Oracle-策略-RMAN（恢复管理器）-RECOVER（恢复）

    使用恢复命令可以执行下列任务之一:

• 执行整个数据库或一个或多个已恢复的数据文件的完全恢复
• 执行数据库(DBPITR)或表空间(TSPITR)的时间点恢复
• 将增量备份应用到数据文件映像副本(而不是已恢复的数据文件)，以便及时前滚
• 在数据文件中恢复损坏的数据块或一组数据块

    以下先决条件适用于恢复块:

• 目标数据库必须在ARCHIVELOG模式下运行，并使用当前控制文件打开或挂载。
• 目标数据库不能是备用数据库。
• 只能恢复标记为媒体损坏的块。V$DATABASE_BLOCK_CORRUPTION视图指出文件中的哪些块被标记为损坏，WHICH最近的备份或备份对该文件运行了VALIDATE命令.
• 包含损坏块的数据文件的备份必须是完全备份，而不是代理备份。如果只有代理备份存在，那么您可以将它们恢复到磁盘上的非默认位置，在这种情况下，RMAN认为它们是数据文件副本。然后可以使用数据文件副本进行块媒体恢复。
• RMAN只能使用存档的重做日志进行恢复。块媒体恢复无法在丢失或无法访问的日志中存活，但有时可以在丢失或无法访问的记录中存活.

--Incremental Backups and Archived Redo Log Files（增量备份和归档重做日志文件）
With the exception of RECOVER BLOCK, RMAN can use both incremental backups and archived redo logs for recovery. RMAN uses the following search order:
     Incremental backup sets on disk or tape
     Archived redo logs on disk
     Archived redo log backups on disk
     Archived redo log backup sets on tape
When RMAN chooses a destination to restore archived redo logs, it uses the following order of precedence:
     SET ARCHIVELOG DESTINATION
     The LOG_ARCHIVE_DEST_n parameter whose value is set to LOCATION=USE_DB_RECOVERY_FILE_DEST
     LOG_ARCHIVE_DEST_1
RMAN can apply incremental backups to datafiles that were not restored from an incremental backup. 
If overlapping levels of incremental backup exist, then RMAN automatically chooses the level covering the longest period of time.
--Recovery Through RESETLOGS（通过RESETLOGS恢复）
You must RESTORE datafiles before you can recover them. 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 previous database incarnations, even if those logs were generated in previous releases of Oracle Database.
When recovering through an OPEN RESETLOGS, ensure that you have all logs needed for recovery. 
In a previous database incarnation, you must have the logs from the time of the backup until the SCN that is 1 less than the RESETLOGS SCN. 
The incarnation table must have a complete history of RESETLOGS operations from the creation time of the database backup. 
If the complete metadata is not found in V$DATABASE_INCARNATION, then you can re-create this metadata by using CATALOG for the archived redo logs from the missing incarnations.

Example 2-95 Recovering a Tablespace in an Open Database

Assume that the disk containing the datafiles for tablespace users becomes unavailable because of a hardware error, but is repaired after a few minutes. This example takes tablespace users offline, uses automatic channels to restore the datafiles to their default location and recover them (deleting the logs that it restored from tape), then brings the tablespace back online.

SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
RESTORE TABLESPACE users;
RECOVER TABLESPACE users DELETE ARCHIVELOG MAXSIZE 2M;
SQL "ALTER TABLESPACE users ONLINE";
Example 2-96 Recovering Datafiles Restored to New Locations

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

RUN
{  
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;  
  SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";  
  SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf' 
    TO '/disk2/users01.dbf';
  RESTORE TABLESPACE users;
  SWITCH DATAFILE ALL;
  RECOVER TABLESPACE users;
  SQL "ALTER TABLESPACE users ONLINE";
}
Example 2-97 Performing DBPITR with a Backup Control File and Recovery Catalog

Assume that all datafiles and control files as well as archived redo log 58 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 tools because it has been read-only since before the most recent backup. After connecting RMAN to the target database and recovery catalog, issue the following commands:

STARTUP FORCE NOMOUNT;
RUN
{  
  SET UNTIL SEQUENCE 40 THREAD 1;  # Recover database until log sequence 40 
  RESTORE CONTROLFILE;
  ALTER DATABASE MOUNT;
  RESTORE DATABASE SKIP TABLESPACE temp;
  RECOVER DATABASE SKIP TABLESPACE temp;
}
ALTER DATABASE OPEN RESETLOGS;
Note that RMAN automatically skips the restore and recovery of datafile 8, which is the datafile in the read-only tablespace. The following portion of sample output indicates the skip:

using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=104 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
 
skipping datafile 8; already restored to file /disk1/oradata/prod/tools01.dbf
channel ORA_DISK_1: starting datafile backup set restore
.
.
.
Finished restore at 19-FEB-07 

Starting recover at 19-FEB-07
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1
datafile 8 not processed because file is read-only
Example 2-98 Incrementally Updating Backups

By incrementally updating backups, you can avoid the overhead of making full image copy backups of datafiles, while also minimizing time required for media recovery of your database. This example enables you to recover to any SCN within the previous week, but enables you to avoid having to apply more than one day of redo.

Assume you run the following script daily. On first execution, the script creates an image copy backup of the database on disk with the specified tag. On the second through the seventh execution, the script creates a level 1 backup of the database. On the eighth and all subsequent executions, RMAN applies the level 1 incremental to the datafile copy made 7 days ago and then makes a new level 1 backup with the changes from the previous day.

RUN
{
  RECOVER COPY OF DATABASE 
    WITH TAG 'incr_update' 
    UNTIL TIME 'SYSDATE - 7';
  BACKUP
    INCREMENTAL LEVEL 1 
    FOR RECOVER OF COPY WITH TAG 'incr_update'
    DATABASE;
}
Example 2-99 Recovery from Loss of a Control File on a Standby Database

Assume that the standby database dgprod3 control files are lost because of a media failure. The primary and standby database share SBT storage. A backup of the primary database control file exists on tape.

You start the RMAN client and connect to dgprod3 as TARGET and connect to the recovery catalog. The following RMAN commands restore a control file that is usable by the standby database, update the filenames to existing files on disk, and recover the standby database:

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RECOVER DATABASE;
You can then start redo apply on the standby database.

Example 2-100 Recovering a NOARCHIVELOG Database

You can perform limited recovery of changes to a database running in NOARCHIVELOG mode by applying incremental backups. The incremental backups must be consistent, like all backups of a database run in NOARCHIVELOG mode, so you cannot back up the database when it is open.

Assume that you run database prod in NOARCHIVELOG mode with a recovery catalog. You shut down the database consistently and make a level 0 backup of database prod to tape on Sunday afternoon. You shut down the database consistently and make a level 1 differential incremental backup to tape at 3:00 a.m. on Wednesday and Friday.

On Saturday, a media failure destroys half of the datafiles as well as the online redo logs. Because the online logs are lost, you must specify the NOREDO option in the RECOVER command. Otherwise, RMAN searches for the redo logs after applying the Friday incremental backup and issues an error message when it does not find them.

After connecting RMAN to prod and the catalog database, recover as follows:

STARTUP FORCE NOMOUNT;
RESTORE CONTROLFILE;      # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE;         # restore datafiles from consistent backup
RECOVER DATABASE NOREDO;  # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;
The recovered database reflects only changes up through the time of the Friday incremental backup. Because there are no archived redo logs, there is no way to recover changes made after the incremental backup.