3 RMAN Recovery Concepts

Mechanics of Datafile Restore Operations

When you issue a RESTORE command, RMAN directs a server session to restore a suitable backup to either:

• The default location, overwriting the files with the same name currently there

• A new location, which you can specify with the SET NEWNAME command

To restore a datafile, either mount the database, or keep it open and take the datafile to be restored offline. When RMAN performs a restore, it creates the restored files as datafile image copies and records them in the repository.

The following table describes the behavior of the RESTORE, SET NEWNAME, and SWITCH commands.

For example, if you restore datafile ?/oradata/trgt/tools01.dbf to its default location, then RMAN restores the file ?/oradata/trgt/tools01.dbf and overwrites any file that it finds with the same filename. If you run a SET NEWNAME command before you restore a file, then RMAN creates a datafile copy with the name that you specify. For example, assume that you run the following commands:

RUN {
    SET NEWNAME FOR DATAFILE '?/oradata/trgt/tools01.dbf' TO '/tmp/tools01.dbf';
    RESTORE DATAFILE '?/oradata/trgt/tools01.dbf';
}

In this case, RMAN creates a datafile copy of ?/oradata/trgt/tools01.dbf named /tmp/tools01.dbf and records it in the repository. To update the control file to use the datafile copy at ?/oradata/trgt/tools01.dbf to /tmp/tools01.dbf as the datafile, use the SWITCH command as shown in the following example:

SWITCH DATAFILE '/tmp/tools01.dbf' TO DATAFILECOPY '?/oradata/trgt/tools01.dbf';

The SWITCH command is the RMAN equivalent of the SQL statement ALTER DATABASE RENAME FILE.

How RMAN Selects Backups for Use in Restore Operations

RMAN uses the record of available backups in the RMAN repository to select the best available backups for use in the restore operation. The most recent backup available, or the most recent backup satisfying any UNTIL clause specified in the RESTORE command, is always the preferred choice. If two backups are from the same point in time, RMAN prefers to use image copies over backup sets because RMAN can restore more quickly from image copies than from backup sets (especially those stored on tape).

All specifications of the RESTORE command must be satisfied before RMAN restores a backup. Unless limited by the DEVICE TYPE clause, the RESTORE command searches for backups on all device types of configured channels.

If no available backup in the repository satisfies all the specified criteria, then RMAN returns an error during the compilation phase of the restore job.

If you use only manually allocated channels, a backup job may fail if there is no usable backup on the media for which you allocated channels. Configuring automatic channels makes it more likely that RMAN can find and restore a backup that satisfies the specified criteria.

Restore Failover

During a RESTORE operation, if a backup piece, image copy or proxy copy is inaccessible (for instance, deleted from the device) or a block in the backup is corrupted, then RMAN automatically looks for a another usable copy of this backup piece or image copy, on the same device or another device, based on the information in the RMAN repository. If no usable copies are available, then RMAN searches for prior backups. RMAN searches all prior backups for the most recent available backup usable in the current operation until it has exhausted all possibilities. If all of the backups are unusable or no backups exists, then RMAN will try to re-create the datafile.

Restore failover is also used when there are errors restoring archivelogs during RECOVER, BLOCKRECOVER, and FLASHBACK DATABASE commands.

When RMAN performs restore failover to another backup of the same file, you will see a message similar to this one in the output of RMAN:

failover to piece handle=/u01/backup/db_1 tag=BACKUP_031009

Also, details about block corruptions will be printed in the alert log and trace files.

When restore failover cannot locate another copy of the same backup and searches for a prior backup, the message generated is similar to this example:

ORA-19624: operation failed, retry possible
ORA-19505: failed to identify file "/u01/backup/db_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
failover to previous backup

Restore Optimization

RMAN uses restore optimization to avoid restoring datafiles from backup when possible. If a datafile is already present in the correct location and its header contains the expected information, then RMAN does not restore the datafile from backup.

You can use the FORCE option of the RESTORE command to override this behavior and restore the requested files unconditionally.

Restore optimization is particularly useful in cases where an operation that restores several datafiles is interrupted. For example, assume that a full database restore encounters a power failure after all except one of the datafiles has been restored. If you run the same RESTORE operation again, then RMAN only restores the single datafile that was not restored during the previous attempt.

Restore optimization is also used when duplicating a database. If a datafile at the duplicate is in the correct place with the correct header contents, then the datafile is not duplicated. Unlike RESTORE, however, DUPLICATE does not support a FORCE option. To force RMAN to duplicate a datafile that is skipped due to restore optimization, delete the datafile from the duplicate before running the DUPLICATE command.

RMAN Media Recovery: Basic Steps

If possible, make the recovery catalog available to perform the media recovery. If it is not available, or if you do not maintain a recovery catalog, then RMAN uses metadata from the target database control file. If both the control file and recovery catalog are lost, then you can still recover the database—assuming that you have backups of the datafiles and at least one autobackup of the control file.

The generic steps for media recovery using RMAN are as follows:

Figure 3-1 illustrates an example of RMAN media recovery using data from the RMAN repository. The repository in this example is stored in a recovery catalog. The contents of the recovery catalog have been synchronized with the record of backups in the control file.

The DBA enters the following commands in the RMAN client:

