首先我们对能够导致节点重启的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)．<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 报告
下面结合自己的RAC环境出现节点重启问题进行分析：
查询节点1的oprocd.log，如下：
查看其它的日志信息，没有发现明显的错误信息，因此怀疑是ORACLE oprocd的时间参数设置不当；
下面对oprocd参数进行设置：
当我们设置diagwait参数时，需要停止所有rac节点的集群活动，停止顺序如下(如果集群式活动的，修改diagwait有可能会损害ocr);
1.root用户执行，停止所有节点的CRS
2.停止10.2.0.3到11.1.0.6版本的RAC中才引入的OPROCD进程(OS系统安装的DB版本是10.2.0.4)
3.检查是否还有CRS相关的资源在运行
4.在任意一个节点使用ROOT用户来设置DIAGWAIT的值（按照ORACLE的推荐，一般设置为13）
查看设置结果，如下：
5.启动所有节点的CRS资源
6.验证CRS是否正常运行
7.查看oprocd进程的状态
批注：11gR2之前版本的集群，ORACLE建议将Diagwait设置为13。从本质上讲,diagwait值在RAC环境中控制着两件关键的事情：
默认情况下,集群守护进程OPROCD的超时值为1秒和0.5秒的时间差，这意味着，如果OPROCD不能在 1.5秒内返回，系统会被重启。设置diagwait为推荐值13会将OPROCD的默认超时时差增加到10秒(diagwait - CSS重启时间[默认为3秒]),从而防止大量由于OPROCD没有在定义的时间内返回而导致的'假'的节点重启。对于繁忙的系统,1.5秒的默认值太小了。长期推荐的办法是将OPROCD超时提高到一个更为合理的值11秒（1秒休眠时间+10秒时间差）。
当节点驱逐/重启事件发生时，增加diagwait，我们更可能在重新启动之前将日志信息刷新到磁盘，因此，缩短寻找问题根本原因时间。
从11g第2版（11.2.0.1和更高版本）开始，这一变化不再是必要的。然而，对于之前的版本，这个改变必须在一个完整的停机时间进行，而且这个值不能通过补丁修正。因此，必须安排停机时间手动修改。鉴于已知通过设置diagwait解决的问题的数量，申请停机时间来修改它是值得的投入。请注意，因为这个值存储在Oracle集群注册表（OCR），如果您的确需要重建OCR或从一个之前的备份恢复，您可能需要重新设置diagwai。