Oracle RAC一節(jié)點宕機導致另一節(jié)點HANG的問題分析

        正所謂“福無雙至，禍不單行”，生產(chǎn)上有套2節(jié)點Oracle 11.2.0.4數(shù)據(jù)庫，其中2節(jié)點因硬件故障宕機，1節(jié)點去HANG住了。我們一起來分析這起故障。

        凌晨4點半，值班同時電話說一套生產(chǎn)庫節(jié)點2宕機了，機房的同事看機器正在啟動，估計是硬件原因?qū)е碌摹Ｐ南牍?jié)點2宕了還有一個節(jié)點1在跑，應該問題不大，于是繼續(xù)睡覺，離公司近的另一位DBA同事趕往現(xiàn)場支持?？墒菦]有過多長時間，到現(xiàn)場的DBA反饋信息：活著的另一節(jié)點也出問題了。在宕掉的那個節(jié)點2上部署了ogg，由于宕機，自動切換到了節(jié)點1，但ogg的復制進程延遲一直的增長，感覺像是一直沒有應用。

        嘗試用sqlplus進入庫結(jié)果卻報了ORA-00020超過最大進程數(shù)，無法登錄數(shù)據(jù)庫，無法分析數(shù)據(jù)庫當前的狀況。

        于是分析哪個應用服務器連接這套數(shù)據(jù)庫，是不是由于應用問題造成的。

        找到連接數(shù)最多的那個ip上的應用，與相關(guān)業(yè)務人員確認，可以封堵其連接數(shù)據(jù)庫的端口，減少數(shù)據(jù)庫的外部連接?？墒前堰@個ip禁掉之后，別的ip連接數(shù)又漲上來了。開始想到，是不是由于數(shù)據(jù)庫的問題導致應用處理慢，進而導致連接數(shù)過多呢?，F(xiàn)在無法登錄數(shù)據(jù)庫也無法進行驗證。

        與業(yè)務部門溝通是否可以嘗試kill部分會話，讓DBA可以連接到數(shù)據(jù)庫后臺，進行一些管理操作，和性能分析。得到業(yè)務部分同事的肯定答復之后，kill了部分LOCAL=NO的會話。以sysdba登錄數(shù)據(jù)庫后臺，執(zhí)行性能分析語句，剛查完session的等待事件，查第二個sql的時候，sql執(zhí)行卡住了。從新的窗口登錄數(shù)據(jù)庫依然報ORA-00020。這里進一步確定了是由于數(shù)據(jù)庫的性能問題導致了ogg及應用的問題。

        數(shù)據(jù)庫都HANG住了，如何分析呢？

        想到了以前看別人分享的一個hanganalyze在數(shù)據(jù)庫HANG住時可以用于分析HANG的原因，于是找到命令ORADEBUG hanganalyze 3。分析trace文件，看到hang chain如下圖

        再往下看，SMON進程在等待parallel recovery coord wait for reply，等待時間已經(jīng)有289min，正是故障出現(xiàn)到hanganalyze的時間，而且他阻塞了1465個session。

        從trace中看到等待事件為parallel recover coord wait for reply 、gc domain validation。沒見過這個等待事件，于是查詢MOS，關(guān)于這兩個等待事件的文檔不是很多，找到一篇

        不知是否觸發(fā)了ORACLE的BUG。

        由于時間緊迫，只能選擇把節(jié)點1的數(shù)據(jù)庫實例進行重啟，重啟后數(shù)據(jù)庫恢復正常。

        事后找大神幫忙分析原因，看SMON進程的trace信息

        發(fā)現(xiàn)正在做并行恢復，查看OSW中的SMON進程監(jiān)控，沒有發(fā)現(xiàn)性能問題。

        查看到有大量的p00xx的進程，說明是在并行進行恢復，也沒有看出有什么問題。

        大神建議使用TFA查看日志進行詳細，結(jié)果沒有時間分析就給擱置了。

        總結(jié)故障就是：節(jié)點2宕機，節(jié)點1要接管節(jié)點2的數(shù)據(jù)，結(jié)果節(jié)點1也因為接管HANG住了。