Oracle RAC一節點宕機致使另外一節點HANG的問題分析

        正所謂「福無雙至，禍不單行」，生產上有套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住了。