資料庫叢集自動重啟？Linux硬體錯誤日誌立大功！
環境：兩臺某想R680的物理機搭建一套2節點RAC，資料庫版本為ORACLE 11.2.0.4
一、故障問題現象
節點2頻繁發生重啟，從1月至2月發生多次重啟，甚至一天內3次重啟，讓人頭疼。
二、問題分析處理過程
1、檢查是否時間同步問題
首先懷疑是時間不同步造成的。
觀察現象是該伺服器的ntp時間同步offset過大（下圖offset為11376）
並在資料庫的CTSS日誌出現不正常的返回值
在這裡發現一個問題，就是時間源指向舊的時間源伺服器10.33.144.18和10.33.144.19，而伺服器在新的資料中心，所以修改為新資料的時間源伺服器11.8.13.1和11.8.13.9，並修改了BIOS時鐘，使系統時鐘和硬體時鐘時間一致。
至此，時間同步問題排除。
2、檢查資料庫日誌反應的問題
通過查ALERT日誌，發現有節點驅逐
又查CSSD日誌發現
顯示有磁碟的心跳，但無網路的心跳。
此時判斷：node 2 節點老是頻繁重啟，私網出問題的概率會較大，因此從網路處查。
node 2 每次重啟完以後，都能順利加入rac叢集，更不是時間同步的問題。
補充：
如果叢集中的節點連續丟失磁碟心跳或網路心跳，該節點就會被從叢集中驅逐，也就是節點重啟。組管理導致的節點重啟，我們稱之為node kill escalation（只有在11gR1以及以上版本適用）。
重啟需要在指定的時間（reboot time,一般為3秒）內完成。
網路心跳
如果某個節點連續丟失網路心跳達到閥值，misscount（預設為30秒，如果存在其他叢集管理軟體則為600秒），叢集會通過表決盤進行投票，使丟失網路心跳的節點被主節點驅逐出叢集，即節點重啟。
如果叢集只包含2個節點，則會出現腦裂，結果是節點號小的節點存活下來，即使是節點號小的節點存在網路問題。
磁碟心跳：ocssd.bin程序每秒鐘都會向所有表決盤（Voting File）註冊本節點的狀態資訊，這個過程叫做磁碟心跳。
如果某個節點連續丟失磁碟心跳達到閥值disk timeou(一般為200秒)，則該節點會自動重啟以保證叢集的一致性。
另外，CRS只要求[N/2]+1個表決盤可用即可，其中N為表決盤數量，一般為奇數。
3、核查是否網路的問題
這套RAC的心跳網是由ETH13和ETH15兩塊網絡卡組成，對應兩個交換機的兩個埠。
先後採取啟用宕掉交換機兩個埠和網絡卡口沒有解決問題，最後又採用換線、單獨拉線等解決辦法，發現線的光衰有點大，但重啟問題沒有最終解決。
4、檢查是否是硬體的問題
問題至此陷入了困境，換個思路既然網路和資料庫都可能不是問題，那麼硬體真的能獨善其身，超然之外麼？
答案是否定的，那就是硬體的問題。
在節點發生重啟時，資料庫的日誌裡有中斷的現象，那麼會不會是CPU和記憶體的問題呢？檢查下MCELOG日誌就知道了。
MCELOG：不容忽視的日誌
mcelog 是 x86 的 Linux 系統上用來檢查硬體錯誤，特別是記憶體和CPU錯誤的工具。它的日誌就是MCELOG.
一般來說大記憶體的伺服器容易出現記憶體上的問題，現在記憶體控制器都是整合在cpu裡，記憶體的校驗錯誤和CPU的問題易引起伺服器的重啟。
好了，下面我們看看MCELOG日誌的錯誤提示
ORACLE官方對MCELOG事件的解釋：
至此，問題浮出水面。和硬體廠商聯絡，刷主機板韌體程式，更換一根記憶體後問題最終解決。
三、問題總結與思考
1、不能忽視監控的作用。這次記憶體硬體的問題，在伺服器硬體監控平臺沒有被發現，這個需要聯絡廠商，繼續完善伺服器硬體監控的細粒度和敏感性
2、從日誌、網路、資料庫、系統、硬體等方面全面排查，問題終會被發現。
3、解決問題靠的是耐心和細心，進一步再進一步，問題終會被解決。
文章出處：高效運維