RMAN高级恢复.doc

RMAN 高级恢复
1. 不完全恢复
2. 基于RMAN 的恢复主题
3. 表空间时间点恢复
4. 验证备份可恢复
5. 跨平台的数据库移动和RMAN

一． 不完全恢复
不完全恢复是指不完全的数据恢复，不完全恢复与完全恢复在许多方面是相同的，他们基本的命令集相同，但不完全恢复添加了一些其他命令。 引起不完全恢复的原因有很多，如丢失了联机重做日志或归档的重做日志，或者出现重大的用户错误。 不完全恢复会影响整个数据库，换句话，不能只对数据库的一部分执行不完全恢复操作，因为这个会使数据库的一部分具有与这个数据库其余部分不同的SCN和时间点。
要将数据库数据还原到与数据库剩余部分不同的时间点，可以用基于 表空间时间恢复 或者用 闪回技术。 
不完全恢复方法包括：基于时间，SCN，日志序列 或取消的恢复。

1.1 使用resetlogslogs 命令
在不完全恢复期间，通常需要使用resetlogs命令打开数据库，这是因为我们要从已经简历的现有日志流中脱离出来，并且需要向Oracle 说明这种情况. Resetlogs 命令表示一个数据库逻辑生存期的结束和另一个数据库逻辑生存期的开始. 数据库的逻辑生存期也称为一个对应物(Incarnation). 每次使用resetlogs命令都会创建一个新的数据库对应物,这对于恢复操作来说非常重要. 
每次使用resetlogs命令时,SCN 计数器不会被重置,不过Oracle 会重置其他计数器(如:日志序列号),同时还会重置联机重做日志的内容.
Oracle 10g 简化了通过resetlogs命令进行的恢复，在归档的重做日志名中添加了一个新的特换串（%r），该字符串表示resetlog ID 号。 在log_archive_dest_format 参数串中包括%r时，归档的重做日志名在每个resetlogs 命令中保持唯一。 这种改动以及其他的内部Oracle 数据库改动使oracle 可以很容易的通过给定的resetlogs操作恢复数据库。 因此，可以很容易的在执行操作后立刻备份数据库，然而我们仍然认为在任何不完全恢复后备份数据库是很有必要的。

Oracle Rman跨resetlogs版本恢复

1.2 建立恢复点
使用RMAN执行不完全恢复操作时需要完成一个工作是简历恢复目标。恢复目录是恢复进程的终点，通常我们基于一个时间点，一个指定的SCN 或者 一个日志序列号来表示它。 我们可以采用许多不同的方法建立恢复目标。 

1.2.1 在run 代码块中使用set 命令与until time，until SCN 或 until sequence参数
Run
{
Set until time "to_date('2010-07-05 14:02:00','yyyy-mm-dd hh24:mi:ss')";
Restore database;
Recover database alter database open resetlogs;
}
执行这条命令时，RMAN 会查找与恢复目标时间最近（并非恢复目标时间本身也不能是位于恢复目标之间的时间）的备份集，并且从这个备份集中还原数据库。 如果数据库置于noarchivelog 模式中，恢复操作会在备份集的时间停止；否则在执行recover命令期间，oracle 会在所定义的恢复目标（不包含恢复目标本身）上应用归档的重做日志（以及需要应用的任何增量备份）。
注意： 如果尝试恢复到特定备份的完成点，则必须恢复到备份集中文件的CKP SCN 或 CKP TIME，在不同备份集的RMAN list命令中会列出这些内容。 有时使用备份的CKP TIME 并不够，还可能导致ORA-1152错误。

1.2.2 在restore 和recover 命令中直接使用until time，until SCN 和 until sequence 参数
这种方法避免使用run 代码块，也倾向与使用这种方法。 
Startup mount;
Restore database until time "to_date('2010-07-05 14:02:00','yyyy-mm-dd hh24:mi:ss')";
Recover database until time "to_date('2010-07-05 14:02:00','yyyy-mm-dd hh24:mi:ss')";
Alter database open resetlogs;
1.3 基于时间的恢复
这种恢复类型允许用户将数据库恢复到与指定时间一致的状态。 当然，如果不存在能将数据库还原到用户请求的时间的有效备份或归档重做日志，Oracle 就会报RMAN-03002 和 RMAN-20207的错误。
必须具备在我们指定的恢复时间之前生成的数据库备份，此外还需要所有归档的重做日志。

