The Problem
After restoring a controlfile, the restore database can take a long time to restore due to implicit croscchecking and cataloging.
RMAN> restore database; RMAN-03090: Starting implicit crosscheck backup at 2012/10/05 01:56:55 RMAN-08030: allocated channel: ORA_DISK_1 RMAN-08500: channel ORA_DISK_1: SID=63 device type=DISK RMAN-06206: Crosschecked XXXX objects ------> Time taken <------ RMAN-03091: Finished implicit crosscheck backup at 2012/10/05 02:57:02 RMAN-03090: Starting implicit crosscheck copy at 2012/10/05 02:57:02 RMAN-12016: using channel ORA_DISK_1 ------> Time taken <------- RMAN-03091: Finished implicit crosscheck copy at 2012/10/05 03:57:02 RMAN-07501: searching for all files in the recovery area RMAN-07507: cataloging files... RMAN-07508: cataloging done ------> Time taken <-------
Sometimes this may also inadvertently introduce orphaned incarnations and lead to issues such as these:
a) duplicate failed during the recovery phase:
RMAN-03002: failure of Duplicate Db command at 08/22/2014 11:43:47 RMAN-05501: aborting duplication of target database RMAN-03015: error occurred in stored script Memory Script RMAN-10032: unhandled exception during execution of job step 1: ORA-00283: recovery session canceled due to errors RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed start until change 3996570506 using backup controlfile RMAN-11001: Oracle Error: ORA-00283: recovery session canceled due to errors ORA-19909: datafile 1 belongs to an orphan incarnation ORA-01110: data file 1: '+UAT3_DATA/tlxqa7/datafile/system.309.856254365'
b) Cannot restore from a known backup:
RMAN> list incarnation of database; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------- 1 1 LAWPROD 543219554 PARENT 1 12-MAR-2008 00:38:41 2 2 LAWPROD 543219554 PARENT 602821 25-MAY-2014 01:24:52 4 4 LAWPROD 543219554 ORPHAN 8618277 02-JUL-2014 15:11:35 7 7 LAWPROD 543219554 ORPHAN 8999502 22-JUN-2014 17:04:48 3 3 LAWPROD 543219554 ORPHAN 12377463 10-JUL-2014 02:45:40 9 9 LAWPROD 543219554 ORPHAN 13414195 15-JUL-2014 15:57:28 8 8 LAWPROD 543219554 ORPHAN 13906671 28-JUL-2014 11:25:03 5 5 LAWPROD 543219554 ORPHAN 22434478 28-AUG-2014 19:14:15 6 6 LAWPROD 543219554 CURRENT 23304847 02-SEP-2014 19:33:04
RMAN> run {
set until TIME "TO_DATE('2014-09-08:20:41:00','yyyy-dd-mm:hh24:mi:ss')";
RESTORE DATABASE;
}
2> 3> 4>
executing command: SET until clause
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of set command at 09/09/2014 00:45:39
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time
The Solution
The implicit crosscheck and cataloging are only seen when using the fast recovery area. When using a restored controlfile to restore the database, we need to ensure that the controlfile metadata is still correct. So RMAN automatically crosschecks all backups and catalogs the flash recovery area. This is a one-time operation. So the first time a restore of any datafile is initiated, we will crosscheck and catalog the backup pieces. Subsequent restores from the same controlfile will not kick off the crosscheck and catalog operation.
It is not uncommon to have 1000's of records stored within the controlfile that will require crosschecking. Once the crosschecking is complete RMAN continues with cataloging the fast recovery area. This task can potentially take hours to complete. Further, if a new incarnation is introduced you may have issues with recovery due to the orphaned incarnation.
The workarounds:
1. disable the fast recovery area (FRA).
SQL> alter system set db_recovery_file_dest='' scope=both;
Remember to re-enable the FRA at a later point once the restore (or recovery) is completed.
OR
2. Remove the old files/unnecessary files from the FRA. Please note in 11gr2 you have the option to specify incarnation.