Use the RMAN RESTORE command to restore the following types of files from copies on disk or backups on other media:

· Database (all datafiles)

· Tablespaces

· Control files

· Archived redo logs

· Server parameter files

Process of Restore Operations

RMAN

automates the procedure for restoring files. When you issue a RESTORE command, RMAN restore the correct backups and copies to either:

· The default location, overwriting the old files with the same name

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

For example:

If

you restore datafile 'C:_DATA.DBF’ to its default location, then RMAN restores the file C:_DTAA.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 'C:_DATA.DBF’ TO C:_DATA.DBF’;

RESTORE DATAFILE 'C:_DTAA.DBF’;

SWITCH DATAFILE 'C:_DATA.DBF' TO DATAFILECOPY 'C:_DATA.DBF’;

}

In this case, RMAN creates a datafile copy of 'C:_DATA.DBF’ named 'C:_DATA.DBF’ and records it in the repository. To change the name for datafile 'C:_DATA.DBF’ to 'C:_DATA.DBF’ in the control file, run a SWITCH command so that RMAN considers the restored file as the current database file.

RMAN Recovery: Basic Steps

If possible, make the recovery catalog available to perform the media recovery. If it is not available, then RMAN uses metadata from the target database control file. 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:

· Place the database in the appropriate state: mounted or open. For example, mount the database when performing whole database recovery, or open the database when performing online tablespace recovery.

· Restore the necessary files using the RESTORE command.

· Recover the datafiles using the RECOVER command.

· Place the database in its normal state.

Mechanism of Restore and Recovery operation:

The DBA runs the following commands:

RESTORE DATABASE;

RECOVER DATABASE;

The RMAN recovery catalog obtains its metadata from the target database control file. RMAN 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.

Mechanics of Recovery: Incremental Backups and Redo Logs

RMAN

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

How RMAN Searches for Archived Redo Logs During Recovery

If RMAN cannot find an incremental backup, then it looks in the repository for the names of archived redo logs to use for recovery. Oracle records an archived log in the control file whenever one of the following occurs:

· The archiver process archives a redo log

· RMAN restores an archived log

· The RMAN COPY command copies a log

· The RMAN CATALOG command catalogs a user-managed backup of an archived log

RMAN propagates archived log data into the recovery catalog during resynchronization, classifying archived logs as image copies. You can view the log information through:

· The LIST command

· The V$ARCHIVED_LOG control file view

· The RC_ARCHIVED_LOG recovery catalog view

During recovery, RMAN looks for the needed logs using the filenames specified in the V$ARCHIVED_LOG view. If the logs were created in multiple destinations or were generated by the COPY, CATALOG, or RESTORE commands, then multiple, identical copies of each log sequence number exist on disk.

If the RMAN repository indicates that a log has been deleted or uncataloged, then RMAN ceases to consider it as available for recovery. For example, assume that the database archives log 100 to directories /dest1 and /dest2. The RMAN repository indicates that /dest1/log100.arc and /dest2/log100.arc exist. If you delete /dest1/log100.arc with the DELETE command, then the repository indicates that only /dest2/log100.arc is available for recovery.

If the RMAN repository indicates that no copies of a needed log sequence number exist on disk, then RMAN looks in backups and restores archived redo logs as needed to perform the media recovery. By default, RMAN restores the archived redo logs to the first local archiving destination specified in the initialization parameter file. You can run the SET ARCHIVELOG DESTINATION command to specify a different restore location. If you specify the DELETE ARCHIVELOG option on RECOVER, then RMAN deletes the archived logs after restoring and applying them. If you also specify MAXSIZE integer on the RECOVER command, then RMAN staggers the restores so that they consume no more than integer amount of disk space at a time.

Incomplete Recovery

RMAN can perform either complete or incomplete recovery. You can specify a time, SCN, 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. After performing incomplete recovery, you must open the database with the RESETLOGS option.

Disaster Recovery with a Control File Autobackup

Assume that you lose both the target database and the recovery catalog. All that you have remaining is a tape with RMAN backups of the target database and archived redo logs. Can you still recover the database? Yes, assuming that you enabled the control file autobackup feature. In a disaster recovery situation, RMAN can determine the name of a control file autobackup even without a repository available. You can then restore this control file, mount the database, and perform media recovery.

About Block Media Recovery

You can also use the RMAN BLOCKRECOVER command to perform block media recovery. Block media recovery recovers an individual corrupt datablock or set of datablocks within a datafile. In cases when a small number of blocks require media recovery, you can selectively restore and recover damaged blocks rather than whole datafiles.

Note: Restrictions of block media recovery:

• You can only perform block media recovery with Recovery Manager. No SQL*Plus recovery interface is available.
• You can only perform complete recovery of individual blocks. In other words, you cannot stop recovery before all redo has been applied to the block.
• You can only recover blocks marked media corrupt. The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a file were marked corrupt since the most recent BACKUP, BACKUP ... VALIDATE, or COPY command was run against the file.
• You must have a full RMAN backup. Incremental backups are not allowed.
• Blocks that are marked media corrupt are not accessible to users until recovery is complete. Any attempt to use a block undergoing media recovery results in an error message indicating that the block is media corrupt.

When Block Media Recovery Should Be Used

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 survive a missing or inaccessible archived log. Where is 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 newed block later in the redo stream. When a block is newed all previous redo for that block becomes irrelevant because the redo applies to an old incarnation of the block. For example, Oracle can new a block when users delete all the rows recorded in the block or drop a table.