數據庫版本
背景 客戶那邊數據庫突然出現一個current日志文件壞了
導致數據庫crash了
然後現場工程師使用_ALLOW_RESETLOGS_CORRUPTION = TRUE這個隱含參數
做了不完全恢復後強行將數據庫打開
可是打開數據庫後發現只能用internal用戶連接進去
別的用戶連接都報錯
錯誤信息如下
ORA
: internal error code
arguments: [
]
[
]
[
]
[
]
[
]
[
]
[]
[]
查詢不了任何應用的表
應用也沒法使用
於是想嘗試全庫的exp出來然後重新imp進去建庫
結果發現exp數據也不成功
也是報同樣的ORA
的錯誤
用戶當時數據沒有任何的備份過
只能想辦法盡量打開數據庫
導出數據了
處理過程 先檢查了
錯誤產生的trace文件
*** SESSION ID:(
)
ksedmp: internal or fatal error
ORA
: internal error code
arguments: [
]
[
]
[
]
[
]
[
]
[
]
[]
[]
Current SQL statement for this session:
SELECT * FROM
WHSB
SB_BSBF
得到的信息有限
只能看到是嚴重內部錯誤
剩下的都是內存堆棧的一堆信息
於是查找了一下這個錯誤的具體相關信息
ORA
[
]
Block SCN is ahead of Current SCN
說明當前數據庫的數據塊的SCN早於當前的SCN
主要是和存儲在UGA變量中的dependent SCN進行比較
如果當前的SCN小於它
數據庫就會產生這個ORA
[
]的錯誤了
這個錯誤一共有五個參數
分別代表不同的含義
ORA
[
] [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=
d=
表明當前的SCN確實是小於dependent SCN
所以產生了這個
的錯誤
通過查閱文檔
發現這個錯誤的產生原因主要有以下幾條
使用隱含參數_ALLOW_RESETLOGS_CORRUPTION後resetlogs打開數據庫
硬件錯誤引起數據庫沒法寫控制文件和重做日志文件
錯誤的部分恢復數據庫
恢復了控制文件但是沒有使用recover database using backup controlfile進行恢復
數據庫crash後設置了_DISABLE_LOGGING隱含參數
在並行服務器環境中DLM存在問題
仔細對比了一下
發現問題可能是由於第一條產生的
由於設置了_ALLOW_RESETLOGS_CORRUPTION這個隱含參數後
雖然強制性的打開數據庫
但是數據庫本身存在了corruption
仍然存在嚴重的問題
於是想到使用ADJUST_SCN事件來調整當前的SCN
使其大於dependent SCN
然後保證數據庫可以全庫的導出
然後重建數據庫導入數據
用internal用戶登陸數據庫後
連接別的用戶
還是失敗報錯
執行
alter session set events
IMMEDIATE trace name ADJUST_SCN level
;
然後嘗試連接別的用戶
連接成功
最後exp整個數據庫
重建數據庫後導入數據
整個數據庫恢復成功！
通過這個實例
我們可以看到
盡量的不要去使用那些隱含參數
這些參數是oracle所不推薦使用的
也不是萬能的！如果使用了可能會存在一些遺留的問題
如果非要使用
建議使用後一定要exp/imp重建建立數據庫
From:http://tw.wingwit.com/Article/program/Oracle/201311/17202.html
