这里简要的描述了RAC 环境中造成节点重启或者CRS意外重启的几个主要事件。

原因：

如果节点重启是Oracle进程造成的，但是日志并没有显示任何错误，那么引起节点重启的进程就是oprocd，cssmonitor和cssdagent。当节点挂起一段时间或者一个或多个重要CRS进程无法获取cpu资源，就会造成这样的情况。因为这些进程是实时运行的，问题很可能是因为进程无法获取足够的内存而不是因为无法获取cpu资源。内核正在大量交换页面，swap空间使用比较严重或者正在忙碌于扫描内存寻找可以释放的页面。

处理方法：

2）如果操作系统是AIX，调整AIX VM参数到建议值。参考文档 811293.1 (RAC and Oracle Clusterware Best Practices and Starter Kit (AIX))

3）如果操作系统是linux，设置hugepages并且设置内核参数vm.min_free_kbytes为保留512MB 并且swappiness设置为100

注意：设置hugepages之后，memory_target就无法设置。

4）检查是否大量的内存都分配给IO buffer cache，和OS厂商讨论找到减少IO buffer cache的方法或者增加内存从IO buffer cache回收率。

5）增加物理内存

这样的情况是由于网络心跳断开或者脑裂的引起的。在两个节点的环境，节点2频繁重启一般都意味着节点2因为脑裂被踢出集群。在节点重启之前，ocssd.log都会显示网络心跳丢失或者脑裂的信息。

原因：

节点间私有网络端口，节点无法进行通讯。这样的通讯错误可能是单向的，也可能是双向的。

处理办法:

修复网络问题，确保所有的网络组件比如交换机和网卡都是正常工作的。确保ssh在私有网络可以正常通讯。一般重启之后，网络问题都可以恢复正常。

ocssd.log显示节点重启是因为无法访问大多数的voting disk

原因：

CRS正常工作必须要访问大多数的voting disk。如果大部分的voting disk出了问题造成CRS无法访问，那么CRS就无法保证集群的完整性，这样CRS就会重启节点。

处理方法：

修复voting disk的问题，确保voting disk是可用的，并且可以被oracle用户、grid用户或者CRS/GI HOME的所有者账户访问。如果voting disk不存在于ASM里，可以使用dd工具测试设备是否可以正常访问。"dd if= of=/dev/null bs=1024 count=10240"

剩下节点的ocssd.log显示，member kill请求升级为node kill请求。

原因：

从11.1开始，在数据层面无法踢出数据库或者asm实例意味着CRS将会处理并尝试kill掉出问题的实例。这就是member kill请求。如果CRS无法kill掉出了问题的实例，那么CRS会重启故障节点因为member kill请求升级为node kill请求。

处理方法：

找出asm或者数据库实例无法在数据库层面踢出集群的原因。一个普遍的原因是因为实例hang住并且不能响应远端实例的将其关闭的请求。另一个原因是一个或者多个实例进程不能被杀掉。比如某个进程处于IO睡眠状态。

原因：

从11.2.0.2开始，如果CRS因为以上的原因需要重启节点，那么CRS首先会在重启节点之前尝试自己重启。只有当他无法成功重启自己的时候，CRS才会重启节点来实现强制重启自己。

处理方法：

检查以上节点重启的原因，根据以上列出的处理方法处理。