1.4 基于SCN 的恢复
Oracle 允许用户将数据库恢复到指定的SCN，实际上，这并不是一种常见的恢复方法。示例如下：
Startup mount;
Restore database until SCN 1000;
Recover database until SCN 1000;
Alter database open resetlogs;

注意： 该示例可以将数据库还原到SCN 1000，但是不会包含SCN.

1.5 基于日志序列的恢复
RMAN 允许用户将数据库恢复到指定序列号的归档重做日志。如果归档的重做日志中存在间隙，使用这种恢复方法就非常方便。 间隙通常意味着我们只能将数据库还原到间隙的开始点。 
Startup mount;
Restore database until sequence 100 thread 1;
Recover database until sequence 100 thread 1;
Alter database open resetlogs;

二． 基于RMAN 的恢复主题

2.1 只读表空间的恢复
在默认情况下，即使丢失了只读的数据文件，RMAN也不会在执行完全恢复数据库还原操作时还原只读的数据文件。 要在完全恢复期间还原只读的数据文件，就必须在restore 命令中使用check readonly 参数，如：
Restore database check readonly;

注意，执行recover tablespace或recover datafile命令时，RMAN的工作情况是不一样的。 使用这两个命令时，不管表空间是否为只读状态都会执行恢复操作。

2.2 归档重做日志的还原
在使用RMAN的普通恢复过程中，不必恢复归档的重做日志。 不过，偶尔也会要求还原一个或多个归档的重做日志。 例如，我们可能需要使用LogMiner 在备份中存储的归档重做日志文件里查找一些信息。
Restore archivelog all;
Restore archivelog from logseq=20 thread=1;
Restore archivelog from logseq=20 until logseq=30 thread=1;

还可以将归档的重做日志还原到默认位置以外的位置上：
Run
{
Set archivelog destination to "d:/arch";
Restore archivelog all;
}

注意：1. 上例中的set 命令没有替代方法，必须要求使用set。 
  2. 如果RMAN 认为一个归档的重做日志已存在，就不会在磁盘上还原这个归档的重做日志，即使设置的还原位置不同与默认的归档日志位置，Oracle 也不会在这个新的位置上恢复归档的重做日志。

2.3 数据文件副本的还原
可以从数据文件副本（不是备份集）中还原数据库的数据文件。 要实现这个功能，需要先使用restore from datafilecopy命令，然后再使用恢复数据库（或表空间，数据文件）的recover。
RMAN>Restore (datafile 5) from datafilecopy;  -- 此处的圆括号是必须的，如果没有就报错
RMAN>Recover datafile 5;
SQL>Alter database datafile 5 online;

执行restore 时，该命令会识别需要还原的数据文件的最新副本，然后从这个副本中还原这些数据文件。 数据文件的最新副本可能是在一个数据文件副本中，而不是在一个副本中。 在这种情况下，Oracle 会恢复这个数据文件副本。 

