本文对如何诊断RAC环境中节点重启问题进行了介绍。适用于10gR2和11gR1.
首先我们对能够导致节点重启的CRS进程进行介绍。
1.ocssd : 它的主要功能是节点监控（Node Monitoring）和组管理(Group Management),它是CRS的核心进程之一。节点监控是指监控集群中节点的健康，监控的方法是通过网络心跳(network heartbeat)和磁盘心跳（disk heartbeat）实现的，如果集群中的节点连续丢失磁盘心跳或网络心跳，该节点就会被从集群中驱逐，也就是节点重启。组管理导致的节点重启，我们称之为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为表决盘数量，一般为奇数。
2.oclsomon：这个进程负责监控ocssd是否挂起，如果发现ocssd.bin存在性能问题，则重启该节点。
3.oprocd：这个进程只在Linux和Unix系统，并且第三方集群管理软件未安装的情况下才会出现。如果它发现节点挂起,则重启该节点。
注意：以上的所有进程都是由脚本init.cssd产生的。
接下来是诊断节点重启问题是经常搜集的信息。
1．操作系统日志
2．/log//cssd/ocssd.log
3．oprocd.log(/etc/Oracle/oprocd/*.log.* 或 /var/opt/oracle/oprocd/*.log.*)
4．/log//cssd/oclsomon/oclsomon.log
5. Oracle OSWatcher 报告
接下来我们讨论如何诊断节点重启问题。
1．由ocssd导致的节点重启。
如果在ocssd.log中出现以下错误，则表示节点重启是由于丢失网络心跳。接下来需要查看和网络相关的信息，如操作系统日志，OSW报表（traceroute的输出），以确定网络层面（cluster interconnect）是否存在问题，并确定最终的原因。
[ CSSD]2012-03-02 23:56:18.749 [3086] >WARNING: clssnmPollingThread: node at 50% heartbeat fatal, eviction in 14.494 seconds
[ CSSD]2012-03-02 23:56:25.749 [3086] >WARNING: clssnmPollingThread: node at 75% heartbeat fatal, eviction in 7.494 seconds
[ CSSD]2012-03-02 23:56:32.749 [3086] >WARNING: clssnmPollingThread: node at 90% heartbeat fatal, eviction in 0.494 seconds
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE: clssnmPollingThread: Eviction started for node , flags 0x040d, state 3, wt4c 0
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE: clssnmDiscHelper: , node(4) connection failed, con (1128a5530), probe(0)
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE: clssnmDiscHelper: node 4 clean up, con (1128a5530), init state 5, cur state 5
[CSSD]2012-03-02 23:56:33.243 [3600] >TRACE: clssnmDoSyncUpdate: Initiating sync 196446491
[CSSD]2012-03-02 23:56:33.243 [3600] >TRACE: clssnmDoSyncUpdate: diskTimeout set to (27000)ms
注意：如果在主节点的ocssd.log中出现以上信息的时间点要晚于节点的重启时间，则说明节点重启的原因不是丢失网络心跳。
如果ocssd.log中出现以下错误，则表示节点重启是由于丢失磁盘心跳。接下来需要查看操作系统日志，OSWatcher报告（iostat的输出），以确定i/o层面是否存在问题，并确定最终的原因。
2010-08-13 18:34:37.423: [ CSSD][150477728]clssnmvDiskOpen: Opening /dev/sdb8
2010-08-13 18:34:37.423: [ CLSF][150477728]Opened hdl:0xf4336530 for dev:/dev/sdb8:
2010-08-13 18:34:37.429: [ SKGFD][150477728]ERROR: -9(Error 27072, OS Error (Linux Error: 5: Input/output error
Additional information: 4
Additional information: 720913
Additional information: -1)
)
2010-08-13 18:34:37.429: [ CSSD][150477728](:CSSNM00060: )clssnmvReadBlocks: read failed at offset 17 of /dev/sdb8
2010-08-13 18:34:38.205: [ CSSD][4110736288](:CSSNM00058: )clssnmvDiskCheck: No I/O completions for 200880 ms for voting file /dev/sdb8)
2010-08-13 18:34:38.206: [ CSSD][4110736288](:CSSNM00018: )clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1
2010-08-13 18:34:38.206: [ CSSD][4110736288]###################################
2010-08-13 18:34:38.206: [ CSSD][4110736288]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
2010-08-13 18:34:38.206: [ CSSD][4110736288]###################################
2. 由oclsomon导致的节点重启。
如果在oclsomon.log 中出现错误，则表示节点重启是由于ocssd进程挂起，由于ocssd进程拥有实时（RT）优先级，很可能此时操作系统存在资源（如cpu）竞争，接下来需要察看操作系统日志，OSW报表（vmstat，top的输出），以确定最终的原因。
3．由oprocd导致的节点重启。
如果在oprocd日志中出现以下信息，则表明节点重启是由oprocd进程导致。
Dec 21 16:15:30.369857 | LASTGASP | AlarmHandler: timeout(2312 msec) exceeds interval(1000 msec)+margin(500 msec). Rebooting NOW.
由于oprocd进程通过查看系统时间以确定操作系统是否挂起，正确的配置ntp（或其他时间同步软件），调整diagwait=13 可以避免节点重启，另外，如果需要大幅度修改系时间，建议首先停止CRS，在修改完成之后再重新启动。当然，我们也不排除操作系统挂起导致oprocd重启节点，所以，也需要查看OSWatcher报告（vmstat，top的输出），以确定最终的原因。
本文只是对诊断节点重启问题的思路进行了介绍，在具体实际问题当中还需要灵活运用。
关于更多的信息，请阅读以下的MOS 文章。
Note 265769.1 ：Troubleshooting 10g and 11.1 Clusterware Reboots
Note 1050693.1 ：Troubleshooting 11.2 Clusterware Node Evictions (Reboots)