RMAN備份恢復之歸檔日誌對BLOCKRECOVER的影響

yangtingkun發表於2007-06-16

上面一篇簡單的介紹了一下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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章