2.4 恢复讹误的数据块
即使与讹误数据块关联的数据文件一直联机，也可以通过用块介质恢复（block Media recover： BMR）执行块级别恢复操作来修复Oracle 数据库中的这些逻辑上或者物理上的讹误数据块。
一般出现数据块错误时，都会有错误消息：
ORA-01578: ORACLE data block corrupted (file #18,block #88)

如果没有BMR时，我们必须从一个备份中恢复这个数据文件，在恢复过程中，用户不能使用该数据块文件中的所有数据。
用BMR恢复就很简单，只需要执行blockrecover命令即可：
Blockrecover datafile 18 block 88;

如果有必要，可以同时恢复多个数据文件的多个数据块。如：
Blockrecover datafile 18 block 16,17,88,108;
Blcokrecover datafile 18 block 88 datafile 19 blcok 188;

Oracle 会跟踪在备份和恢复期间发生的数据块讹误。如果检测到备份或复制操作出现讹误，由于Oracle 不允许在备份中出现讹误，所有这个备份就会失败。 当然，可以配置RMAN允许一定数量的讹误，但是不推荐这种用法。
可以使用backup validate database 命令查看RMAN 检测到的所有数据库讹误。这条命令会在v$backup_corruption 和v$database_block_corruption视图中填充检测到的所有讹误数据块。 如果讹误发生在复制操作期间，v$copy_corruption视图就会指明包含讹误的备份集。
注意的是：v$backup_corruption 是一个显示历史讹误的视图v$database_block_corruption 则是一个显示当前数据块讹误的视图。 一旦修正了数据库的块讹误，就需要重新运行backup validate database命令，然后查询v$database_block_corruption 视图以确保不存在其他讹误。
查询v$database_block_corruption视图可以查看讹误数据块的详细信息。 如下所示，使用具有corruption list restore 参数的blockrecover命令可以方便地修正v$database_block_corruption 视图中的讹误数据块。
Blockrecover corruption list restore until time 'SYSDATE-5';
这条命令将还原讹误列表中最近5天的所有讹误数据块。 在上面的命令中，还可以使用until time 和 until sequence.

2.5 恢复前一个对应物
一个数据库的对应物（incarnation）对应这个数据库的特定逻辑生存期。 有时我们需要使用上次执行resetlogs命令打开数据库前生成的一个备份来还原数据库，或者可能需要还原到执行上一个resetlogs命令之前的时间点。 这就需要用到incarnation.

2.5.1 使用恢复目录恢复前一个对应物
 先假设使用恢复目录执行了备份操作，并且最近使用了resetlogs命令执行过时间点恢复，现在需要使用执行resetlogs命令之前的一个备份来恢复数据库。
操作步骤：
（1）启动但不加载实例，这是因为我们要先得到一个与恢复数据库对应物关联的控制文件
（2）使用reset database to incarnation 命令为RMAN 指示对应物的备份集。
（3）Restore controlfile，使rman还原最新的控制文件
（4）加载数据库
（5）Restore 数据库
（6）Recover 数据库
（7）使用resetlogs 打开数据库
示例如下：
C:/Users/Administrator.DavidDai>rman target / catalog rman/rman@orcl;
恢复管理器: Release 11.2.0.1.0 - Production on 星期二 7月 6 10:31:40 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
连接到目标数据库: ORCL (DBID=1247395743)
连接到恢复目录数据库
RMAN> list incarnation;
数据库原型列表
DB 关键字  Inc 关键字 DB 名  DB ID            STATUS  重置 SCN  重置时间
------- ------- -------- ---------------- --- ---------- ----------
2       12      ORCL     1250808537       PARENT  1          30-8月 -05
2       4       ORCL     1250808537       PARENT  534907     30-6月 -10
2       323     ORCL     1250808537       CURRENT 940996     06-7月 -10
RMAN> startup force nomount;
RMAN> reset database to incarnation 4;
RMAN> restore controlfile;
RMAN>alter database mount;
RMAN>restore database until scn 940990;
RMAN>recover database until scn 940990;
RMAN>alter database open resetlogs;

2.5.2 不使用恢复目录恢复前一个对应物
为了通过前一个对应物进行恢复，需要一个包含前一个对应物信息的控制文件。在大多数情况下，这可能是当前的控制文件。如果当前的控制文件不了解需要恢复的对应物，则需要还原包含该信息的控制文件，从而使得利用该方法恢复数据。 可以使用list incarnation of database 命令查看控制文件了解哪些对应物.
没有连接恢复目录的list incarnation 输出与已连接恢复目录时的list incarnation 输出有一些细微的区别。 这是因为信息从控制文件中获得的，因此某些键（如Inc key）将会不同。
操作步骤如下：
（1）从RMAN中运行list incarnation 命令，确定希望复位到哪个对应物
（2）关闭数据库
（3）启动加载数据库
（4）执行reset database to incarnation 命令复位对应物
（5）使用restore 命令还原数据库
（6）recover恢复数据库
（7）使用resetlogs 打开数据库

示例如下：
RMAN> list incarnation of database;
数据库原型列表
DB 关键字  Inc 关键字 DB 名  DB ID            STATUS  重置 SCN  重置时间
------- ------- -------- ----------- --- ---------- ----------
1       1       ORCL     1247395743       PARENT  1          02-4月 -10
2       2       ORCL     1247395743       PARENT  940976     21-5月 -10
3       3       ORCL     1247395743       ORPHAN  8426617    06-7月 -10
4       4       ORCL     1247395743       CURRENT 8554968    06-7月 -10
RMAN>shutdown immediate;
RMAN>startup mount;
RMAN> reset database to incarnation 2;
将数据库重置为原型 2
RMAN> restore database until time "to_date('2010-7-5 23:50:39','yyyy-mm-dd hh24:mi:ss')";
启动 restore 于 06-7月 -10
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00001 还原到 D:/APP/ADMINISTRATOR/ORADATA/ORCL/SYSTEM01.DBF
通道 ORA_DISK_1: 将数据文件 00002 还原到 D:/APP/ADMINISTRATOR/ORADATA/ORCL/SYSAUX01.DBF
通道 ORA_DISK_1: 将数据文件 00003 还原到 D:/APP/ADMINISTRATOR/ORADATA/ORCL/UNDOTBS01.DBF
通道 ORA_DISK_1: 将数据文件 00004 还原到 D:/APP/ADMINISTRATOR/ORADATA/ORCL/USERS01.DBF
通道 ORA_DISK_1: 将数据文件 00005 还原到 D:/APP/ADMINISTRATOR/ORADATA/ORCL/DAVE0.DBF
通道 ORA_DISK_1: 正在读取备份片段 F:/BACKUP/ORCL_1GLI2EN5_1_1.BAK
通道 ORA_DISK_1: 段句柄 = F:/BACKUP/ORCL_1GLI2EN5_1_1.BAK 标记 = TAG20100705T232732
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:01:45
完成 restore 于 06-7月 -10
RMAN> recover database until time "to_date('2010-7-5 23:50:39','yyyy-mm-dd hh24:mi:ss')";
启动 recover 于 06-7月 -10
使用通道 ORA_DISK_1
正在开始介质的恢复
线程 1 序列 156 的归档日志已作为文件 D:/ARCHIVELOG/ORCL_1_156_719615012.ARC 存在于磁盘上
归档日志文件名=D:/ARCHIVELOG/ORCL_1_156_719615012.ARC 线程=1 序列=156
介质恢复完成, 用时: 00:00:02
完成 recover 于 06-7月 -10
RMAN> alter database open resetlogs;
数据库已打开
RMAN> list incarnation;
数据库原型列表
DB 关键字  Inc 关键字 DB 名  DB ID            STATUS  重置 SCN  重置时间
------- ------- -------- ---------------- --- ---------- ----------
1       1       ORCL     1247395743       PARENT  1          02-4月 -10
2       2       ORCL     1247395743       PARENT  940976     21-5月 -10
3       3       ORCL     1247395743       ORPHAN  8426617    06-7月 -10
4       4       ORCL     1247395743       CURRENT 8554968    06-7月 -10

注： until 后面可以跟三种类型： 
1. restore database until time "to_date('2010-7-5 23:50:39','yyyy-mm-dd hh24:mi:ss')";
2. recover database until scn 1000
3. recover database until sequence 150;
查看sequence:
SQL> select sequence# from v$archived_log;
 SEQUENCE#
       161
       162
         1
         2
         3
         4
从这个结果也证明resetlogs 会重置sequnce，但是scn不会被重置。

查看scn：
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
8555698
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
 8555706

三． 表空间时间点恢复
表空间时间点恢复，TSPITR: tablespace point-in-time recovery.   Oracle 官网文档的连接地址：
RMAN Tablespace Point-in-Time Recovery (TSPITR)

使用表空间时间点恢复(TSPITR)可以将一个或多个非SYSTEM表空间恢复到与数据库其他部分不同的某个时间点上。这点和Flashback 有点类型。 比如用户误删了3张表，我们就可以用TSPITR恢复。

先看TSPITR 的工作流程，如下图所示：
（1） 在辅助实例上用target的备份集restore 数据文件
（2） 在辅助库上用target的归档文件recover 数据文件

（3） 在辅助库上导出相关数据
（4） 修改主库的控制文件
（5） 用辅助库上导出文件导入辅助库上。

几个相关相关的定义：
辅助实例(Auxiliary instance)：我们创建的临时实例，RMAN可以使用这个实例执行TSPITR，完成TSPITR操作后，可以删除辅助实例。
辅助数据库(Auxiliary database)：主数据库的一个复本或子集，用于表空间的临时恢复。
主数据库(Primary database)：需要TSPITR的数据库。
恢复集(Recovery set)：构成恢复到某一个时间点表空间的表空间或数据文件，SYSTEM表空间数据文件不能作为恢复集的一部分。
辅助集(Auxiliary set)：需要执行TSPITR的其他目标数据库文件集。 辅助集包括备份控制文件，回滚和撤销段表空间数据文件，system表空间数据文件，辅助数据库的联机重做日志，以及一个可选的位于辅助数据库中的临时的表空间。
目标实例（target instance）：包含将要恢复的表空间

3.1 执行自动的TSPITR

3.1.1 为TSPITR 做准备
在开始执行TSPITR之前需要完成一些步骤。 
（1） 确定还原的时间点
这是最关键的因素。 我们需要认真对待这项操作，因为如果没有使用恢复目录，则表空间的恢复是一次性的过程。 如果错误地标识了恢复的时间点，则不能重新来过。 如果使用恢复目录，则不存在这种限制。

（2） 确定传送集中的对象是自包含的
应该使用TS_PITR_CHECK 视图来确保恢复集是完整的，并且标识所有可能要用到的其他表空间。 首先需要检查TS_PITR_CHECK 视图来确保没有其他相关的表空间。 比如我们检查DAVE 表空间，示例代码如下：
/* Formatted on 2010/7/7 17:10:00 (QP5 v5.115.810.9015) */
SELECT   obj1_owner,
         obj1_name,
         obj1_type,
         reason
  FROM   sys.ts_pitr_check
 WHERE   (ts1_name IN ('BL') AND ts2_name NOT IN ('BL'))
         OR (ts1_name NOT IN ('BL') AND Ts2_Name IN ('BL'))

如果没有冲突，则不会返回任何行。 如果存在冲突，则会看到描述的每个冲突的行。如果有冲突，我们也需要还原关联的表空间。

（3） 保存可能丢失的对象或数据
如果我们将Dave表空间恢复之前的某个时间，那么在这个时间以后的任何更改，如新建对象，更新，插入或者删除，都会丢失。 丢失这些对象可能没有问题，但假设我们需要保存这些数据，则需要导出将要保存的数据，或者将数据复制到数据库中的其他位置。 Oracle 提供了视图 TS_PITR_OBJECTS_TO_BEDROPPED, 该视图列出了将在恢复操作期间丢失的所有对象。 使用该视图可以确定表空间中的对象在恢复之后的状态。

SQL> col owner format a10
SQL> col name format a10
SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
SQL> SELECT  *  FROM   ts_pitr_objects_to_be_dropped WHERE  tablespace_name = 'BL' ;

OWNER      NAME       CREATION_TIME       TABLESPACE_NAME
---------- ---------- ------------------- ------------------------------
BL         BL         2010-07-07 19:24:18    BL

3.1.2 执行实际的TSPITR
Oracle Database 10g将为我们执行自动的TSPITR，这意味着它将创建辅助实例。 在这种情况下，我们只需要连接目标数据库和可选的恢复目录（如果有的话），并且执行recover tablespace 命令。 RMAN 将为我们完成剩余的工作。
下面演示使用recover tablespace 命令恢复BL 表空间的示例。 我们使用可选的auxiliary destination来指示RMAN 和 Oracle 应该在何处创建与辅助数据库关联的文件。 使用该参数使得该恢复成为一个具有自动化实例的自定义TSPITR。 如果没有使用该参数，TSPITR 就称为完全自动的TSPITR 恢复。
需要注意的是，如果使用auxiliary destination参数，则应该已经创建了目标目录，并且Oracle 必须能够写入到该目标目录。 在目标路径名中没有后缀的斜杠（/或/）,如果包含斜杠将会导致TSPITR失败，并且获得错误消息无法确切地描述该问题。命令如下：

Recover tablespace BL until time "to_date('2010-7-7 20:38:18','yyyy-mm-dd hh24:mi:ss')" auxiliary destination 'F:/bl'

在执行这个命令之前有几点注意的地方，因为TSPITR 会用已经存在的备份集和归档文件来创建辅助数据库所以在执行该命令之前需要确认target 数据库有备份和归档，并且控制文件也要有备份。 

RMAN> Recover tablespace BL until time "to_date('2010-7-7 20:40:18','yyyy-mm-dd hh24:mi:ss')" auxiliary destination 'F:/bl';
启动 recover 于 07-7月 -10
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=145 设备类型=DISK
RMAN-05026: 警告: 假定以下表空间集适用于指定的时间点
表空间列表要求具有 UNDO 段
表空间 SYSTEM
表空间 UNDOTBS1
使用 SID='iEfs' 创建自动实例  -- 这里是系统自动创建的辅助数据库名
供自动实例使用的初始化参数:
db_name=BL
db_unique_name=iEfs_tspitr_BL
compatible=11.2.0.0.0
db_block_size=8192
db_files=200
sga_target=280M
processes=50
db_create_file_dest=F:/bl
log_archive_dest_1='location=F:/bl'
#No auxiliary parameter file used
启动自动实例 BL
Oracle 实例已启动
系统全局区域总计     292933632 字节
Fixed Size                     1374164 字节
Variable Size                100665388 字节
Database Buffers             184549376 字节
Redo Buffers                   6344704 字节
自动实例已创建
对恢复集表空间运行 TRANSPORT_SET_CHECK
TRANSPORT_SET_CHECK 已成功完成
内存脚本的内容:
{
# set requested point in time
set until  time "to_date('2010-7-7 20:40:18','yyyy-mm-dd hh24:mi:ss')";
# restore the controlfile
restore clone controlfile;
# mount the controlfile
sql clone 'alter database mount clone database';
# archive current online log
sql 'alter system archive log current';
# avoid unnecessary autobackups for structural changes during TSPITR
sql 'begin dbms_backup_restore.AutoBackupFlag(FALSE); end;';
}
正在执行内存脚本
正在执行命令: SET until clause
启动 restore 于 07-7月 -10
分配的通道: ORA_AUX_DISK_1
通道 ORA_AUX_DISK_1: SID=59 设备类型=DISK
通道 ORA_AUX_DISK_1: 正在开始还原数据文件备份集
通道 ORA_AUX_DISK_1: 正在还原控制文件
通道 ORA_AUX_DISK_1: 正在读取备份片段 D:/APP/ADMINISTRATOR/FLASH_RECOVERY_AREA/B
L/AUTOBACKUP/2010_07_07/O1_MF_S_723759094_638VQR8R_.BKP
通道 ORA_AUX_DISK_1: 段句柄 = D:/APP/ADMINISTRATOR/FLASH_RECOVERY_AREA/BL/AUTOBA
CKUP/2010_07_07/O1_MF_S_723759094_638VQR8R_.BKP 标记 = TAG20100707T201134
通道 ORA_AUX_DISK_1: 已还原备份片段 1
通道 ORA_AUX_DISK_1: 还原完成, 用时: 00:00:02
输出文件名=F:/BL/BL/CONTROLFILE/O1_MF_638Y5Y3J_.CTL
完成 restore 于 07-7月 -10
sql 语句: alter database mount clone database
sql 语句: alter system archive log current
sql 语句: begin dbms_backup_restore.AutoBackupFlag(FALSE); end;
内存脚本的内容:
{
# set requested point in time
set until  time "to_date('2010-7-7 20:40:18','yyyy-mm-dd hh24:mi:ss')";
# set destinations for recovery set and auxiliary set datafiles
set newname for clone datafile  1 to new;
set newname for clone datafile  3 to new;
set newname for clone datafile  2 to new;
set newname for clone tempfile  1 to new;
set newname for datafile  5 to
 "D:/APP/ADMINISTRATOR/ORADATA/BL/B