ITPub博客

首页 > Linux操作系统 > Linux操作系统 > RMAN备份恢复之归档日志对BLOCKRECOVER的影响

RMAN备份恢复之归档日志对BLOCKRECOVER的影响

原创 Linux操作系统 作者:yangtingkun 时间:2007-06-16 00:00:00 0 删除 编辑

上面一篇简单的介绍了一下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连一个空的归档都无法跳过,看来这块的文档描述和实际情况有很大的出入。

从这一点也反映出归档日志的重要性,如果丢失了归档日志,不管是常规恢复还是数据库的恢复都是无法进行的。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-69314/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10368511