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

一.故障描述

首先是執行個體恢複需要用到的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