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
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:
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
Remove the old files/unnecessary files from the FRA. Please note in 11gr2 you have the option to specify incarnation.
