Restoring Files with RMAN

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 exhaused 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.