1. 节点间的网络问题或者延时问题，由于丢失网络心跳导致的节点重启问题。对于这种原因导致的节点重启，诊断的方式和10g基本没有什么区别但是有一个误区要指出来，比如下面是一段GI alert log 信息，他们来自于node2
2018-05-17 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
2018-05-17 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
2018-05-17 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
2018-05-17 16:30:21.073 [cssd(11011) ]CRS-1632:Node node1 is being removed from the cluster in cluster incarnation 236379832
2018-05-17 16:30:21.086 [cssd(11011) ]CRS-1601:CSSD Reconfiguration complete. Active nodes are node2 .
如果你仅从上面的信息就说驱逐就是网络引起的，这是不对的。因为正常的网络心跳故障，rac会自动驱逐节点二，保留节点小的，即节点一。同时由于rebootless restart的介入 node eviction 首先导致的结果是GI stack重启，而不是直接节点重启，因此以上的信息并不一定说明节点node1是由于丢失网络心跳而被驱逐出集群的。
首先我们要验证， node2在报 node1 丢失网络心跳的时候node1的状态如何，如果说node1 已经重启或者存在严重的性能问题（可以通过os log 或者OSW 报告验证）那么node1 重启并不是由于node2发现node1丢失网络心跳造成的，而是由于node1出现问题后产生的结果，因此我们最近在好几家客户现场处理重启故障时发现，在我们对比时间节点时rac出现网络不通消息，对面节点已经出现故障了，os之前报了hardware error, 有的是从osw log中发现osw等一些基本的操作系统命令都没用了，如top vmstat等都不记东西了或者很不规律的写到日志，这种情况一般操作系统或者硬件层面的问题。另外、如果在node2报node1丢失节点心跳的时候，node1的ocssd.bin仍然正常运行（可以通过ocssd.log验证）或者node1也报丢失了和其他节点的网络心跳，那么node1的重启是由于GI node eviction导致的。
2.由于丢失磁盘心跳导致的节点重启，这种情况和10g的情况基本相同，只是在11g 里面同样由于rebootless restart的介入，在重启机制上多了一层。
集群必须能够访问最小数量的磁盘心跳文件，否则节点将会停止工作。当节点因为某种原因中止时， $GRID_HOME/log/<hostname>/alert<nodename>.log将会有CRS-1606报错，例如：
2013-01-26 10:15:47.177
[cssd(3743)]CRS-1606:The number of voting files available, 1, is less than the minimum number of voting files required, 2, resulting in CSSD termination to ensure data integrity; details at (:CSSNM00018:) in /u01/app/11.2.0/grid/log/apdbc76n1/cssd/ocssd.log
这种情况一般os message层面都有日志，可以检查存储链路状态等
3. 系统或者硬件故障，比如操作系统故障或者调度问题、CPU内存IO问题等
这类问题基本也可以分为硬件或者软件问题。大之前处理过的问题中，有关于操作系统软件问题的导致节点重启比如在重启时间节点前一小时间范围内sys% cpu占用非常高，而此时是半夜基本没有业务的；还有的是在重启前一小会操作系统的负载非常高，这些都会导致cpu不能及时响应其它节点而导致节点重启rac驱逐。对于高负载引起的驱逐问题，一般都是和内存的关系大点，因为rac的核心进程cssd cssdmonitor等进程的优先级都非常高，这种简单的负载高的情况下，我们更倾向于排查于内存相关，如有没有内存泄露、有没有大量的换页和分区的交换。因此需要知道这些信息，就必须有监控，这就是我们最近在和客户沟通时，明确要部署监控如osw。另外如果由于硬件故障，比如电源或者主板等硬件的故障，也会引起集群节点的重启这种案例在我们实际生产中偏多，有因为网卡故障而引起的网络问题而导致的节点重启，这种要归到第一点了，还有因为主板故障问题的，而表现出来的现象就是在某一瞬间所有日志都终止，像是电源被拔了一样，然后只有启动日志。在这几类情况中，无论是软件或者硬件引起的系统或者硬件故障、或者高负载故障，最终都会导致ocssd进程无法工作如hang住，或者ocssdmonitor 或者ocssdagent进程故障而引起的节点驱逐或者重启。 因此这类问题我一般归类为本地心跳故障即ocssd.bin 丢失了和Cssdagent/Cssdmonitor.bin的本地心跳导致的节点重启一般来说，我们会在oracssdagent_root.log 或oracssdmonitor_root.log 看到以下的信息。
2018-05-17 15: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
……
2018-05-17 15: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. 另外由于操作系统或者oracle bug 也会导致节点的重启，这类问题一般以oracle bug居多，表现多以集群核心进程cssd,crsd等占相当高的cpu利用率。针对这类问题我们主要要打上最新验证过的补丁为主。
关于重启或者驱逐这里有两个新特性不得不说：
1. rebootless restart
我们知道从11gR2 rac grid里面由于为了减少节点重启，减少故障恢复时间，rac 会试首先试去重启集群gi stack，而不重启节点本身，因此这里我们如果要从分析为什么会引起节点重启的角度去找原因，可以有以下几种情况：
a. 大的IO存在，这种情况一般发生在"member kill"升级为"node kill"时，由于Unix或者Linux操作系统中，数据库实例的一个或者多个进程处在"kill -9"不能直接终止的状态，例如，一个进程的状态是"D",D意味着"Uninterruptible sleep(通常IO)".进程的状态变为D的原因是因为进程已经发出一个IO请求,正在等OS完成该IO操作。直到此次IO请求完成前，该进程都不能被Killed. 所以当ocssd.bin进程去试着kill一个正在等IO完成的进程时，如果该IO请求在30秒或者更少的时间没有完成的话，该"member kill"请求将会time out,并且升级成"node kill"请求。
b. cssd进程被干掉或者无法工作
c. CSSDMONITOR 进程无法调度
d. 集群stack加入或者重新配置时超过了short_disk_timeout时间限制
2.Member Kill Escalation
关于这点，引用网上一段文摘：
在oracle 9i/10g 中，如果一个数据库实例需要驱逐(evict, alert 文件中会出现ora-29740错误）另一个实例时，需要通过LMON进程在控制文件（以下简称CF）中写入相应信息，当目标实例的LMON进程读取到相应的信息后，该实例shudown。但是，如果目标实例的LMON进程挂起而无法完成CF I/O的话，eviction将无法成功，这种情况有可能导致整个数据库挂起，需要dba手工干预。所以，从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,如果不能够完成，才会重新启动节点。
接下来我们用下面的例子说明Member Kill Escalation是如何工作的。
a.实例2发现实例1的LMS1进程出现问题，并发出member kill request.
实例2 Alert log：
Sat Jul 24 10:37:37 2010
LMS1 (ospid: 22636) has detected no messaging activity from instance 1
LMS1 (ospid: 22636) issues an IMR to resolve the situation
Please check LMS1 trace file for more detail.
Sat Jul 24 10:37:37 2010 <======= 实例2发出reconfiguration请求
Communications reconfiguration: instance_number 1
Sat Jul 24 10:38:25 2010
Evicting instance 1 from cluster
Waiting for instances to leave:
1
Sat Jul 24 10:38:45 2010 <===== 在reconfiguration请求发出20秒之后实例1仍然没有离开集群，实例2发出了member kill的请求。
Remote instance kill is issued with system inc 10
Remote instance kill map (size 1) : 1
Sat Jul 24 10:38:55 2010
Waiting for instances to leave:
1
b. 节点2的ocssd.bin收到member kill请求之后，向节点1的KD发出了请求，要求终止节点1的lmon进程。
节点2 ocssd.log：
2010-07-24 10:38:45.112: [ CSSD][1091119424]clssgmExecuteClientRequest: Member kill request from client (0x2aaab4178470)
2010-07-24 10:38:45.113: [ CSSD][1091119424]clssgmReqMemberKill: Kill requested map 0x00000001 flags 0x2 escalate 0xffffffff <========= member kill escalation还没有发生。
2010-07-24 10:38:45.113: [ CSSD][1281349952]clssgmMbrKillThread: Kill requested map 0x00000001 id 2 Group name DBOR08P flags 0x00000001 start time 0x98117058 end time 0x9811e77c time out 30500 req node 2 <======= member kill 需要在30秒内完成。
如果节点1能够在指定的时间内（30秒）终止本地lmon进程，member kill 就不会被escalation 成为node kill。
c.由于member kill 没有在指定的时间内完成，被escalate 为node kill，即节点1 重启。
节点2 ocssd.log：
2010-07-24 10:39:15.619: [ CSSD][1281349952]clssgmMbrKillThread: Time up: Start time -1743687592 End time -1743657092 Current time -1743657092 timeout 30500
2010-07-24 10:39:15.619: [ CSSD][1281349952]clssgmMbrKillThread: Member kill request complete.
2010-07-24 10:39:15.619: [ CSSD][1281349952]clssgmMbrKillSendEvent: Missing answers or immediate escalation: Req member 1 Req node 2 Number of answers expected 0 Number of answers outstanding 1
2010-07-24 10:39:15.620: [ CSSD][1281349952]clssgmMbrKillEsc: Escalating node 1 Member request 0x00000001 Member success 0x00000000 Member failure 0x00000000 Number left to kill 1
2010-07-24 10:39:15.620: [ CSSD][1281349952]clssnmKillNode: node 1 (ghlx062ptlge) kill initiated <====== 节点1被重启
因此对于这种member kill Escalation 的原因一般有无法中断的IO，还有就是僵尸进程高负载问题而引起的ocssd进程不能把出问题的故障实例干掉，而需要重启节点。
以上是个人总结，欢迎补充或者指出有需要
