如何進行rac節點頻繁重啟的問題分析

如何進行rac節點頻繁重啟的問題分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

環境：兩臺聯想R680的物理機搭建一套2節點RAC，數據庫版本為ORACLE 11.2.0.4

一、故障問題現象：
節點2頻繁發生重啟，從1月至2月發生多次重啟，甚至一天內3次重啟，讓人頭疼。

二、問題分析處理過程：

1、時間同步問題
首先懷疑是時間不同步造成的。
觀察現象是該服務器的ntp時間同步offset過大

并在數據庫的CTSS日志出現不正常的返回值

在這里發現一個問題，就是時間源指向舊的時間源服務器，而服務器在新的數據中心，所以修改為新數據中心的時間源服務器并修改了BIOS時鐘，使系統時鐘和硬件時鐘時間一致。至此，時間同步問題排除。

2、數據庫日志反應的問題

通過查ALERT日志，發現有節點驅逐

又查CSSD日志發現

顯示有磁盤的心跳，但無網絡的心跳。

此時判斷：node 2 節點老是頻繁重啟，私網出問題的概率會較大，因此從網絡處查。node 2 每次重啟完以后，都能順利加入rac集群，更不是時間同步的問題。 

補充：

如果集群中的節點連續丟失磁盤心跳或網絡心跳，該節點就會被從集群中驅逐，也就是節點重啟。組管理導致的節點重啟，我們稱之為node kill escalation（只有在11gR1以及以上版本適用）。重啟需要在指定的時間（reboot time,一般為3秒）內完成。

網絡心跳:ocssd.bin進程每秒鐘向集群中的各個節點通過私網發送網絡心跳信息，以確認各個節點是否正常。如果某個節點連續丟失網絡心跳達到閥值，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的問題易引起服務器的重啟。

至此，問題浮出水面。和硬件廠商聯系，刷主板固件程序，更換一根內存后問題最終解決。

三、問題總結與思考：

1、不能忽視監控的作用。這次內存硬件的問題，在服務器硬件監控平臺沒有被發現，這個需要聯系廠商，繼續完善服務器硬件監控的細粒度和敏感性

2、從日志、網絡、數據庫、系統、硬件等方面全面排查，問題終會被發現。

3、解決問題靠的是耐心和細心，進一步再進一步，問題終會被解決。

看完上述內容，你們掌握如何進行rac節點頻繁重啟的問題分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！