Recovery Manager (RMAN) is one of the most popular Oracle databases components with unique Backup/Recovery features. It is fully integrated with the Multitenant Architecture allowing to implement “Manage Many-Databases-as-One“ strategy.
RMAN permits to customize and save several database parameters used during the backup and recovery operations. Such parameters define for example the backup retention policy, the default device type, how many archivelog copy should be stored, if the backup-sets should be compressed and/or encrypted and so on…
Below an example of RMAN setup with the highlight of the parameter CONFIGURE BACKUP OPTIMIZATION ON discussed on the next sections.
RMAN> show all; RMAN configuration parameters for database with db_unique_name CEFUPRD are: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 8 DAYS; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/BACKUP/Databases/CEFUPRD/%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/BACKUP/Databases/CEFUPRD/%d_%T_%U'; CONFIGURE MAXSETSIZE TO UNLIMITED; CONFIGURE ENCRYPTION FOR DATABASE OFF; CONFIGURE ENCRYPTION ALGORITHM 'AES128'; CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE; CONFIGURE RMAN OUTPUT TO KEEP FOR 10 DAYS; CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO DISK; CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/fast_recovery_area/rcocefuprd/cefuprd/snapcf_cefuprd.f'; RMAN>
Effects of RMAN Backup Optimization ON/OFF
In a Multitenant environment is more important than ever to understand the effects of the parameter CONFIGURE BACKUP OPTIMIZATION which can be set to ON or OFF.
Behavion when set ON
If RMAN determines that a file is identical and it has been backed up, then it is a candidate to be skipped. RMAN must do further checking to determine whether to skip the file, however, because both the retention policy and the backup duplexing feature are factors in the algorithm that determines whether RMAN has sufficient backups on the specified device type. (Definition from Oracle Backup Recovery User’s Guide).
Behavion when set OFF
The RMAN backup always includes all files no matter if they are identical and already backed up within the backup retention window.
What happens by migrating from Non-CDB to PDB?
Assuming that we have just migrated a non-CDB database to PDB and our pluggable database has 4 tablespaces all open read/write. The container uses the same RMAN setup included on the top of this page, with CONFIGURE BACKUP OPTIMIZATION ON.
Dispite having a FULL database backup every night, only 1 backup every 8 days will be complete and consistent, because the RMAN backup optimization algorithm will detect the SEED PDB datafiles unchanged and it will skip those files. Therefore if we restore the CDB using the backup-sets generated by one FULL database backup, with no access to the rest of backup-sets inside the retention window, there are great probabilities that the restore will fail.
Extract of the CDB backup log which shows that the PDB$SEED datafiles have been skipped because already backed up 1 time during the last 8 days.
RMAN> BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL = 0 DATABASE PLUS ARCHIVELOG NOT BACKED UP 1 TIMES; Starting backup at May 15 2018 00:35:07 current log archived allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=9 instance=clgbprd1 device type=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: SID=168 instance=clgbprd1 device type=DISK skipping archived logs of thread 1 from sequence 39516 to 39931; already backed up skipping archived logs of thread 2 from sequence 34457 to 34749; already backed up channel ORA_DISK_1: starting compressed archived log backup set channel ORA_DISK_1: specifying archived log(s) in backup set input archived log thread=2 sequence=34774 RECID=148645 STAMP=976088413 input archived log thread=2 sequence=34775 RECID=148649 STAMP=976088467 input archived log thread=1 sequence=39944 RECID=148655 STAMP=976088552 input archived log thread=2 sequence=34776 RECID=148651 STAMP=976088509 input archived log thread=2 sequence=34777 RECID=148653 STAMP=976088551 input archived log thread=2 sequence=34778 RECID=148657 STAMP=976088700 input archived log thread=1 sequence=39945 RECID=148662 STAMP=976088937 input archived log thread=2 sequence=34779 RECID=148659 STAMP=976088838 ... Starting backup at May 15 2018 00:50:02 using channel ORA_DISK_1 using channel ORA_DISK_2 skipping datafile 2; already backed up 1 time(s) skipping datafile 4; already backed up 1 time(s) channel ORA_DISK_1: starting compressed incremental level 0 datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set ...
Using only the backup-sets above to restore the CDB means that Oracle has to recreate the two skipped datafiles (number 2 and 4) applying the archived logs generated during the initial CDB provisioning.
To note that the full backup starts including archived log from the following sequence:
- For the Thread 1 – Sequence 39944
- For the Thread 2 – Sequence 34774
But when Oracle initiates the Media Recovery, it complains because the archived log Thread 1 – Sequence 1 is unavailable:
RMAN> run {
allocate auxiliary channel dsk1 type disk ;
2> allocate auxiliary channel dsk2 type disk ;
allocate auxiliary channel dsk3 type disk ;
allocate auxiliary channel dsk4 type disk ;
3> allocate auxiliary channel dsk5 type disk ;
4> allocate auxiliary channel dsk6 type disk ;
5> duplicate database to 'CEFUAUX' noopen backup location '/BACKUP/Databases/CEFUPRD/backup_20180515_only' nofilenamecheck;
}6> 7> 8> 9>
allocated channel: dsk1
channel dsk1: SID=322 device type=DISK
allocated channel: dsk2
channel dsk2: SID=471 device type=DISK
allocated channel: dsk3
channel dsk3: SID=9 device type=DISK
allocated channel: dsk4
channel dsk4: SID=166 device type=DISK
allocated channel: dsk5
channel dsk5: SID=323 device type=DISK
allocated channel: dsk6
channel dsk6: SID=478 device type=DISK
Starting Duplicate Db at May 15 2018 09:29:15
....
contents of Memory Script:
{
set until scn 2372623043;
recover
clone database
delete archivelog
;
}
executing Memory Script
executing command: SET until clause
Starting recover at May 15 2018 11:24:39
starting media recovery
unable to find archived log
archived log thread=1 sequence=1
Oracle instance started
I hope this example helped to understand that while migrating from non-CDB to Multitenant, many Administration tasks should be carefully reviewed due to major architecture changes.
My Oracle Notes 