Restore oracle database 12C incremental backup on daily basis

Question

i need to restore my backup at different database server with following sequence on daily basis

level 0 incremental only once level 1 incremental everyday

i did the level 0 restore successfully however when i was restoring the incremental backup using the incremental backup level 1 control file i noticed that RMAN was reading the full backup files and allocating almost the same space used to restore the level 0 back .

my question is can i restore incremental level 1 backups on daily basis without restoring the level 0 backup ? also why the rman allocate more space for each restore if the datafiles already exists from the level 0 backup ?

below are the scripts used for full and inc backup

Full

#!/bin/bash ORACLE_HOME=/u01/app/oracle/product/12.2.0.1/dbhome_1

ORACLE_SID=cdb11

PATH=$PATH:$ORACLE_HOME/bin

DD=date +%Y-%m-%d-%H-%M

export ORACLE_HOME ORACLE_SID PATH DD

mkdir /ArchiveDBBackup/DAILY_RMAN/${DD}

LOGFILE=/ArchiveDBBackup/DAILY_RMAN/log/DAILY_FULLBKP_date +%Y%m%d.log

rman target / LOG $LOGFILE <<EOF run { backup as compressed backupset incremental level 0 DEVICE TYPE DISK TAG='DAILY_BACKUP' FORMAT '/ArchiveDBBackup/DAILY_RMAN/${DD}/DAILY_FULLBKP_%D_%T_%s-%p' check logical database plus archivelog; backup current controlfile format '/ArchiveDBBackup/DAILY_RMAN/${DD}/CDB1_CONTROLFILE_%D_%T_%s-%p'; backup spfile format '/ArchiveDBBackup/DAILY_RMAN/${DD}/CDB1_SPFILE_%D_%T_%s-%p'; } EOF

INC

#!/bin/bash

ORACLE_HOME=/u01/app/oracle/product/12.2.0.1/dbhome_1

ORACLE_SID=cdb11

PATH=$PATH:$ORACLE_HOME/bin

DD=date +%Y-%m-%d-%H-%M

export ORACLE_HOME ORACLE_SID PATH DD

mkdir /ArchiveDBBackup/DAILY_INC/${DD}

LOGFILE=/ArchiveDBBackup/DAILY_INC/log/DAILY_INCBKP_date +%Y%m%d.log

rman target / LOG $LOGFILE <<EOF run { backup as compressed backupset INCREMENTAL LEVEL 1 DEVICE TYPE DISK TAG='DAILY_INC' FORMAT '/ArchiveDBBackup/DAILY_INC/${DD}/DAILY_INCBKP_%D_%T_%s-%p' check logical database plus archivelog; backup current controlfile format '/ArchiveDBBackup/DAILY_INC/${DD}/CDB1_CONTROLFILE_%D_%T_%s-%p'; backup spfile format '/ArchiveDBBackup/DAILY_INC/${DD}/CDB1_SPFILE_%D_%T_%s-%p'; } EOF

Answer 1

Incremental backups make copies of all data blocks changed since the previous incremental backup. If you have updated a lot of data, or if the daily amount of archive logs is significantly larger than the size of most data files, that could add up to almost as much space required as a full backup.

As for the restore, RMAN must always start from the most recent complete level 0 backup and then apply all incremental changes on top of that to reach the desired point in time or SCN value. You can't restore from just a level 1 backup because it only contains changes, not the baseline starting point for all data.

Have you considered using rman's "duplicate database" feature, as described here: https://docs.oracle.com/database/121/BRADV/rcmdupdb.htm#BRADV010 ?

Answer 2

You don't state the purpose of the second database, but you might want to consider using DataGuard to create a Snapshot Standby database. (That's the plain vanilla, "free" sort of DataGuard, not the "Active" version that costs you money - although the latter might be another option for you).

DataGuard is a Disaster Recovery technology that can use log shipping to maintain copies of a Primary database. In this case, you start by creating a Physical Standby database, a complete copy of your Primary database which is is permanently in Recovery mode, receiving redo from the Primary.

Then, when you want to use this Standby, you "unplug" it from DataGuard and open it, just like any other database - this is the Snapshot Standby. You can use this database in any way you like, even writing changes to it (but don't).

When you want to "refresh" the Standby from the Primary, you "plug" it back into DataGuard, which will then "catch-up" all the redo logs generated on the Primary, bringing the Standby back up to date.

Warning: This requires a lot of disk space.
Not only do you need to buffer all of the redo logs generated on the Primary (which are held in the FRA on both the Primary and the Standby) but you'll also need Flashback [Database] logging in place. This is used by DataGuard to "flashback" the Standby database to the point it was "unplugged" from the Primary, so that redo Apply can pick up where it left off.
(Remember when I said you shouldn't make changes to the Snapshot Standby? This is why!)

If you have the money for it, you might also consider "Active" DataGuard.
In this arrangement, you have a Physical Standby database, permanently connected to the Primary and receiving redo all the time, but the "Active" part allows you to run queries against it as well. I'm pretty sure you can't make any changes, though.