正所謂“福無雙至，禍不單行”，生産上有套2節點Oracle 11.2.0.4資料庫，其中2節點因硬體故障當機，1節點去HANG住了。我們一起來分析這起故障。
淩晨4點半，值班同時電話說一套生産庫節點2當機了，機房的同僚看機器正在啟動，估計是硬體原因導緻的。心想節點2宕了還有一個節點1在跑，應該問題不大，于是繼續睡覺，離公司近的另一位DBA同僚趕往現場支援。可是沒有過多長時間，到現場的DBA回報資訊：活着的另一節點也出問題了。在宕掉的那個節點2上部署了ogg，由于當機，自動切換到了節點1，但ogg的複制程序延遲一直的增長，感覺像是一直沒有應用。
嘗試用sqlplus進入庫結果卻報了ORA-00020超過最大程序數，無法登入資料庫，無法分析資料庫目前的狀況。
于是分析哪個應用伺服器連接配接這套資料庫，是不是由于應用問題造成的。
找到連接配接數最多的那個ip上的應用，與相關業務人員确認，可以封堵其連接配接資料庫的端口，減少資料庫的外部連接配接。可是把這個ip禁掉之後，别的ip連接配接數又漲上來了。開始想到，是不是由于資料庫的問題導緻應用處理慢，進而導緻連接配接數過多呢。現在無法登入資料庫也無法進行驗證。
與業務部門溝通是否可以嘗試kill部分會話，讓DBA可以連接配接到資料庫背景，進行一些管理操作，和性能分析。得到業務部分同僚的肯定答複之後，kill了部分LOCAL=NO的會話。以sysdba登入資料庫背景，執行性能分析語句，剛查完session的等待事件，查第二個sql的時候，sql執行卡住了。從新的視窗登入資料庫依然報ORA-00020。這裡進一步确定了是由于資料庫的性能問題導緻了ogg及應用的問題。
資料庫都HANG住了，如何分析呢？
想到了以前看别人分享的一個hanganalyze在資料庫HANG住時可以用于分析HANG的原因，于是找到指令ORADEBUG hanganalyze 3。分析trace檔案，看到hang chain如下圖
再往下看，SMON程序在等待parallel recovery coord wait for reply，等待時間已經有289min，正是故障出現到hanganalyze的時間，而且他阻塞了1465個session。
從trace中看到等待事件為parallel recover coord wait for reply 、gc domain validation。沒見過這個等待事件，于是查詢MOS，關于這兩個等待事件的文檔不是很多，找到一篇
不知是否觸發了ORACLE的BUG。
由于時間緊迫，隻能選擇把節點1的資料庫執行個體進行重新開機，重新開機後資料庫恢複正常。
事後找大神幫忙分析原因，看SMON程序的trace資訊
發現正在做并行恢複，檢視OSW中的SMON程序監控，沒有發現性能問題。
檢視到有大量的p00xx的程序，說明是在并行進行恢複，也沒有看出有什麼問題。
大神建議使用TFA檢視日志進行詳細，結果沒有時間分析就給擱置了。
總結故障就是：節點2當機，節點1要接管節點2的資料，結果節點1也因為接管HANG住了。