簡單記錄一次REDO檔案損壞報錯 ORA-00333重做日誌讀取塊出錯

還不算暈發表於2014-07-04

一.故障描述

首先是例項恢復需要用到的REDO檔案損壞


二、解決方法

1.對於非當前REDO或者當前REDO但是無活動事務使用以下CLEAR命令：

用CLEAR命令重建該日誌檔案SQL>alter database clear logfile group 3；

如果是該日誌組還沒有歸檔，則需要用SQL>alter database clear unarchived logfile group 3；

因為是當前例項恢復需要用的REDO，且未歸檔，使用是CLEAR命令不行的。


2.沒備份，有備份可以參考以下：

拷貝有效的資料庫的全備份，並不完全恢復資料庫

可以採用獲取最近的SCN的辦法用until scn恢復或用until cnacel恢復

recover database until cancel

　　先選擇auto，儘量恢復可以利用的歸檔日誌，然後重新

recover database until cancel

這次輸入cancel，完成不完全恢復，也就是說恢復兩次。如：

SQL> recover database until cancel;
Auto
……
SQL> recover database until cancel;
Cancel;

、利用alter database open resetlogs開啟資料庫

說明：

這種辦法恢復的資料庫是一致的不完全恢復，會丟失當前聯機日誌中的事務資料

這種方法適合於歸檔資料庫並且有可用的資料庫全備份。

恢復成功之後，記得再做一次資料庫的全備份。

建議聯機日誌檔案一定要實現鏡相在不同的磁碟上，避免這種情況的發生，因為任何資料的丟失對於生產來說都是不容許的。

3.修改隱含引數_allow_resetlogs_corruption

_allow_resetlogs_corruption=TRUE

重新啟動資料庫,利用until cancel恢復

SQL>recover database until cancel;
Cancel

如果出錯，不再理會，發出

SQL>alter database open resetlogs;

資料庫被開啟後，馬上執行一個full export

shutdown資料庫,去掉_all_resetlogs_corrupt引數


二、參考EYGLE：ORA-00600 kcratr1_lostwrt之解決與原理分析

ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [], [], [], []
Current SQL statement for this session:
alter database open
這個錯誤不難解決，但是其具體成因有點意思。
Metalink對這個錯誤的解釋只有一句關鍵：
When an instance is restarted following an instance crash, Oracle carries out some checks against the last block that was written to disk prior to the instance crash.
If Oracle finds an old block, then this suggests a lost write and the  error is raised.
這句話是說，當例項崩潰之後啟動，Oracle會去檢查崩潰前最後一個寫出的資料塊，通過控制檔案校驗其是否一致，如果這個塊是Old的，則說明最後的寫操作丟失了。

這是一個非常快捷巧妙地判斷，如果有寫丟失，自然必須引入恢復。

在跟蹤檔案中記錄了詳細的資訊：
Last BWR afn: 6 rdba: 0x18f9590(blk 1021328) ver: 0x0001.5c21fd6e.01 flg: 0x04
Disk version: 0x0001.5c1ec4f0.04 flag: 0x04
提示說，控制檔案記錄的最後一次寫的資料塊是file6 block 1021328，SCN版本為：5c21fd6e，而資料檔案上記錄的SCN則是5c1ec4f0，後者Old，小於前者，這說明丟失了寫操作。

那能否恢復呢？跟蹤檔案裡還會記錄這樣的資訊：
Thread checkpoint rba:0x00dfeb.00000002.0010 scn:0x0001.5c1ee5b7
On-disk rba:0x00dfeb.0001161f.0000 scn:0x0001.5c2266d6
執行緒檢查點的SCN為5c1ee5b7，而On-Disk Rba的SCN為5c2266d6，完全可以推演超過5c21fd6e，可以恢復。

所以這樣的問題：
SQL>startup mount;
SQL>recover database;
SQL>alter database open;
一般就可以完成恢復了，如果不幸的，你的On-Disk Rba不足以恢復丟失的寫操作，則問題將嚴重了。

參考：http://blog.itpub.net/25964700/viewspace-709097/      http://www.eygle.com/archives/2010/05/ora-00600_kcratr1_lostwrt.html

相關文章