This chapter describes the basic concepts involved in using RMAN to restore, recover, and duplicate databases.
This chapter contains these topics:
Use the RMAN RESTORE
command to restore the following types of files from disk or other media:
Database (all datafiles)
Tablespaces
Control files
Archived redo logs
Server parameter files
Because a backup set is in a proprietary format, you cannot simply copy it as you would a backup database file created with an operating system utility; you must use the RMAN RESTORE
command to extract its contents. In contrast, the database can use image copies created by the RMAN BACKUP
AS
COPY
command without additional processing.
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.
Run SET NEWNAME? | RESTORE Behavior | Run SWITCH? |
---|---|---|
No | RMAN restores the files to their current path names. | N/A |
Yes | RMAN restores the files to the path names specified by SET NEWNAME and creates repository records for each datafile copy after the restore. |
If yes, then RMAN replaces the current datafile names in the control file to the names of the restored files and current datafile names (if exists) are stored as datafile copies. If no, then RMAN doesn't update current datafile names and the restored file is retained as datafile copies. |
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
.
See Also:
Oracle Database Backup and Recovery Reference forSET
NEWNAME
syntax, and Oracle Database Backup and Recovery Reference for SWITCH
syntaxRMAN 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.
See Also:
"Configuring Channels"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
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.
Note:
Restore optimization only checks the datafile header. It does not the scan the datafile body for corrupted blocks.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.
See Also:
Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for description ofRESTORE
behavior in a RAC configurationThe 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.
Figure 3-1 Performing RMAN Media Recovery
See Also:
Chapter 7, "Advanced RMAN Recovery Techniques" for detailed restore and recovery procedures
Oracle Database Backup and Recovery Reference for RESTORE
syntax
Oracle Database Backup and Recovery Reference for RECOVER
syntax
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 or the 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 RMANAlthough datafile media recovery is the principal form of 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.
Block media recovery provides several advantages over datafile media recovery. For example, block media recovery
Lowers the Mean Time to Recovery (MTTR) because only blocks needing recovery are restored and only necessary corrupt blocks undergo recovery. Block media recovery minimizes redo application time and avoids I/O overhead during recovery.
Allows affected datafiles to remain online during recovery of the blocks. Without block-level recovery, if even a single block is corrupt, then you must restore a backup of the entire datafile and apply all redo generated for that file after the backup was created.
Note these restrictions of block media recovery:
You can only perform block media recovery with RMAN. 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
or BACKUP
...
VALIDATE
command was run against the file.
You must have a full RMAN backup. Incremental backups are not used by block media recovery. Proxy backups are also not used by block media recovery. Only full backups and archived log files are used.
Block media recovery is able to restore blocks from parent incarnation backups and recover the corrupted blocks through a RESETLOGS
.
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.
See Also:
"Performing Disaster Recovery" and Oracle Database Backup and Recovery Reference forBLOCKRECOVER
syntaxBlock 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;
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.
Note:
Each block is recovered independently during block media recovery, so recovery may be successful for a subset of blocks.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
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.
Use the RMAN DUPLICATE
command to create a copy of the target database in another location. The command restores backups of the primary database files and creates a new database.
As part of the duplication, RMAN manages the following:
Restores the target datafiles into the duplicate database and performs incomplete recovery using all available archived log and incremental backups
Opens the duplicate database with the RESETLOGS
option after incomplete recovery to create the online redo logs
Generates a new, unique database identifier for the duplicate database
Note the following features of RMAN duplication. You can:
Skip read-only tablespaces with the SKIP
READONLY
clause (read-only tablespaces are included by default). You can also exclude any tablespace with the SKIP
TABLESPACE
clause so long as it is not the SYSTEM
or SYSAUX
tablespace and does not contain rollback or undo data. If you omit tablespaces, then you can add them later.
Create the duplicate database in a new host. If the same directory structure is available, then you can use the NOFILENAMECHECK
option and reuse the target datafile filenames for the duplicate datafiles.
Create the duplicate database by using the SET
UNTIL
command or UNTIL
clause of the DUPLICATE
command to recover it to a past time. By default, the DUPLICATE
command creates the database using the most recent backups of the target database and then performs recovery to the most recent consistent point contained in the incremental and archived redo log backups.
Use the duplicate database without a recovery catalog.
Register the duplicate database in the same recovery catalog as the target database. This option is possible because the duplicate database receives a new database identifier during duplication. If you copy the target database with operating system utilities, then the database identifier of the copied database remains the same so you cannot register it in the same recovery catalog (unless you change its DBID with the DBNEWID utility, described in Oracle Database Utilities ).
Figure 3-3 illustrates a case of database duplication. In this example, RMAN creates two duplicate database by using one set of datafile backups: one database on the local host and one database on a remote host.
Figure 3-3 Creating a Duplicate Database from Backups
The method you use to duplicate your database depends on whether you are creating your duplicate database on the same or a different host and whether the duplicate directory structure is the same as your target database directory structure. For example, in some cases you can keep the same directory structure and filenames in your duplicate database, while other times you must rename the files.
See Also:
Chapter 13, "Creating and Updating Duplicate Databases with RMAN" to learn how to make a duplicate database
Oracle Database Backup and Recovery Reference for DUPLICATE
command syntax
Oracle Database Utilities to learn how to use the DBNEWID
utility
You can use the RMAN DUPLICATE
command to create a physical standby database. (Note that RMAN cannot be used to create a logical standby database, because it is not a block-for-block duplicate of the primary database.)
RMAN automates the following steps of the creation procedure:
Restores the standby control file.
Restores the primary datafile backups.
Optionally, RMAN recovers the standby database (after the control file has been mounted) up to the specified time or to the latest archived redo log generated.
RMAN leaves the database mounted so that the user can activate it, place it in manual or managed recovery mode, or open it in read-only mode.
RMAN cannot fully automate creation of the standby database because you must manually create an initialization parameter file for the standby database, start the standby instance without mounting the control file, and perform any Oracle Net setup required before performing the creation of the standby. Also, you must have RMAN backups of all datafiles available and a control file backup that is usable as a standby control file, and those backups must be accessible by the standby instance under the same name.
Once the standby database is created, RMAN can be used to back up the datafiles, control file and archived redo logs of the standby. Backups of datafiles and archived redo logs taken from a physical standby database are fully interchangeable with primary backups. In other words, you can restore a backup of a physical standby datafile to the primary database, and you can restore a backup of a primary datafile to the physical standby database. The standby control file backups can be used to restore the standby control file without needing to re-instantiate the standby in cases where the standby control file is lost.
See Also:
Oracle Data Guard Concepts and Administration to learn how to create and back up a physical standby database with RMAN