一、可导致节点重启的CRS进程进行：


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，才会重新启动节点，之后，存活的节点对集群进行重新配置。
当出现以下情况的时候，集群件（GI）会重新启动集群管理软件，而不是将节点重启。
1.当某个节点连续丢失网络心跳超过misscount时。
2.当某个节点不能访问大多数表决盘（VF）时。
3.当member kill被升级成为node kill的时候(一个实例驱逐其他实例时，在问题实例自己关闭之前，所有实例都处于等待状态，但是如果问题实例因为某些原因不能终止自己，发起驱逐的实例将发出 Member Kill 请求。从oracle 11gR1 开始，Member Kill Escalation的出现成功的解决了前面提到的情况。当实例eviction在指定的时间内（默认20秒）不能成功完成时，oracle会在css层面上（因为lmon进程会作为成员注册到css上，相应的内容会在今后的文章中介绍）产生一个新的进程 Kill Daemon（以下简称KD）, 终止目标实例的LMON进程以保证eviction 能够成功结束。如果情况更糟，KD进程也无法在指定的时间内（默认30秒）终止LMON进程，css 会把member kill升级为node kill，目标节点的css会重新启动本节点，以确保数据库的一致性。当然，如果您的版本是11.2.0.2或更高，由于新特性Rebootless restart的引入，node kill首先会尝试重新启动GI stack,如果不能够完成，才会重新启动节点。)


下面我们列出在诊断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。

 
  关于更多的信息，请阅读以下的MOS 文章：

 Note 1050693.1 ：Troubleshooting 11.2 Clusterware Node Evictions (Reboots)

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