RECOVER

Syntax

recover::=

Text description of recover.gif follows

Text description of recover

recoverObject::=

Text description of recoverObject.gif follows

Text description of recoverObject

dbObject::=

Text description of dbObject.gif follows

Text description of dbObject

recoverOptionList::=

Text description of recoverOptionList.gif follows

Text description of recoverOptionList

sizeSpec::=

Text description of sizeSpec.gif follows

Text description of sizeSpec

Purpose

The RECOVER command has three 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 or image copies 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 redo logs. If RMAN has a choice between applying an incremental backup or applying redo, then it always chooses the incremental backup. If overlapping levels of incremental backup are available, then RMAN automatically chooses the one covering the longest period of time. RMAN can apply incremental backups to restored files that were not created as part of an incremental backup.

Note:

When RMAN applies incremental backups, it recovers changes to objects created with the NOLOGGING 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.

Restrictions and Usage Notes

Recovery is possible with a backup control file and no recovery catalog, but requires manual intervention if you added files to the database after the backup control file was created.
RMAN can recover through RESETLOGS operations transparently if the parent incarnation backups were restored. If required, the RECOVER command can also restore and apply archived logs and incremental backups from prior incarnations.
If, during recovery, the database encounters redo for adding a datafile, RMAN automatically creates a new datafile if the tablespace containing the added datafile is not 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.
If you need to restore archived log redo or incremental backups during your recovery operation, then you must either configure channels or use ALLOCATE CHANNEL commands in a RUN block with your RECOVER command.
You do not have to allocate a channel for archived log recovery because RMAN uses the preconfigured DISK channel. If incremental backups 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 uses restore failover to try all suitable backups, when it encounters difficulty restoring files needed for the recovery operation. See Oracle Database Backup and Recovery Advanced User's Guide for details on restore failover.
For datafile and tablespace recovery, the target database must be mounted. If it is open, then the datafiles or tablespaces to be recovered must be offline. For database recovery, the database must be mounted but not open.
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.
You cannot arbitrarily recover datafiles to different points in time. You can recover the whole database to a single point in time (DBPITR, in which case you should use SET 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 tOracle 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 .
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 omits read-only files.
You must open the database with the RESETLOGS option after incomplete recovery or recovery with a backup control file.
Temporary tablespaces cannot be recovered. They must be re-created. Note that if you recover the database after restoring a backup control file, you must add new tempfiles to locally-managed temporary tablespaces.
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.

Keywords and Parameters

recover

Syntax Element Description

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"

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"

recoverObject

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 is the other half of the incrementally updated backups feature, in conjunction with the `BACKUP... FOR RECOVER OF COPY` syntax. You must meet the following requirements: At least one copy of each datafile that you are recovering must exist. Backup incrementals taken after the image copy that you are recovering must exist. 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`	Lists 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 `SKIP` is not allowed. Instead, use `SKIP` `FOREVER`, with the intention of dropping the skipped tablespaces after opening the database with the `RESETLOGS` option. The `SKIP` `FOREVER` clause causes RMAN to take the datafiles offline with the `DROP` option. Only use `SKIP` `FOREVER` when the specified tablespaces will be dropped after opening the database.
`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"

dbObject

Syntax Element Description

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.

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.

recoverOptionList

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 `AUXILIARY DESTINATION` for a TSPITR, then you must specify the naming of individual auxiliary set datafiles, control files, and online logs before executing the `RECOVER TABLESPACE`... `UNTIL`... command. Otherwise, TSPITR will fail. 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. If the total number of physical and logical corruptions detected for a file is less than its `MAXCORRUPT` setting, the RMAN command completes and the database populates `V$DATABASE_BLOCK_CORRUPTION` with corrupt block ranges. Otherwise the command terminates without populating the views. Note: The `MAXCORRUPT` setting represents the total number of physical and logical corruptions permitted on a file.
`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 `MAXSIZE`, then RMAN deletes restored archived logs as they are applied. If you specify `MAXSIZE`, then RMAN will not use more than `integer` amount of disk space for restored archived logs. If recovery requires the restore of a log larger than the `MAXSIZE` value, then RMAN reports an error indicating that you should increase the `MAXSIZE` value. If `MAXSIZE` is smaller than the backup set containing the logs, then RMAN must read the backup set more than once to extract the logs. Hence, RMAN issues a warning that `MAXSIZE` should be increased. Note: If archived redo logs are restored to the flash recovery area then the `DELETE ARCHIVELOG` option is enabled by default.
`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--only incremental backups are applied. This option is intended for recovery of `NOARCHIVELOG` databases by using incremental backups. If you do not specify `NOREDO` when recovering a `NOARCHIVELOG` database, then the database terminates recovery and issues an error. Note: Incremental backups of `NOARCHIVELOG` databases can only be taken after a consistent shutdown.
`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.
`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 TEST clause), `integer` can exceed 1. When using this clause during normal recovery, `integer` can only be 0 or 1.
`NOPARALLEL`	Specifies not to perform recovery in parallel. Serial execution is the default for `RECOVER`.
`PARALLEL [``integer``]`	Specification of integer indicates the degree of parallelism, which is the number of parallel threads used in the parallel operation. Each parallel thread may use one or two parallel execution servers. Normally the database calculates the optimum degree of parallelism, so it is not necessary for you to specify `integer`. For more complete information on `PARALLEL` see the description of the PARALLEL clause in the discussion of CREATE TABLE in Oracle Database SQL Reference.

Examples

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 tools OFFLINE IMMEDIATE";
RESTORE TABLESPACE tools;
# 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. Because 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 530 THREAD 1;      # Recover database until log sequence 40 
  RESTORE CONTROLFILE TO '/tmp/control01.ctl';
  RESTORE CONTROLFILE FROM '/tmp/control01.ctl'; # Replicates to CONTROL_FILES locations
  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, then you must add tempfiles to these tablespaces after restoring a backup control file, using the SQL ALTER TABLESPACE... ADD TEMPFILE command:

RMAN> SQL "ALTER TABLESPACE temp ADD TEMPFILE ''?/oradata/trgt/temp01.dbf'' REUSE";

RECOVER and Incrementally Updated Backups: Example

Assume that at time t1 you create an image copy of datafile 3:

BACKUP FOR RECOVER OF COPY WITH TAG DATAFILE 3 FORMAT '/disk1/3img.df' TAG "DF3CPY";

You can also refer to the datafile copy by its tag, with this form of the command:

RMAN> RECOVER COPY OF DATAFILE 3 WITH TAG "DF3CPY";

At time t2, t3, and t4 you make incremental backups of the database. To roll forward the image copy of datafile 3 to the date of the latest incremental backup, use the RECOVER command. You can identify the datafile by its filename with this form of the command:

RMAN> RECOVER DATAFILECOPY '/disk1/3img.df';

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