Performing Disaster Recovery

Disaster recovery includes the restore of and recovery of the target database after the loss of the entire target database, the recovery catalog database, all current control files, all online redo log files, and all parameter files.

To perform a disaster recovery, the minimum required set of backups is backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.

The basic procedure for disaster recovery begins with restoring an autobackup of the server parameter file, as described in Oracle Database Backup and Recovery Basics.

Once you have an SPFILE, you can start the target database instance, restore the control file from autobackup and mount it.

With the control file mounted, then follow the instructions found in "Performing Recovery with a Backup Control File" to restore and recover your datafiles.

Note:

If you are restoring to a new host, you should review the considerations described in "Restore and Recovery of the Database on a New Host".

The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:

You are restoring the database to a new host with the same directory structure.
You have one tape drive containing backups of all the datafiles and archived redo logs through log 1124, as well as autobackups of the control file and server parameter file.
You do not use a recovery catalog.

In this scenario, perform the following steps:

If possible, restore all relevant network files such as tnsnames.ora and listener.ora by means of operating system utilities.
Start RMAN and connect to the target database. If you do not have the Oracle Net files, then connect using operating system authentication.
Specify the DBID for the target database with the SET DBID command, as described in "Performing Recovery with a Backup Control File and No Recovery Catalog: Scenario".
Run the STARTUP NOMOUNT command. RMAN attempts to start the instance with a dummy server parameter file.
Allocate a channel to the media manager and then run the RESTORE SPFILE FROM AUTOBACKUP command.
Run STARTUP FORCE NOMOUNT mode so that the instance is restarted with the restored server parameter file.
Allocate a channel to the media manager and then restore a control file autobackup (refer to"Performing Recovery with a Backup Control File and No Recovery Catalog: Scenario").
Mount the restored control file.
Catalog any backups not recorded in the repository with the CATALOG command (refer to"Removing DELETED Records From the Recovery Catalog After Upgrade").
Restore the datafiles to their original locations. If volume names have changed, then run SET NEWNAME commands before the restore and perform a switch after the restore to update the control file with the new locations for the datafiles (refer to"Performing Disaster Recovery").
Recover the datafiles. RMAN stops recovery when it reaches the log sequence number specified.
Open the database in RESETLOGS mode. Only complete this last step if you are certain that no other archived logs can be applied.

# Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt

# Set the DBID for the target database
RMAN> SET DBID 676549873;
RMAN> STARTUP FORCE NOMOUNT;  # rman starts instance with dummy parameter file
RUN
{
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  RESTORE SPFILE FROM AUTOBACKUP;
}
# Restart instance with restored server parameter file
RMAN> STARTUP FORCE NOMOUNT;  

RMAN> RUN
{
  # Manually allocate a channel to the media manager
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  # Restore autobackup of the control file. This example assumes that you have 
  # accepted the default format for the autobackup name.
  RESTORE CONTROLFILE FROM AUTOBACKUP;
  #  The set until command is used in case the database
  #  structure has changed in the most recent backups, and you wish to
  #  recover to that point-in-time. In this way RMAN restores the database
  #  to the same structure that the database had at the specified time.
  ALTER DATABASE MOUNT;
  SET UNTIL SEQUENCE 1124 THREAD 1;
  RESTORE DATABASE;
  RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery completes

The following example of the RUN command shows the same scenario except with new filenames for the restored datafiles:

RMAN> RUN
{
  #  If you need to restore the files to new locations, tell Recovery Manager
  #  to do this using SET NEWNAME commands:
  SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
  SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
  SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  RESTORE CONTROLFILE FROM AUTOBACKUP;
  ALTER DATABASE MOUNT;
  SET UNTIL SEQUENCE 124 THREAD 1;
  RESTORE DATABASE;
  SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
  RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;