本文對如何診斷11gR2 GI環境下的節點重啟問題進行了一些介紹。

首先，像10g版本一樣，我們首先介紹在GI中能夠導致節點重啟的進程。
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 耗盡。
Linux OSWbb v5.0 node1
SNAP_INTERVAL 30
CPU_COUNT 8
OSWBB_ARCHIVE_DEST /osw/archive
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa
……
zzz ***Mon Aug 30 17:55:21 CST 2012
158 6 4200956 923940 7664 19088464 0 0 1296 3574 11153 231579 0 100 0 0 0
zzz ***Mon Aug 30 17:55:53 CST 2012
135 4 4200956 923760 7812 19089344 0 0 4 45 570 14563 0 100 0 0 0
zzz ***Mon Aug 30 17:56:53 CST 2012
126 2 4200956 923784 8396 19083620 0 0 196 1121 651 15941 2 98 0 0 0

對於這種原因導致的重啟問題，也適用於10g。

本文只是對11gR2診斷節點重啟問題進行了簡單的介紹，更詳細的內容，請參考以下的內容
Note 1050693.1 : Troubleshooting 11.2 Clusterware Node Evictions (Reboots)

11gR2 如何診斷節點重啟問題