一、可导致节点重启的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 timeout(一般为200秒)，则该节点会自动重启以保证集群的一致性。另外，CRS只要求[N/2]+1个表决盘可用即可，其中N为表决盘数量，一般为奇数。

 IF
(Disk IO Time > Disktimeout) OR (Network IO time > Misscount)
THEN
REBOOT NODE
ELSE
DO NOT REBOOT
END IF;
----相关值的获取方法：
$crsctl get css disktimeout
$crsctl get css misscount
$crsctl get css reboottime

 2、oclsomon：这个进程负责监控ocssd是否挂起，如果发现ocssd.bin存在性能问题，则重启该节点(日志路径：<crs主目录>/log/<节点名称>/cssd/oclsomon/oclsomon.log)。

3、oprocd：这个进程只在Linux(10.2.0.4和以后版本引入了一个新的Oracle Clusterware Process Monitor Daemon (OPROCD)进程来监控系统状态和集群中的每个节点的健康状态)和Unix系统，并且第三方集群管理软件未安装的情况下才会出现。如果它发现节点挂起,则重启该节点。

通过以下命令查看css运行时的进程：# ps -ef |egrep "crsd.bin|ocssd.bin|evmd.bin|oprocd"

   
注意：以上的所有进程都是由脚本init.cssd产生的。

         下面是诊断节点重启问题是经常搜集的信息：

1．操作系统日志

2．<crs主目录>/log/<节点名称>/cssd/ocssd.log

3．oprocd.log(/etc/oracle/oprocd/*.log.* 或 /var/opt/oracle/oprocd/*.log.*)

4．<crs主目录>/log/<节点名称>/cssd/oclsomon/oclsomon.log

5．Oracle OSWatcher 报告

 

二、如何诊断节点重启问题：

 1、由ocssd导致的节点重启

      a、如果在ocssd.log中出现以下错误，则表示节点重启是由于丢失网络心跳。接下来需要查看和网络相关的信息，如操作系统日志，OSW报表（traceroute的输出），以确定网络层面（cluster interconnect）是否存在问题，并确定最终的原因。

[ CSSD]2012-03-02 23:56:18.749 [3086] >WARNING: clssnmPollingThread: node <node_name> at 50% heartbeat fatal, eviction in 14.494 seconds
[ CSSD]2012-03-02 23:56:25.749 [3086] >WARNING: clssnmPollingThread: node <node_name> at 75% heartbeat fatal, eviction in 7.494 seconds
[ CSSD]2012-03-02 23:56:32.749 [3086] >WARNING: clssnmPollingThread: node <node_name>at 90% heartbeat fatal, eviction in 0.494 seconds
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE: clssnmPollingThread: Eviction started for node <node_name>, flags 0x040d, state 3, wt4c 0
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE: clssnmDiscHelper: <node_name>, 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中出现以上信息的时间点要晚于节点的重启时间，则说明节点重启的原因不是丢失网络心跳。

     b、如果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 (<crs主目录>/log/$ORACLE_SID/cssd/oclsomon/oclsomon.log)中出现错误，则表示节点重启是由于ocssd进程挂起，由于ocssd进程拥有实时（RT）优先级，很可能此时操作系统存在资源（如cpu）竞争，接下来需要察看操作系统日志，OSW报表（vmstat，top的输出），以确定最终的原因。

 3、由oprocd导致的节点重启

     如果在oprocd日志(/etc/oracle/oprocd/hostname.oprocd.log)中出现以下信息，则表明节点重启是由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

   https://blogs.oracle.com/Database4CN/