< Previous  | TOC | Index | Next  >

Guidelines for Oracle Recovery

For optimal Oracle recovery, follow these guidelines:

• Back up all control files before storage rollback in case the subsequent Oracle recovery is not successful. Oracle recommends that you keep at least two copies of the control files for each Oracle database and that you store the copies on different disks. It is also a good idea to back up the control files before and after making structural changes to databases.

  ---

    Note   The dbed_ckptcreate command automatically saves control file and log information when you create a Storage Checkpoint.

  ---

  See Creating Storage Checkpoints using dbed_ckptcreate

• Make sure that the control files are not rolled back.

  A control file is a small binary file that describes the structure of the database and must be available to mount, open, and maintain the database. The control file stores all necessary database file information, log file information, the name of the database, the timestamp of database creation, and synchronization information, such as the Storage Checkpoint and log-sequence information needed for recovery. Rolling back the control file will result in an inconsistency between the physical database structure and the control file.

  ---

    Note   If your intention is to roll back the database to recover from structural changes that you do not want to maintain, you may want to use the backup control file that was created by the dbed_ckptcreate command. The backup control file is located in the directory $VXDBA_DBPATH/$ORACLE_SID/checkpoint_dir/CKPT_NAME.

  ---

• Make sure that all archived redo logs are available.

  A database backup with online and archived logs is required for a complete database recovery. Query V$ARCHIVED_LOG to list all the archived log information and V$ARCHIVE_DEST to list the location of archive destinations.

  To restore the necessary archived redo log files, you can query V$LOG_HISTORY to list all the archived redo log history or query V$RECOVERY_LOG to list only the archived redo logs needed for recovery. The required archived redo log files can be restored to the destination specified in the LOG_ARCHIVE_DEST parameter or to an alternate location. If the archived redo logs were restored to an alternate location, use the ALTER DATABASE RECOVER ... FROM statement during media recovery.

• After storage rollback, perform Oracle recovery, applying some or all of the archived redo logs.

  ---

    Note   After rolling back the database (including control files and redo logs) to a Storage Checkpoint, you need to recover the Oracle database instance. Rolling the database forward is not supported; that is, you cannot apply archived redo logs.

  ---

  • To perform a complete media recovery:

    SET AUTORECOVERY ON;

    RECOVER DATABASE;

• To perform an incomplete media recovery, use one of the following:
  • RECOVER DATABASE UNTIL CANCEL;
  • RECOVER DATABASE UNTIL TIME 'yyyy-mm-dd:hh:mm:ss';

    (You can confirm the time of error by checking the ../bdump/alert*.log file.)

  • RECOVER DATABASE UNTIL TIME 'yyyy-mm-dd:hh:mm:ss'\
using backup controlfile;
  • RECOVER DATABASE UNTIL CHANGE scn;

• To open the database after an incomplete media recovery, use the following:

  ALTER DATABASE OPEN RESETLOGS;

  RESETLOGS resets the log sequence. The RESETLOGS option is required after an incomplete media recovery. After opening the database with the RESETLOGS option, remove the Storage Checkpoint you just rolled back to as well as any Storage Checkpoints that were taken before that one. These earlier Storage Checkpoints can no longer be used for storage rollback. After removing these Storage Checkpoints, be sure to create a new Storage Checkpoint.

  ---

    Caution   Attempting to roll back to the same Storage Checkpoint more than once can result in data corruption. After rolling back, be sure to delete the Storage Checkpoint that you rolled back to and then create a new one.

  ---

See your Oracle documentation for complete information on recovery.