312
我明明 immediate 關庫的，怎麼就打不開了？！
五一放假期間，某客戶的數據庫出現故障，據說對方找了一些工程師折騰了一天，都無法將數據庫open，其中參考了網絡上的很多文章，也使用了一係列隱含參數，均無法將數據庫打開。這裏我簡單的與大家分享一下這個case。
首先我介紹一下整個case的背景，客戶在4月30號淩晨通過shutdown immediate停庫維護後，啟動數據庫無法報錯，此時發現數據庫無法open，期間嚐試了各種數據庫手段，均失敗告終。
我們先來看看相關日誌，如下是數據庫停庫的日誌：
我們可以看出，這個數據庫確實是以shutdown immediate的方式停止的。客戶第一次嚐試啟動時，發現報錯ORA-00600 [2663],如下：
這是一個非常常見的錯誤,這個錯誤通常是是跟數據塊有關係。我們知道，根據經驗，一般來講，如果current scn (這裏是scn base)與dependent scn(scn base)非常接近（且scn wrap都一致或者為0)的情況下，說明scn的差異非常小，通過多次重啟數據庫的手段，基本上可以繞過這個錯誤。
果然，通過看客戶提供的alert log發現多次重啟後，alert log的報錯日誌變了ORA-00600 [4194]錯誤，如下：
這是一個看似非常簡單的錯誤，大致意思是說Oracle 在進行事務恢複時發現redo和undo的信息有所出入，因此拋出這個錯誤。
這裏我貼出Oracle MOS的標準解釋供大家參考：Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter (文檔 ID 281429.1)
上述文檔中提到，這個錯誤其實就是指恢複時發現undo block對應的record 編號與redo block 對應的undo record 編號不一致。通常情況下來講，都是由於回滾段損壞導致的問題。 這裏我們先不去進行alert log的詳細分析展開了，以自己的實際操作過程來進行展開分析說明。如下是我的簡單恢複過程。
首先我嚐試進行正常恢複，並打開數據庫：
我們可以看到操作報錯，並沒有打開數據庫。此時查看數據庫alert 告警日誌，發現正是前麵提到的ORA-00600 [4194]錯誤：
這個ora-00600 錯誤與前麵提到的完全一致。根據我們常規處理這個錯誤的套路，基本上就是使用undo_management=’manual’ 來嚐試繞過，經過測試發現不好使。
進一步查看對應的trace 文件，發現oracle提示說某個塊存在異常：
上述的錯誤其實也很容易解釋，簡單的講就是redo應用時出現了異常，而且oracle 明確提升file 1 block 131 這個undo block有問題. 上述的內容是redo block的dump；那麼我們來看看對應的undo block 中的前鏡像是什麼：
我們可以看到完全不匹配，同時我們通過腳本將上述內容進行轉換，可以發現是其實是回滾段名稱：
其次結合我們前麵解釋ora-00600 [4194]錯誤來看，這裏undo block 對應的record number是0×20，而redo block中記錄的record number是0×2. 這確實是不匹配的。
那麼怎麼解決這個問題呢？ 能不能通過屏蔽回滾段的方式來解決呢？
我嚐試在open之前設置10046 trace，來觀察了一下得到了如下結果：
可以看到oracle在執行update undo$時報錯，其中更新的是_SYSSMU1_3724004606$ 這個回滾段。而且我們也可以看到，wait# 中記錄的正好是前麵報錯的file# 1 block 131. 那麼通過_corrupted_rollback_segments=(_SYSSMU1_3724004606$)
這種方式是否可以解決這個問題呢？
很遺憾，這裏我測試也不行。甚至通過bbed 修改undo$的kdbr記錄，將_SYSSMU1 的狀態修改為offline，也無法繞過這個ora-00600 4194錯誤。簡直堪稱最頑固的ORA-00600 [4194]。
我又檢查了一下前麵的trace文件，發現所針對這個回滾段頭的dump記錄，可以確認其中並沒有什麼活動事務。然後再仔細看我們所遇到的這個ora-00600 [4194]錯誤，我感覺有點怪異。為什麼說怪異呢？
如果說根據Oracle mos的解釋文檔來看，這裏是是沒有[a],[b] 值的，因為均為0.
最後我們想到通過修改system 回滾段頭來繞過這個錯誤，如下是操作過程：
注意，這裏我們僅僅需要修改ktuxcnfb和ktuxcfbp[1] 即可。其中將ktuxcnfb修改為0，ktuxcfbp[1]中的uba修改為0.
然後再嚐試打開數據庫，發現順利打開了數據庫，如下：
接著檢查了數據庫alert log，也沒有發現任何的ora-錯誤。看到最後，或許大家會覺得很奇怪，為什麼會出現這樣的故障呢 ？ 這裏我也跟大家一樣困惑。
這庫是通過shutdown immediate方式正常停止的。我們都知道，這種方式停庫之後，整個Oracle數據庫的文件都是處於一致的狀態，重新啟動數據庫實例後按理說是不需要再進行實例恢複的。
那麼為什麼這裏又出現了這種情況呢？
針對這個問題，我認為有2種可能性：
1、shutdown immediate之後，數據庫寫入到操作係統cache，還未完全寫入到disk上時，此時數據庫主機被強行重啟；由於操作係統cache丟失，導致數據庫出現了不一致的情況(本文環境是Linux文件係統)。
2、其他程序或軟件破壞了Oracle數據庫文件的一致性（實際上，經過了解該環境部署了Rose HA軟件；而且客戶在操作時，據說並沒有停止rose ha軟件）。
由於客戶操作的時間點是淩晨2點，幾乎是0業務場景，因此我認為第一種可能性幾乎為0；第2種可能性更大。
當然由於我們不了解Rose HA軟件的工作機製，這裏不便評論。隻能說這是一個非常奇怪的case了。值得欣慰的是，通過我們的努力，很快就幫助客戶恢複了係統訪問，並且無數據丟失。
本文出自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 17:32:55