本文对如何诊断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)