recover::=
dbObject::=
sizeSpec::=
The RECOVER command has three distinct uses:
Performing complete recovery of one or more restored datafiles, or the entire database.
Performing point-in-time recovery of a database (DBPITR) or tablespace (TSPITR).
Applying incremental backups to a datafile image copy (not a restored datafile) to roll it forward in time.
When performing media recovery, RMAN first looks for archived logs on disk, and if none are available, then it restores logs from backups to the LOG_ARCHIVE_DEST_1
destination (or the SET
ARCHIVELOG
DESTINATION
) as needed for the recovery.
Complete and point-in-time recovery of a database can use both incremental backups and archived logs. If RMAN has a choice between applying an incremental backup or applying redo, then it always chooses the incremental backup. Applying incremental backups is faster and captures NOLOGGING changes. If overlapping levels of incremental backup are available, then RMAN automatically chooses the one covering the longest period of time.
RMAN also applies incremental backups to restored files that were not restored from an incremental backup.
Note:
When RMAN applies incremental backups, it also recovers changes to objects created with theNOLOGGING
option. Applying archived redo logs to datafiles does not recover these changes.See Also:
Oracle Database Backup and Recovery Basics to learn how to recover datafiles.
"RESTORE" command for explanation of the default location for restoring archived logs. Note that RMAN automatically specifies the MAXSIZE
option when staging logs in the flash recovery area.
You cannot arbitrarily recover individual datafiles to different points in time. You can recover the whole database to a single point in time (DBPITR, in which case you should useSET UNTIL
, followed by RESTORE DATABASE
and RECOVER DATABASE
) or recover wholly contained tablespaces to a point in time different from the rest of the database (TSPITR, in which case you must use RECOVER TABLESPACE... UNTIL...
). For more information on DBPITR, see Oracle Database Backup and Recovery Advanced User's Guide. For more information on TSPITR, see the procedure described in Oracle Database Backup and Recovery Advanced User's Guide .
For whole database recovery, the database must be mounted but not open. For recovery of datafiles or tablespaces, the target database must be mounted or open, but if the database is open, then the datafiles or tablespaces to be recovered must be offline.
The RECOVER
DATABASE
command does not recover any files that are offline normal or read-only at the point in time to which the files are being recovered. RMAN omits offline normal files with no further checking. If CHECK
READONLY
is specified, then RMAN checks each read-only file on disk to ensure that it is already current at the desired point in time. If CHECK
READONLY
is not specified, then RMAN skips read-only files completely during the RECOVER
command.
You must open the database with the RESETLOGS
option after incomplete recovery or recovery with a backup control file.
If RMAN is unable to restore files needed for the recovery operation from the first backup it tries, it uses restore failover to try to restore the file from other suitable backups. See Oracle Database Backup and Recovery Advanced User's Guide for details on restore failover.
If the recovery operation requires that RMAN restore archived log redo or incremental backups from backup, then you must either configure channels for the devices from which files are to be restored (disk or SBT) or use ALLOCATE CHANNEL commands in a RUN
block with your RECOVER
command.
You must have already configured a device type with the CONFIGURE DEVICE
TYPE
command (except for DISK
, which is preconfigured) before specifying the DEVICE
TYPE
option.
You cannot manually allocate channels and then run RECOVER
with the DEVICE
TYPE
option.
If incremental backups or archived logsis need to be restored during recovery, then you must either use configured channels or manually allocate channels of the same type that created these backups.
RMAN can recover through RESETLOGS
operations transparently if the datafiles to be recovered are from a parent incarnation. If required, the RECOVER
command can also restore and apply archived logs and incremental backups from prior incarnations.
If, during recovery of a tablespace or database, the database encounters redo for adding a datafile, RMAN automatically creates a new datafile, unless the tablespace containing the added datafile is skipped during recovery. This situation can arise when a backup control file is restored prior to recovery, and the backup control file does not contain a record of the recently-added datafile.
When opening a database after recovery, any locally managed tempfiles recorded in the RMAN repository are re-created if necessary. If you are recovering using a backup control file and no recovery catalog, then tempfiles created after the control file backup are not recorded in the RMAN repository and are not created automatically.
If you want to perform DBPITR, the best practice is to enter a SET UNTIL
command before both the RESTORE and RECOVER
commands. If you run SET
UNTIL
after the RESTORE operation, then you may not be able to perform media recovery on the database to the target time, because the restored files may have time stamps later than the target time.
Syntax Element | Description |
---|---|
DEVICE TYPE deviceSpecifier |
Allocates automatic channels for the specified device type only. For example, if you configure automatic disk and tape channels, and issue RECOVER DEVICE TYPE DISK ... , then RMAN allocates only disk channels.
See Also: "deviceSpecifier" |
Syntax Element | Description |
---|---|
COPY OF |
Applies incremental backups to the specified image copy to roll it forward to any time equal to or before the most recent incremental backup of the file. The existing image copy is overwritten, and remains in a fuzzy state during the recovery. RECOVER COPY is a method for updating a copy and is not a media recovery of a current database file. This command is meant to be used in conjunction with the BACKUP... FOR RECOVER OF COPY syntax, to implement a strategy using incrementally updated backups.
The following requirements must be met:
RMAN selects one suitable copy if there are multiple possible copies to which the incrementals can be applied to carry out the operation. Note: RMAN issues a warning (not an error) if it cannot recover to the specified time (or current time if none is specified) because no incrementals are available. |
WITH TAG 'tag_name' |
Specifies a tag name to identify the image copy to be rolled forward. |
DATAFILECOPY |
Applies incremental backups to the specified datafile image copy. Refer to description of RECOVER COPY OF .. |
SKIP [FOREVER] TABLESPACE |
Specifies tablespaces that should not be recovered, which is useful for avoiding recovery of tablespaces containing only temporary data or for postponing recovery of some tablespaces. The SKIP clause takes the datafiles in the specified tablespaces offline before starting media recovery. These files are left offline after the media recovery is complete.
If you perform incomplete recovery, then |
untilClause | Specifies a past time, SCN, or log sequence number for termination of the RECOVER command. When used with one or more tablespaces, indicates a TSPITR operation for the named tablespaces. It cannot be used with RECOVER DATAFILE . It should not be used for RECOVER DATABASE (see "Restrictions and Usage Notes" for details). After DBPITR, you must open the database with the RESETLOGS option.
See Also: "untilClause" |
Syntax Element | Description |
---|---|
DATABASE |
Specifies that the entire database is to be recovered. By default, RMAN performs complete recovery. For incomplete recovery, specify an untilClause . |
DATAFILE datafileSpec |
Specifies a list of one or more datafiles to recover. Specify datafiles by either filename (by using a quoted string) or absolute datafile number (by using an integer).
If you are using the control file as the exclusive repository for RMAN metadata, then the filename must be the name of the datafile as recorded in the control file. If you are using a recovery catalog, then the filename of the datafile must be the most recent name recorded in the catalog, even if the name in the control file has been updated more recently. For example, assume that a datafile was renamed in the control file. The instance then fails before you can resynchronize the catalog. Specify the old name of the datafile in the RECOVER command, because this is the name recorded in the catalog. See Also: "datafileSpec" |
TABLESPACE 'tablespace_name' |
Specifies tablespaces by tablespace name. |
Syntax Element | Description |
---|---|
recoverOptionList |
Specifies various recovery options. |
ARCHIVELOG TAG = tag_name |
Specifies the tag for an archived log backup to be used during recovery. If the tagged backup does not contain all the necessary logs for recovery, RMAN uses logs or incremental backups as needed from whatever is available. Note that tag names are not case sensitive and display in all uppercase. |
AUXILIARY DESTINATION [ = ] ' location ' |
Can only be used when performing TSPITR. Used to automate the management of auxiliary set files during TSPITR. Specifies a location where auxiliary set datafiles, control files and online logs are created during TSPITR if another location for an individual file is not explicitly specified.
If you do not specify See also: The chapter on TSPITR in Oracle Database Backup and Recovery Advanced User's Guide for more details about the auxiliary destination. |
CHECK LOGICAL |
Tests data and index blocks that pass physical corruption checks for logical corruption, for example, corruption of a row piece or index entry. If RMAN finds logical corruption, it logs the block in the alert.log and server session trace file.
The If the total number of physical and logical corruptions detected for a file is less than its |
CHECK READONLY |
Checks the headers of read-only files to ensure that they are current before omitting them from the recovery. |
DELETE ARCHIVELOG [MAXSIZE integer [K|M|G]] |
Deletes archived logs restored from backups or copies that are no longer needed. RMAN does not delete archived logs that were already on disk before the RESTORE command started.
If you do not specify Note: If archived redo logs are restored to the flash recovery area then the |
FROM TAG = tag_name |
Specifies the tag for an incremental backup to be used during recovery. If the tagged backup does not contain all the necessary incrementals for recovery, then RMAN uses logs or incremental backups as needed from whatever is available. Note that tag names are not case sensitive and display in all uppercase.
See Also: "BACKUP" to learn how a tag can be applied to an individual copy of a duplexed backup set, and to learn about the default filename format for backup tags |
NOREDO |
Suppresses the application of redo logs during recovery. Only incremental backups are applied.
One use of this option is in updating full backups of Note: Incremental backups of Another use is in updating standby or duplicate databases. Incremental backups created with the |
TEST |
Use the TEST clause to conduct a trial recovery. A trial recovery is useful if a normal recovery procedure has encountered some problem. It lets you look ahead into the redo stream to detect possible additional problems. The trial recovery applies redo in a way similar to normal recovery, but it does not write changes to disk, and it rolls back its changes at the end of the trial recovery.
Note: You can use this clause only if you have restored a backup taken since the last RESETLOGS operation. Otherwise, the database returns an error. |
UNDO TABLESPACE |
Only for use with RECOVER TABLESPACE .
During TSPITR, RMAN needs information about which tablespaces had undo segments at the TSPITR target time. This information is usually available in the recovery catalog, if one is used. If there is no recovery catalog, or if the information is not found in the recovery catalog, RMAN proceeds assuming that the set of tablespaces with undo segments at the target time is the same as the set of tablespaces with undo segments at the present time. If this assumption is not correct, TSPITR fails with an error. In such a case, use this clause to provide a list of tablespaces with undo segments at the target time. |
ALLOW integer CORRUPTION |
The ALLOW integer CORRUPTION clause lets you specify, in the event of logfile corruption, the number of corrupt blocks that can be tolerated while allowing recovery to proceed.
When you use this clause during trial recovery (that is, in conjunction with the |
NOPARALLEL |
Specifies not to perform recovery in parallel. Parallel execution is the default for RECOVER . |
PARALLEL [ integer ] |
Specifies to perform recovery in parallel (the default).
By default, the database determines the optimal degree of parallelism, which is the number of parallel threads used in the recovery operation. It is generally not necessary for you to specify the degree of parallelism. However, you can specify the degree of parallelism directly by including the For more complete information on |
Recovering a Tablespace in an Open Database: Example The following example takes tablespace tools
offline, uses automatic channels to restore and recover it (deleting the logs that it restored from tape), then brings it back online:
SQL "ALTER TABLESPACE tbs_1 OFFLINE IMMEDIATE"; RESTORE TABLESPACE tbs_1; # restore only 2M of logs at a time, then delete them RECOVER TABLESPACE tools DELETE ARCHIVELOG MAXSIZE 2M; SQL "ALTER TABLESPACE tools ONLINE";
Recovering Datafiles Restored to New Locations: Example The following example uses the preconfigured disk channel and manually allocates one media management channel to use datafile copies on disk and backups on tape, and restores one of the datafiles in tablespace users
to a different location:
RMAN> RUN { ALLOCATE CHANNEL dev2 DEVICE TYPE sbt; SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE"; SET NEWNAME FOR DATAFILE '?/oradata/trgt/users01.dbf' TO '/tmp/users01.dbf'; RESTORE TABLESPACE users; SWITCH DATAFILE ALL; RECOVER TABLESPACE users; SQL "ALTER TABLESPACE users ONLINE"; }
Performing DBPITR with a Backup Control File and Recovery Catalog: Example Assume that all datafiles and control files as well as archived redo log 40 were lost due to a disk failure. Also assume that you do not have incremental backups. You need to recover the database with available archived redo logs. You do not need to restore tablespace history
because it has not changed since log 40. After connecting to the target and recovery catalog, follow the example shown here:
RMAN> STARTUP FORCE NOMOUNT; RMAN> RUN { SET UNTIL SEQUENCE 40 THREAD 1; # Recover database until log sequence 40 RESTORE CONTROLFILE; ALTER DATABASE MOUNT; RESTORE DATABASE SKIP TABLESPACE temp, history; RECOVER DATABASE SKIP FOREVER TABLESPACE temp; } RMAN> ALTER DATABASE OPEN RESETLOGS;
If the database uses locally-managed temporary tablespaces, and you restore a backup control file, and you do not have a recovery catalog, then you must add tempfiles to these tablespaces afterwards, using the SQL ALTER TABLESPACE
... ADD TEMPFILE
command:
RMAN> SQL "ALTER TABLESPACE temp ADD TEMPFILE ''?/oradata/trgt/temp01.dbf'' REUSE";
RECOVER an Image Copy of a Datafile to a Point in Time: Example Assume that you have an image copy backup of a datafile and you want to roll it forward in time using incremental backups. Use RECOVER
DATAFILECOPY
with the UNTIL
TIME
option. For example, run the following command:
RMAN> RECOVER DATAFILECOPY '/disk1/3img.df' UNTIL TIME 'SYSDATE-7';
Available incremental backups are applied to the datafile copy to recover it to the desired point in time. Redo from the archived redo logs is not applied by this command.