| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
The concept of datafile media recovery is the application of online or archived redo logs or incremental backups to a restored datafile in order to update it to the current time or some other specified time. Use the RMAN RECOVER command to perform media recovery and apply logs or incremental backups automatically.
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:
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.
To perform incomplete recovery, use the SET UNTIL command to specify the time, SCN, restore point, or log sequence number at which recovery terminates. Alternatively, specify the UNTIL clause on the RESTORE and RECOVER commands.
Restore the necessary files with the RESTORE command.
Recover the datafiles with the RECOVER command.
Place the database in its normal state. For example, open the database, or bring the recovered tablespaces online.
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.
|
See Also:
|
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.
If RMAN cannot find an incremental backup, then it looks in the repository for the names of archived redo logs to use for recovery. The database 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 BACKUP AS COPY command copies a log
The RMAN CATALOG command catalogs a user-managed backup of an archived log
If you use a recovery catalog, then RMAN propagates archived log data into the recovery catalog during resynchronization, classifying archived logs as image copies.
You can view the log information using the LIST ARCHIVELOG command orthe V$ARCHIVED_LOG control file 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 BACKUP AS COPY, CATALOG, or RESTORE commands, then multiple, identical copies of each log sequence number exist on disk. All copies of a log sequence number listed as AVAILABLE are candidates for use in recovery, regardless of how or where they are stored.
Logs that have been deleted or uncataloged through RMAN are not considered 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 flash recovery area, if one of the archive log destinations is set to USE_DB_RECOVERY_FILE_DEST. Otherwise, it restores the 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 restores archived logs until the disk space allowed by MAXSIZE is consumed, then applies redo from the logs and deletes the restored logs to free space, until there is room enough to restore another archived log. RMAN continues restoring, applying and deleting logs, within the MAXSIZE limit, until recovery is complete.
If an archived log is deleted from disk but is still listed in the RMAN repository, then RMAN does not perform automatic failover during recovery. For example, if the repository indicates that /dest1/log100.arc is on disk when in fact this log was deleted using an operating system command, and if RMAN attempts to apply this log file during recovery, then recovery terminates with an error. RMAN does not automatically attempt to apply other copies of log 100 that are listed as available in the repository.
This situation can sometimes occur when you delete an archived log with an operating system utility and then fail to run CROSSCHECK to synchronize the repository with the actual disk contents. If you run a CROSSCHECK, then the RMAN repository is synchronized, and recovery can proceed by applying available copies of the log or restoring a backup of the log if no disk copies are available.
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.
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.
|
See Also: Chapter 8, "RMAN Tablespace Point-in-Time Recovery (TSPITR)" to learn how to perform TSPITR using RMAN |
