RECOVER

Syntax

recover::=

recoverObject::=

dbObject::=

recoverOptionList::=

sizeSpec::=

Purpose

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.

Restrictions and Usage Notes

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

Keywords and Parameters

recover

recoverObject

dbObject

recoverOptionList

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