ORA-00600 [2662]錯誤解決過程
2024-07-21 02:40:34
供稿：網友
ORA-00600 [2662]錯誤解決過程
數據庫版本：7.3.2
背景：
客戶那邊數據庫忽然出現一個current日志文件壞了，導致數據庫crash了，然后現場工程師使用_ALLOW_RESETLOGS_CORRUPTION = TRUE這個隱含參數，做了不完全恢復后強行將數據庫打開。可是打開數據庫后發現只能用internal用戶連接進去，別的用戶連接都報錯，錯誤信息如下：
ORA-00600: internal error code, arguments: [2662], [0], [431267936], [0], [431273216], [0], [], []
查詢不了任何應用的表，應用也沒法使用，于是想嘗試全庫的eXP出來然后重新imp進去建庫，結果發現exp數據也不成功，也是報同樣的ORA-600的錯誤，用戶當時數據沒有任何的備份過，只能想辦法盡量打開數據庫，導出數據了。
處理過程：
先檢查了600錯誤產生的trace文件：
*** session ID:(7.15) 2004.11.23.23.28.16.824
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [2662], [0], [431267754], [0], [431272752], [0], [], []
Current SQL statement for this session:
SELECT * FROM "WHSB"."SB_BSBF"
得到的信息有限，只能看到是嚴重內部錯誤，剩下的都是內存堆棧的一堆信息，于是查找了一下這個錯誤的具體相關信息。
ORA-600 [2662] "Block SCN is ahead of Current SCN"，說明當前數據庫的數據塊的SCN早于當前的SCN，主要是和存儲在UGA變量中的dependent SCN進行比較，假如當前的SCN小于它，數據庫就會產生這個ORA-600 [2662]的錯誤了。這個錯誤一共有五個參數，分別代表不同的含義，
ORA-600 [2662] [a] [b] [c] [d] [e]
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where PResent this is the DBA where the dependent SCN came from.
我們分析錯誤中的提示，它的參數b=431267754,d=431272752,表明當前的SCN確實是小于dependent SCN，所以產生了這個600的錯誤。
通過查閱文檔，發現這個錯誤的產生原因主要有以下幾條：
l 使用隱含參數_ALLOW_RESETLOGS_CORRUPTION后resetlogs打開數據庫
l 硬件錯誤引起數據庫沒法寫控制文件和重做日志文件
l 錯誤的部分恢復數據庫
l 恢復了控制文件但是沒有使用recover database using backup controlfile進行恢復
l 數據庫crash后設置了_DISABLE_LOGGING隱含參數
l 在并行服務器環境中DLM存在問題
仔細對比了一下，發現問題可能是由于第一條產生的，由于設置了_ALLOW_RESETLOGS_CORRUPTION這個隱含參數后，雖然強制性的打開數據庫，但是數據庫本身存在了corruption，仍然存在嚴重的問題。
于是想到使用ADJUST_SCN事件來調整當前的SCN，使其大于dependent SCN，然后保證數據庫可以全庫的導出，然后重建數據庫導入數據。
用internal用戶登陸數據庫后，連接別的用戶，還是失敗報錯，執行：
alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';
然后嘗試連接別的用戶，連接成功。
最后exp整個數據庫，重建數據庫后導入數據，整個數據庫恢復成功！
通過這個實例，我們可以看到，盡量的不要去使用那些隱含參數，這些參數是Oracle所不推薦使用的，也不是萬能的！假如使用了可能會存在一些遺留的問題，假如非要使用，建議使用后一定要exp/imp重建建立數據庫。
