一.故障描述首先是實(shí)例恢復(fù)需要用到的REDO文件損壞 二、解決方法1.對(duì)于非當(dāng)前REDO或者當(dāng)前REDO但是無(wú)活動(dòng)事務(wù)使用以下CLEAR命令:用CLEAR命令重建該日志文件SQL>alter database clear logfile group 3; 如果是該日志組還沒(méi)有歸檔,則需要用SQL>alter database clear unarchived logfile group 3; 因?yàn)槭钱?dāng)前實(shí)例恢復(fù)需要用的REDO,且未歸檔,使用是CLEAR命令不行的。2.沒(méi)備份,有備份可以參考以下:拷貝有效的數(shù)據(jù)庫(kù)的全備份,并不完全恢復(fù)數(shù)據(jù)庫(kù) 可以采用獲取最近的SCN的辦法用until scn恢復(fù)或用until cnacel恢復(fù) recover database until cancel 先選擇auto,盡量恢復(fù)可以利用的歸檔日志,然后重新 recover database until cancel 這次輸入cancel,完成不完全恢復(fù),也就是說(shuō)恢復(fù)兩次。如: SQL> recover database until cancel; 、利用alter database open resetlogs打開(kāi)數(shù)據(jù)庫(kù) 說(shuō)明: 這種辦法恢復(fù)的數(shù)據(jù)庫(kù)是一致的不完全恢復(fù),會(huì)丟失當(dāng)前聯(lián)機(jī)日志中的事務(wù)數(shù)據(jù) 這種方法適合于歸檔數(shù)據(jù)庫(kù)并且有可用的數(shù)據(jù)庫(kù)全備份。 恢復(fù)成功之后,記得再做一次數(shù)據(jù)庫(kù)的全備份。 建議聯(lián)機(jī)日志文件一定要實(shí)現(xiàn)鏡相在不同的磁盤(pán)上,避免這種情況的發(fā)生,因?yàn)槿魏螖?shù)據(jù)的丟失對(duì)于生產(chǎn)來(lái)說(shuō)都是不容許的。 3.修改隱含參數(shù)_allow_resetlogs_corruption_allow_resetlogs_corruption=TRUE 重新啟動(dòng)數(shù)據(jù)庫(kù),利用until cancel恢復(fù) SQL>recover database until cancel; 如果出錯(cuò),不再理會(huì),發(fā)出 SQL>alter database open resetlogs; 數(shù)據(jù)庫(kù)被打開(kāi)后,馬上執(zhí)行一個(gè)full export shutdown數(shù)據(jù)庫(kù),去掉_all_resetlogs_corrupt參數(shù)二、參考EYGLE:ORA-00600 kcratr1_lostwrt之解決與原理分析ksedmp: internal or fatal error這個(gè)錯(cuò)誤不難解決,但是其具體成因有點(diǎn)意思。 Metalink對(duì)這個(gè)錯(cuò)誤的解釋只有一句關(guān)鍵: 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.這句話是說(shuō),當(dāng)實(shí)例崩潰之后啟動(dòng),Oracle會(huì)去檢查崩潰前最后一個(gè)寫(xiě)出的數(shù)據(jù)塊,通過(guò)控制文件校驗(yàn)其是否一致,如果這個(gè)塊是Old的,則說(shuō)明最后的寫(xiě)操作丟失了。 這是一個(gè)非??旖萸擅畹嘏袛啵绻袑?xiě)丟失,自然必須引入恢復(fù)。 在跟蹤文件中記錄了詳細(xì)的信息: Last BWR afn: 6 rdba: 0x18f9590(blk 1021328) ver: 0x0001.5c21fd6e.01 flg: 0x04提示說(shuō),控制文件記錄的最后一次寫(xiě)的數(shù)據(jù)塊是file6 block 1021328,SCN版本為:5c21fd6e,而數(shù)據(jù)文件上記錄的SCN則是5c1ec4f0,后者Old,小于前者,這說(shuō)明丟失了寫(xiě)操作。 那能否恢復(fù)呢?跟蹤文件里還會(huì)記錄這樣的信息: Thread checkpoint rba:0x00dfeb.00000002.0010 scn:0x0001.5c1ee5b7線程檢查點(diǎn)的SCN為5c1ee5b7,而On-Disk Rba的SCN為5c2266d6,完全可以推演超過(guò)5c21fd6e,可以恢復(fù)。 所以這樣的問(wèn)題: SQL>startup mount;一般就可以完成恢復(fù)了,如果不幸的,你的On-Disk Rba不足以恢復(fù)丟失的寫(xiě)操作,則問(wèn)題將嚴(yán)重了。 參考:http://blog./25964700/viewspace-709097/ http://www./archives/2010/05/ora-00600_kcratr1_lostwrt.html |
|
來(lái)自: EORi91cus7bl76 > 《故障處理及方法》