RESTORE DATABASE;
RECOVER DATABASE;

RMAN then queries the repository, which in this example is a recovery catalog. RMAN then decides which backup sets to restore, and which incremental backups and archived logs to use for recovery. A server session on the target database instance performs the actual work of restore and recovery.

Figure 3-1 Performing RMAN Media Recovery

Description of "Figure 3-1 Performing RMAN Media Recovery"

Mechanics of Recovery: Incremental Backups and Redo Logs

If RMAN has a choice between applying an incremental backup or applying redo to the restored datafiles to meet a recovery objective, then it always chooses an incremental backup. If overlapping levels of incremental backup are available, then RMAN automatically chooses the one covering the longest period of time.

RMAN does not need to apply incremental backups to a restored level 0 incremental backup: it can also apply archived logs. RMAN restores the datafiles that it needs from available backups, applies incremental backups to the datafiles if they are available, and then applies archived logs.

Incomplete or Point-In-Time Recovery

RMAN can perform either complete or point-in-time recovery (also called incomplete recovery). You can specify a time, SCN, restore point, or log sequence number as a limit for incomplete recovery with the SET UNTIL command or with an UNTIL clause specified directory on the RESTORE and RECOVER commands. The easiest method is run the SET UNTIL command before issuing the RESTORE and RECOVER commands. After performing incomplete recovery, you must open the database with the RESETLOGS option.

Tablespace Point-in-Time Recovery

Recovery Manager automated Tablespace Point-in-Time Recovery (TSPITR) enables you to recover one or more tablespaces to a point in time that is different from that of the rest of the database. RMAN TSPITR is most useful in these cases:

• To recover from an erroneous drop or truncate table operation

• To recover a table that has become logically corrupted

• To recover from an incorrect batch job or other DML statement that has affected only a subset of the database

• In cases where there are multiple logical schemas in separate tablespaces of one physical database, and where one schema must be recovered to a point different from that of the rest of the physical database

• For VLDBs (very large databases), even if a full database point-in-time recovery would suffice, you might choose to do tablespace point-in-time recovery rather than restore the whole database from a backup and perform a complete database roll forward

Similar to a table export, RMAN TSPITR enables you to recover a consistent data set; however, the data set is the entire tablespace rather than a single object.

When to Use Block Media Recovery

Block media recovery is not intended for cases where the extent of data loss or corruption is unknown and the entire datafile requires recovery. In such cases, datafile media recovery is the best solution. Block media recovery is not a replacement for traditional datafile media recovery, but a supplement to it.

In most cases, the database marks a block as media corrupt, invalidates the block in the instances (or all enabled instances in a Real Application Clusters configuration), and then writes it to disk when the corruption is first encountered. No subsequent read of the block will be successful until the block is recovered. You can only perform block recovery on blocks that are marked corrupt. This corrupt status effectively takes the block offline in all database instances and prevents user access during recovery.

Block media recovery is most useful for data losses that affect specific blocks. Block-level data loss usually results from intermittent, random I/O errors that do not cause widespread data loss, as well as memory corruptions that get written to disk. Typically, these types of block corruption are reported in the following locations:

• Error messages in standard output

• The alert log

• User trace files

• Results of the SQL commands ANALYZE TABLE and ANALYZE INDEX

• Results of the DBVERIFY utility

• Third-party media management output

For example, you may discover the following messages in a user trace file:

ORA-01578: ORACLE data block corrupted (file # 7, block # 3)
ORA-01110: data file 7: '/oracle/oradata/trgt/tools01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 235)
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'

You can then specify the corrupt blocks in the BLOCKRECOVER command as follows:

BLOCKRECOVER
  DATAFILE 7 BLOCK 3 
  DATAFILE 2 BLOCK 235;

Block Media Recovery When Redo Is Missing

Like datafile media recovery, block media recovery cannot generally survive a missing or inaccessible archived log (although it will attempt restore failover when looking for usable copies of archived redo log files, as described in "Restore Failover"). Nevertheless, block media recovery can survive gaps in the redo stream if the missing or corrupt redo records do not affect the blocks being recovered. Whereas datafile recovery requires an unbroken series of redo changes from the beginning of recovery to the end, block media recovery only requires an unbroken set of redo changes for the blocks being recovered.

When RMAN first detects missing or corrupt redo records during block media recovery, it does not immediately signal an error because the block undergoing recovery may become a new block later in the redo stream. When a block is new all previous redo for that block becomes irrelevant because the redo applies to an old incarnation of the block. For example, the database can new a block when users delete all the rows recorded in the block or drop a table.

Assume that media recovery is performed on block 13 as depicted in Figure 3-2.

Figure 3-2 Performing RMAN Media Recovery

Description of "Figure 3-2 Performing RMAN Media Recovery"

After block recovery begins, RMAN discovers that change 120 is missing. RMAN does not terminate recovery in the hope that block 13 will be new later in the redo stream. Assume that in change 140 a user drops the table EMPLOYEE stored in block 13. At this point, the database formats block 13 as a new block. Because the redo for block 13 in change 120 related to the EMPLOYEE table, and the EMPLOYEE table was dropped in change 140, RMAN can skip this missing change and apply the redo between changes 140 and 160.