最近生產上出了很多“奇怪”的問題，比如下面要分享的一個故障，一套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也沒有再自動重啓。
最後的猜想，可能是由於私網網絡太高導致私網網卡有擁堵，從而造成網絡心跳丟失。