Performing Recovery with a Backup Control File

This section explains what to do when all current control files are lost and you must restore a control file backup.

About Recovery with a Backup Control File

If all copies of the current control file are lost or damaged, then you must restore and mount a backup control file. You must then run the RECOVER command, even if no datafiles have been restored, and open the database with the RESETLOGS option. If some copies of the current control file are usable, however, then you can follow the procedure in "Responding to the Loss of a Subset of the Current Control Files" and avoid the recovery and RESETLOGS.
During recovery, RMAN automatically searches for online and archived logs that are not recorded in the RMAN repository and catalogs any that it finds. RMAN attempts to find a valid archived redo log in any current archiving destination with the current log format. The current format is specified in the initialization parameter file used to start the instance (or all instances in an Oracle RAC configuration). Similarly, RMAN attempts to find the online redo logs by using the filenames listed in the control file.
If you changed the archiving destination or format during recovery, or if you added new online log members after the backup of the control file, then RMAN may not be able to automatically catalog a needed online or archived log. Whenever RMAN cannot find online redo logs and you did not specify an UNTIL time, RMAN reports errors similar to the following:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/29/2007 14:23:09
RMAN-06054: media recovery requesting unknown log: thread 1 scn 86945

In this case, you must use the CATALOG command to manually add the required redo logs to the repository so that recovery can proceed.

See Also:

The discussion of RESTORE CONTROLFILE in Oracle Database Backup and Recovery Reference For more details on restrictions on using RESTORE CONTROLFILE in different scenarios (such as when using a recovery catalog, or restoring from a specific backup)

Control File Locations

When restoring the control file, the default destination is all of the locations defined in the CONTROL_FILES initialization parameter. If you do not set the CONTROL_FILES initialization parameter, then the database uses the same rules to determine the destination for the restored control file that it uses when creating a control file if the CONTROL_FILES parameter is not set. These rules are described in Oracle Database SQL Language Reference in the description of the CREATE CONTROLFILE statement.
One way to restore the control file to one or more new locations is to change the CONTROL_FILES initialization parameter, and then use the RESTORE CONTROLFILE command with no arguments to restore the control file to the default locations. For example, if you are restoring your control file after a disk failure made some but not all CONTROL_FILES locations unusable, you can change CONTROL_FILES to replace references to the failed disk with path names pointing to another disk, and then run RESTORE CONTROLFILE with no arguments.
You can also restore the control file to any location you choose other than the CONTROL_FILES locations, by using the form RESTORE CONTROLFILE TO 'filename' [FROM AUTOBACKUP]:

RESTORE CONTROLFILE TO '/tmp/my_controlfile';

You can perform this operation with the database in NOMOUNT, MOUNT or OPEN states, because you are not overwriting any of the control files currently in use. Any existing file named 'filename' is overwritten. After restoring the control file to a new location, you can then update the CONTROL_FILES initialization parameter to include the new location.