clas 後者 利用 實例恢復 poi cancel true cover html

一.故障描寫敘述

首先是實例恢復須要用到的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

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