如何诊断RAC环境中节点重启问题（适用于11gR2）
?一、可導致節點重啟的CRS進程進行：
1、Ocssd.bin：這個進程的功能和10g版本的功能基本差不多，主要是節點監控（Node Monitoring）和組管理(Group Management)。詳細的信息請參考之前文章“如何診斷節點重啟問題”了解詳細的內容。
2、Cssdagent.bin/Cssdmonitor.bin：這2個進程是11gR2新增加的。他們的工作主要是同ocssd.bin進行本地心跳（Local HeartBeat），默認情況下每1秒鐘一次。本地心跳的作用是監控本地的ocssd.bin進程是否正常運行。同時，他們也監控自己到ocssd.bin之間的連接。所以，我們可以認為，這兩個進程的出現代替了10g中的oclsomon/oclsvmon（如果第三方集群管理軟件存在）和oprocd。
11gR2的重要的新特性：rebootless restart,這個新特性是在版本11.2.0.2被介紹的。從這個版本開始,當集群中的某個節點被驅逐（例如丟失網絡心跳）或者該節點的ocssd.bin出現問題時，集群將不會直接重新啟動該節點，而是首先嘗試重新啟動GI stack來解決問題，如果GI stack不能夠在指定的時間內（short disk I/O timeout）完成graceful shutdown，才會重新啟動節點，之后，存活的節點對集群進行重新配置。 |
下面我們列出在診斷11gR2 節點重啟問題時經常搜集的信息：
1. Ocssd.log
2. Cssdagent 和 cssdmonitor logs
<GI_home>/log/<node_name>/agent/ohasd/oracssdagent_root/oracssdagent_root.log
<GI_home>/log/<node_name>/agent/ohasd/oracssdmonitor_root_root/oracssdmonitor_root.log
3. Cluster alert log
<GI_home>/log/<node_name>/alert<node_name>.log
4. OS log
5. OSW 或者 CHM 報告
二、如何診斷常見節點重啟問題：
?????1、由于丟失網絡心跳導致的節點重啟問題。對于這種原因導致的節點重啟，診斷的方式和10g基本沒有什么區別。但是有一個誤區需要指出來。下面是一段GI alert log 信息，他們來自于node2
| 2012-08-15 16:30:06.554 [cssd(11011) ]CRS-1612:Network communication with node node1 (1) missing for 50% of timeout interval. Removal of this node from cluster in 14.510 seconds 2012-08-15 16:30:13.586 [cssd(11011) ]CRS-1611:Network communication with node node1 (1) missing for 75% of timeout interval. Removal of this node from cluster in 7.470 seconds 2012-08-15 16:30:18.606 [cssd(11011) ]CRS-1610:Network communication with node node1 (1) missing for 90% of timeout interval. Removal of this node from cluster in 2.450 seconds 2012-08-15 16:30:21.073 [cssd(11011) ]CRS-1632:Node node1 is being removed from the cluster in cluster incarnation 236379832 2012-08-15 16:30:21.086 [cssd(11011) ]CRS-1601:CSSD Reconfiguration complete. Active nodes are node2 . |
????? 以上的信息并不一定說明節點node1是由于丟失網絡心跳而被驅逐出集群的，首先我們要驗證， node2在報 node1 丟失網絡心跳的時候node1 的狀態，如果說node1 已經重啟或者存在嚴重的性能問題（可以通過os log 或者OSW 報告驗證），那么node1 重啟并不是由于node2發現node1丟失網絡心跳造成的，而是由于node1出現問題后產生的結果，這里的reconfiguration，僅僅是集群成員信息的更新，并不會導致節點重啟。而且，從11.2.0.2開始，由于rebootless restart的介入，node eviction 首先導致的結果是GI stack重啟，而不是直接節點重啟。但是，如果在node2報node1丟失節點心跳的時候，node1的ocssd.bin仍然正常運行（可以通過ocssd.log驗證）或者node1也報丟失了和其他節點的網絡心跳，那么node1的重啟是由于GI node eviction導致的。
???? 2、由于丟失磁盤心跳導致的節點重啟，這種情況和10g的情況基本相同，在這里不作詳細的描述。
???? 3、由于ocssd.bin 丟失了和Cssdagent/Cssdmonitor.bin的本地心跳導致的節點重啟，對于這種情況，一般來說，我們會在oracssdagent_root.log 或oracssdmonitor_root.log 看到以下的信息。
| 2012-07-23 14:09:58.506: [ USRTHRD][1095805248] (:CLSN00111: )clsnproc_needreboot: Impending reboot at 75% of limit 28030; disk timeout 28030, network timeout 26380, last heartbeat from CSSD at epoch seconds 1343023777.410, 21091 milliseconds ago based on invariant clock 269251595; now polling at 100 ms …… 2012-07-23 14:10:02.704: [ USRTHRD][1095805248] (:CLSN00111: )clsnproc_needreboot: Impending reboot at 90% of limit 28030; disk timeout 28030, network timeout 26380, last heartbeat from CSSD at epoch seconds 1343023777.410, 25291 milliseconds ago based on invariant clock 269251595; now polling at 100 ms …… |
?
???? 從上面的信息我們看到本地心跳的timeout時間為28秒左右（misscount – reboot time）。
???? 4、由于操作系統資源競爭導致的節點重啟。 如果說操作系統的資源被耗盡或者存在嚴重的競爭，也會導致ocssd.bin不能正常工作，造成節點重啟。對于這種情況，雖然重啟操作系統的命令會由ocssd.bin發出，但是真正的原因是os資源競爭。以下是一小段OSW輸出，它顯示了 在節點重啟之前 cpu 耗盡。
??對于這種原因導致的重啟問題，也適用于10g。
?
? 關于更多的信息，請閱讀以下的MOS 文章：
?Note 1050693.1 ：Troubleshooting 11.2 Clusterware Node Evictions (Reboots)
?https://blogs.oracle.com/Database4CN/
?
轉載于:https://blog.51cto.com/8858975/1785800
總結
以上是生活随笔為你收集整理的如何诊断RAC环境中节点重启问题（适用于11gR2）的全部內容，希望文章能夠幫你解決所遇到的問題。
