RMAN备份恢复之归档日志对BLOCKRECOVER的影响
2008-11-27 20:49
369 查看
RMAN备份恢复之归档日志对BLOCKRECOVER的影响
| 上面一篇简单的介绍了一下RMAN的BLOCKRECOVER的用法，这篇打算介绍一下缺失归档日志对BLOCKRECOVER的影响。 为了演示归档对BLOCKRECOVER的影响，先构造一个例子： RMAN> backup tablespace tools; 启动 backup 于 16-6月 -07 使用通道 ORA_DISK_1 通道 ORA_DISK_1: 正在启动 full 数据文件备份集 通道 ORA_DISK_1: 正在指定备份集中的数据文件 输入数据文件 fno=00005 name=F:ORACLEORADATATEST1TOOLS01.DBF 通道 ORA_DISK_1: 正在启动段 1 于 16-6月 -07 通道 ORA_DISK_1: 已完成段 1 于 16-6月 -07 段 handle=F:ORACLEORACLE920DATABASEHIKFE30_1_1 comment=NONE 通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:03 完成 backup 于 16-6月 -07 首先备份一下表空间，这个表空间的备份用来作为BLOCKRECOVER的全备份基础。 SQL> CREATE TABLE TEST TABLESPACE TOOLS AS SELECT ROWNUM ID, A.* FROM DBA_OBJECTS A; 表已创建。 SQL> SELECT COUNT(*) FROM TEST; COUNT(*) ---------- 28036 SQL> SELECT ROWID FROM TEST WHERE ID = 1000; ROWID ------------------ AAAHApAAFAAAAAbAA8 SQL> SELECT ID FROM TEST 2 WHERE ROWID >= 'AAAHApAAFAAAAAbAAA' 3 AND ROWID < 'AAAHApAAFAAAAAcAAA'; ID ---------- 940 941 942 943 944 945 946 947 . . . 1004 1005 1006 已选择67行。 SQL> SELECT DISTINCT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID), 2 DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) 3 FROM TEST 4 WHERE ID >= 940 5 AND ID <= 1006; DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) ------------------------------------ ------------------------------------ 5 27 SQL> ALTER SYSTEM SWITCH LOGFILE; 系统已更改。 SQL> SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG; MAX(SEQUENCE#) -------------- 321 SQL> UPDATE TEST SET OBJECT_NAME = LOWER(OBJECT_NAME) WHERE ID = 1000; 已更新 1 行。 SQL> COMMIT; 提交完成。 SQL> ALTER SYSTEM SWITCH LOGFILE; 系统已更改。 SQL> DELETE TEST WHERE ID = 1; 已删除 1 行。 SQL> COMMIT; 提交完成。 SQL> ALTER SYSTEM SWITCH LOGFILE; 系统已更改。 SQL> UPDATE TEST SET OBJECT_TYPE = 'TEST' WHERE ID = 10000; 已更新 1 行。 SQL> COMMIT; 提交完成。 SQL> ALTER SYSTEM SWITCH LOGFILE; 系统已更改。 SQL> CREATE TABLE TEST2 (ID NUMBER); 表已创建。 SQL> INSERT INTO TEST2 VALUES (1); 已创建 1 行。 SQL> ALTER SYSTEM SWITCH LOGFILE; 系统已更改。 SQL> ALTER SYSTEM SWITCH LOGFILE; 系统已更改。 SQL> ALTER SYSTEM SWITCH LOGFILE; 系统已更改。 SQL> ALTER SYSTEM SWITCH LOGFILE; 系统已更改。 SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE SEQUENCE# > 321; NAME ------------------------------------------------------------ F:ORACLEORADATATEST1ARCHIVELOGARC00322.001 F:ORACLEORADATATEST1ARCHIVELOGARC00323.001 F:ORACLEORADATATEST1ARCHIVELOGARC00324.001 F:ORACLEORADATATEST1ARCHIVELOGARC00325.001 F:ORACLEORADATATEST1ARCHIVELOGARC00326.001 F:ORACLEORADATATEST1ARCHIVELOGARC00327.001 F:ORACLEORADATATEST1ARCHIVELOGARC00328.001 已选择7行。 SQL> SELECT SEQUENCE# FROM V$LOG; SEQUENCE# ---------- 328 329 327 首先建立一张测试表，在这个表中，ID在940和1006之间的记录存储在DATAFILE 5 BLOCK 27中。在归档322中记录了TEST表的ID等于1000的记录的更新，这个更新发生在DATAFILE 5 BLOCK 27上。随后在归档323中，删除了ID等于1的记录，这条记录与BLOCK 27无关。在归档324中，更新了ID等于10000的记录，这个修改与BLOCK 27也无关。在归档325中，新建TEST2表，并插入数据。归档326就是一个空文件。 因此，除了归档322外，从323到325都与BLOCK 27的修改无关。根据Oracle的文档，这些归档的缺失将不会影响BLOCK 27的恢复。 为了验证文档的说法，下面将归档322到326修改名称，使得Oracle在恢复时无法找到归档日志。 最后执行的几次ALTER SYSTEM SWITCH LOGFILE操作，是确保SEQUENCE为326的联机重做日志已经被重用，避免Oracle利用联机重做日志来代替归档日志。 准备工作完毕，下面开始模拟坏块。仍然是通过UtralEdit对数据文件进行修改，先是定位数据块的偏移地址： SQL> SHOW PARAMETER BLOCK_SIZE NAME TYPE VALUE ------------------------------------ ----------- -------------------------- db_block_size integer 8192 SQL> SELECT TO_CHAR(8192 * 27, 'XXXXX') FROM DUAL; TO_CHA ------ 36000 下面对地址36000后面的数据进行修改，并保存。 执行SQL语句，可以看到下面的错误： SQL> SELECT COUNT(*) FROM TEST; SELECT COUNT(*) FROM TEST * ERROR 位于第 1 行: ORA-01578: ORACLE 数据块损坏（文件号5，块号27） ORA-01110: 数据文件 5: 'F:ORACLEORADATATEST1TOOLS01.DBF' 下面可以对损坏的数据块进行BLOCKRECOVER，注意这时归档322到326已经被修改名称。 RMAN> blockrecover datafile 5 block 27; 启动 blockrecover 于 17-6月 -07 正在使用目标数据库控制文件替代恢复目录 分配的通道: ORA_DISK_1 通道 ORA_DISK_1: sid=14 devtype=DISK 通道 ORA_DISK_1: 正在恢复块 通道 ORA_DISK_1: 正在指定要从备份集恢复的块 正在恢复数据文件 00005 的块 通道 ORA_DISK_1: 已从备份段 1 恢复块 段 handle=F:ORACLEORACLE920DATABASEHIKFE30_1_1 tag=TAG20070617T020728 params=NULL 通道 ORA_DISK_1: 块恢复已完成 正在开始介质的恢复 存档日志线程 1 序列 327 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00327.001 存在于磁盘上 存档日志线程 1 序列 328 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00328.001 存在于磁盘上 存档日志线程 1 序列 329 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00329.001 存在于磁盘上 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of blockrecover command at 06/17/2007 02:33:18 RMAN-06053: unable to perform media recovery because of missing log RMAN-06025: no backup of log thread 1 seq 326 scn 58749837 found to restore RMAN-06025: no backup of log thread 1 seq 325 scn 58749812 found to restore RMAN-06025: no backup of log thread 1 seq 324 scn 58749793 found to restore RMAN-06025: no backup of log thread 1 seq 323 scn 58749778 found to restore RMAN-06025: no backup of log thread 1 seq 322 scn 58749749 found to restore 这个错误的出现是正常的，由于归档322中包含了对BLOCK 27的修改，下面恢复归档322的原始名称，再次执行恢复： RMAN> blockrecover datafile 5 block 27; 启动 blockrecover 于 17-6月 -07 使用通道 ORA_DISK_1 通道 ORA_DISK_1: 正在恢复块 通道 ORA_DISK_1: 正在指定要从备份集恢复的块 正在恢复数据文件 00005 的块 通道 ORA_DISK_1: 已从备份段 1 恢复块 段 handle=F:ORACLEORACLE920DATABASEHIKFE30_1_1 tag=TAG20070617T020728 params=NULL 通道 ORA_DISK_1: 块恢复已完成 正在开始介质的恢复 存档日志线程 1 序列 327 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00327.001 存在于磁盘上 存档日志线程 1 序列 328 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00328.001 存在于磁盘上 存档日志线程 1 序列 329 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00329.001 存在于磁盘上 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of blockrecover command at 06/17/2007 02:36:18 RMAN-06053: unable to perform media recovery because of missing log RMAN-06025: no backup of log thread 1 seq 326 scn 58749837 found to restore RMAN-06025: no backup of log thread 1 seq 325 scn 58749812 found to restore RMAN-06025: no backup of log thread 1 seq 324 scn 58749793 found to restore RMAN-06025: no backup of log thread 1 seq 323 scn 58749778 found to restore 仍然报错，这说明文档上描述的BLOCKRECOVER可以跨越无关的日志的说法是有问题的。 下面依次恢复323、324的名称并测试发现仍然存在上面的问题。 最后恢复325的名称，目前仅归档326不可见，而这个归档是一个空归档，看看BLOCKRECOVER是否可以跳过空归档进行恢复。 RMAN> blockrecover datafile 5 block 27; 启动 blockrecover 于 17-6月 -07 使用通道 ORA_DISK_1 通道 ORA_DISK_1: 正在恢复块 通道 ORA_DISK_1: 正在指定要从备份集恢复的块 正在恢复数据文件 00005 的块 通道 ORA_DISK_1: 已从备份段 1 恢复块 段 handle=F:ORACLEORACLE920DATABASEHIKFE30_1_1 tag=TAG20070617T020728 param s=NULL 通道 ORA_DISK_1: 块恢复已完成 正在开始介质的恢复 存档日志线程 1 序列 327 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00327.001 存在于磁盘上 存档日志线程 1 序列 328 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00328.001 存在于磁盘上 存档日志线程 1 序列 329 已作为文件 F:ORACLEORADATATEST1ARCHIVELOGARC00329.001 存在于磁盘上 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of blockrecover command at 06/17/2007 02:41:16 RMAN-06053: unable to perform media recovery because of missing log RMAN-06025: no backup of log thread 1 seq 326 scn 58749837 found to restore 错误依旧，RMAN连一个空的归档都无法跳过，看来这块的文档描述和实际情况有很大的出入。 从这一点也反映出归档日志的重要性，如果丢失了归档日志，不管是常规恢复还是数据库的恢复都是无法进行的。 |
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- RMAN备份及恢复归档日志的语法
- RMAN备份与恢复—恢复归档日志、控制文件、参数文件
- Oracle 恢复[rman全备份集+当期归档日志]
- RMAN备份恢复 控制文件和归档日志丢失情况
- rman实验之归档模式无备份，正常关机丢失当前联机重做日志文件的恢复
- RMAN备份与恢复（3）——恢复归档日志、控制文件、参数文件！
- Oracle Database 12c RMAN全量+增量备份+归档日志恢复详解
- 归档模式下，使用RMAN的同一备份两次用于不完全恢复
- 怎样使用 RMAN 增量备份恢复 data guard log gap（日志断档）
- 从备份集中恢复归档日志
- 非归档模式下使用Rman进行备份和恢复
- rman备份后为什么要同时备份归档日志
- 使用RMAN备份RAC本地目录中不是用NFS的归档日志
- 无备份有完全归档日志情况下恢复数据文件
- rman异常案例一： 归档日志被人移动到其他目录，导致数据库恢复异常
- RMAN备份与恢复—基于日志序列号的不完全恢复
- 非归档模式下重做日志覆盖后的rman恢复
- Oracle:只有rman备份（数据,参数,日志,控制文件全丢失）的恢复
- Oracle在Rman备份模式下误删归档日志文件解决方法
- 使用RMAN和控制文件备份删除归档日志的SHELL脚本--RED HAT 5 LINUX 64