在Oracle資料庫的日常維護中，我們可能經常會遇到一些從未見過的錯誤，甚至莫名其妙的錯誤。很多時候，甚至通過metalink、baidu、甚至google 都無法搜尋到相關內容。這不，昨天公司南區同事讓幫忙恢複的的一個客戶資料庫；據說是歸檔資料庫，沒有備份，重啟執行個體後就無法開啟資料庫了。
我也是第一次聽說這種事情，看了下居然是Oracle 11.2.0.3的資料庫，還有這樣起碼的事情，確實有點匪夷所思。首先我們來看下是報錯是什麼樣的。
看到這個錯誤。我感覺有一定似曾相識的感覺，但是有又說不來具體是什麼錯誤。不過從錯誤號碼來看，我可以大致判斷跟什麼內容有關係。這裡我拓展一下，對於Oracle ora-00600 錯誤，metalink有一篇詳細的文檔描述，裡面對600錯誤後面的錯誤編號進行了分類。對於該文檔大家務必瞭解下。所以現在即使我從未見過的ora-00600錯誤，我仍然可以第一眼就能大致判斷是哪方面的問題。這裡列舉下：
Ora-600 Base Functionality Description
2000 server/rcv Cache Op
2100 server/rcv Control File mgmt
2200 server/rcv Misc (SCN etc.)
2400 server/rcv Buffer Instance Hash Table
2600 server/rcv Redo file component
2800 server/rcv Db file
3000 server/rcv Redo Application
3200 server/cache Buffer manager
3400 server/rcv Archival & media recovery component
3600 server/rcv recovery component
3700 server/rcv Thread component
3800 server/rcv Compatibility segment
從描述來看，我們可以大致判斷，該錯誤肯定跟redo 有關係。我們再回頭去看下alert log的資訊，可以看到一行比較關鍵的資訊：crash recovery due to error 600.
對於Oracle 資料庫的open過程，我們知道需要經過nomount–mount–open這樣幾個過程，如果是異常關機例如強制abort的情況，那麼open資料庫時，Oracle 需要進行instance recovery；實際上我查詢v$Log 也可以發現current redo logfile 的next_change# 為無窮大.
首先我嘗試手工進行了一次recover database，沒有任何問題，然後alter database open還是報上面的3712錯誤。這裡我發現一個問題，所有的scn都已經變化，而且更新到了一致的狀態。但是為啥還是報錯呢？
我們知道其實Oracle open的時候不僅僅是需要去進行執行個體恢複，執行個體恢複完成後，需要順利open資料庫。如果我們試想是否存在這樣一種情境：
假設當前我們恢複的資料庫scn已經到了100000，然而執行個體恢複完成後open時發現下一個要更新的scn比當前的要小（比如99999），會怎麼樣呢？ 很明顯這是會報錯的。
很多人或許看不懂，甚至不理解我為什麼會這樣設想，這裡主要有2個因素：
1、 基於對於資料庫原理的基本理解，深入瞭解oracle資料庫open的過程
2、細心觀察上述的ORA-00600 錯誤.
ok，就拿這個錯誤來講 [3371],[612688841],[3371],[612688840]；當我們看到這一串數位時候，我們應該認為或者試想這寫數字都是什麼含義 ？
根據我們的資料庫理解和經驗來判斷，通常都是表示序列，dba地址，檔案號，scn等等這些。
我想，稍微有一點常識的人可能都能看出來，這裡應該是表示的SCN。或許有人說為什麼這裡會是表示的scn呢？
如果這樣想，那說明你不瞭解Oracle scn的基本結構。Oracle 中的scn，分為高位和低位兩部分組成。大致上如下：
scn最低值是0×0000.00000000，最高值是0xffff.ffffffff。高位是scn wrap,即0×0000，低位是scn base，即後面的8個位。正確的SCN應該是=scn warp * power(2,32)+scn base
能夠想到這裡，我想我們可以大致判斷這裡的3371 應該是scn wrap值，而後面的612688841應該是scn base。將scn換算一下然後和檔案頭的最新scn進行比較，發現完全符合。這裡能夠驗證我們的判斷。
到這裡，我們可以發現一個問題，scn不對啊？ 為什麼不對？ 因為這裡出現了2個scn，分別是：
3371*power(2,32)+612688841 和 3371*power(2,32)+612688840
很明顯，這2個值大小不同，我想Oracle 肯定是進行判斷，發現即將產生的scn比我們當前的scn還要小，才會出現這個情況。那麼後面要小的scn就是有問題的scn。而這個scn 比如來源於控制檔案。
想到這裡，我就知道，我應該如何去完美解決這個問題了。那麼答案就是重建控制檔案。
如下是恢複的基本步驟，重建控制檔案的步驟就不再描述了。
產生重建控制檔案的指令碼後，重建控制檔案，記得noresetlogs 方式去建立即可（rac環境需要修改
cluster_database=false);建立完畢後直接recover一把，然後順利open資料庫，完美收工！
補充：
1、後面我查詢發現這極有可能是Oracle 11.2.0.3的bug：
Bug 16432211 : ORA-00600 [KCRFNL_3], LGWR… TERMINATING THE INSTANCE, ORA-00600 [3712]
後面我查詢之前的alert log和trace 發現基本上完全一致。
