最近生產上出了很多“奇怪”的問題，比如下面要分享的一個故障，一套11.2.0.4 兩節點RAC資料庫，2節點的叢集元件會不定日期的重啟，但重啟的時間段比較固定，都是凌晨4:50左右。而且幾分鐘就會恢復。廢話不多說，直接上整個問題的處理思路及過程。

        2節點上的叢集重啟，首先會去看叢集的alert日誌。看到故障時間點出錯如下圖的報錯：

        日誌中提示的很明顯，節點之間的心跳網路丟失，導致節點2被驅逐出叢集。那網路心跳丟失為什麼只是叢集件重啟呢，這是由於從11.2.0.2開始，引入了新特性rebootless restart，對於丟失網路心跳導致的重新配置，只會發生GI重啟。

        那問題很明顯了，叢集網路心跳丟失，導致2節點的GI重啟。那就來看是不是兩臺機器的私網網絡卡是不是出現了故障。

        先檢視osw對私網的監控日誌，發現有丟包

        那由以上資訊能夠確定是由於私網網絡卡故障導致的嗎？

        想到以前看高斌老師的書《RAC核心技術詳解》有介紹過類似的現象，找來書一看，現象簡直是一模一樣，他那個案例中確實是由於私網網絡卡有故障導致的。但我們的故障也是嗎？

        找來網路工程師來確認網絡卡的情況。才知道，由於私網網絡卡用的是ib卡，連的是ib交換機，不屬於我們自己的維護範圍。於是找到資料中心來協助檢查，得到的回覆是沒發現私網網絡卡有問題。

        那麼問題來了，私網網絡卡沒有問題，那會是什麼原因導致網路心跳丟失的呢。

        又想到有zabbix監控，可以看當時私網網絡卡的流量情況，看是不是有流量為0的情況，如果流量為0，應該說明網絡卡出了問題，來看看監控圖

        從監控圖上看出問題時間私網網路流量沒有下降，反到比平時要高出很多倍，最高峰達到440.64Mbps。

        從網路工程師那瞭解到私網網絡卡是千兆的，也就是流量用了網絡卡的50%左右。也沒有達到網絡卡的瓶頸，那是什麼原因導致網路心跳丟失，又是什麼原因導致問題時段比平時高出很多呢。

        正趕上一位資料分析的同事反映有一個job每天4點到5點執行，執行時間非常不穩定，有時3分鐘左右執行完成有時就需要70分鐘執行完。從ash看執行時間長時，主要是在等待gc的等待事件。gc是叢集等待事件，說明SQL訪問的相關表在其他節點有併發。從awr和他給出的sql語句中定位到主要是發生在1張大表中。

        該表是從其他庫通過ogg同步到本庫的，該表每天凌晨0-2點都會執行跑批操作，幾乎全表更新。查詢同步該表的ogg程序是連線到的是2節點，而他們的應用是連線到了1節點。立馬跟前面節點重啟前私網流量高關聯起來了，由於0-2點該表在2節點通過ogg同步更新，而到了4點多，job中的sql在1節點執行，導致私網流量過大。

        似乎問題明確了，於是採取措施，把ogg及job都連線到同一個節點，防止他們出現跨節點的資料塊交換。調整完後回家睡覺。

        第二天早上起來，沒有收到資料庫4-5點dbtime高的簡訊告警，也沒有反映節點重啟，以為問題解決了。來到公司發現dbtime只是下降到了告警值下一點，比之前沒有下降很多。再檢視私網網路流量，也沒有明顯下降，只是4-5點的那個job執行時間比較穩定了，穩定在了3分鐘左右。

        問題還是沒有解決，但資料庫2節點也沒有再重啟，就這樣放了幾天。

        幾天後的晚上，值夜班，凌晨4：50被告警電話吵醒，資料庫2節點又自動重啟了。現象還是一樣，重啟也很快。檢視私網流量還是很高，甚至達到了600Mbps。重啟後登入節點2，發現上面跑了很多pxxx的程序，有100多個。由於節點2不定期重啟，業務已經都連線1節點了，2節點應該不會有會話才對。從程序型別來看應該是並行會話的子程序，沒有應用在跑，那並行程序又是從哪來的呢，難道是從1節點？想到前幾天與同事討論的跨節點並行，於是檢視資料庫的parallel_force_local配置。

        果然設定的值為false，即可以跨節點執行，引數詳細說明見下圖：

        想到這裡如獲至寶，於是把引數設定為false

        alter system set parallel_force_local=true scope=both sid='*';

        該引數設定完後，觀察了幾天，私網網路流量降到了以的同時段的1/10。

        從監控來看私網流量已經下降了很多，觀察了幾天，比較穩定。節點2也沒有再自動重啟。

        最後的猜想，可能是由於私網網路太高導致私網網絡卡有擁堵，從而造成網路心跳丟失。