五一放假期間，某客戶的資料庫出現故障，據說對方找了一些工程師折騰了一天，都無法將資料庫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.

注意，這裡我們僅僅需要修改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了。值得欣慰的是，通過我們的努力，很快就幫助客戶恢復了系統訪問，並且無資料丟失。

文章來自微信公眾號：資料和雲