某系统的其中一个RAC节点的db实例被干掉并自动重启了，如下是该实例的alert log信息：

我们可以看到，该实例在13:17:07 秒被LMS0进程强行终止掉了，接着该实例在13:17:17 被正常启动。
在该实例被强行终止之前，有一点关键信息是值得我们注意的，如下：

从这部分信息，我们可以大致判断，在13:16:56时，Oracle已经发现LMON进程长时间没有检测到心跳了，这个时间长达204秒。
如果根据时间向前推进，在13:13:32时间点，实际上Lmon进程就开始出现异常了。 我们也可以看到在13:13:45时间点，出现了
一个ora-3136错误。一般来讲，这个waring跟系统的负载可能有极大的关系，例如资源使用极高，可能出现超时的情况。

从alert log信息来看，Oracle 让我们去查看LMD0/LMS0 以及diag的信息来进行进一步的分析。那么我们首先就来看一下LMD0进程的信息：

从LMD0进程的信息来看，可以发现该进程（lmd0）已经等待了258秒，等待事件为ges remote message，除此之外，没有其他的信息了。

既然这样，那我们继续来看下LMS0进程的信息：

LMS0进程的信息似乎也没有太多的价值。最后我们只能看看diag的信息了，Oracle在将所有进程kill之前进行了一次dump。

从前面的load来看，load信息如下：
loadavg : 62.17 35.29 18.12

这里简单解释一下，这3个loadavg值表示该主机分别在1分钟，5分钟，15分钟内的平均load值。 显然，这里我们不看后面2个指标了。
根据时间点，我们这里看第一个loadavg值是62.17. 这个值已经超出CPU的数倍了，由此我们不难判断在13:16:56向前推进1分钟的时间内
系统的load是极高的。

对于LMON进程，主要是监控RAC的GES信息，当然其作用不仅仅局限于此，其还负责检查集群中每个节点的健康情况，当有节点出现故障是，
负责进行reconfig以及GRD(global resource Directory)的恢复等等。我们知道AC的脑裂机制，如果IO fencing是Oracle本身来完成，也
就是说由CLusterware来完成。那么Lmon进程检查到实例级别出现脑裂时，会通知clusterware来进行脑裂操作，然而其并不会等待clusterware
的处理结果。当等待超过一定时间，那么LMON进程会自动触发IMR(instance membership recovery)，这实际上也就是我们所说的
Instance membership reconfig。

对于报错中提到的LMON进程无法获得心跳了，那么LMON进程的心跳是什么呢？ lmon进程主要通过2种心跳机制来判断集群节点的状态：

1) 网络心跳 （主要是通过ping进行检测）
2) 控制文件磁盘心跳，类似ckpt进程每3s更新一次controlfile的机制。

那么什么情况下，会导致LMON无法获得心跳呢？

一般来讲有可能是该进程无法获得latch或者系统的资源不足，导致LMON进程无法正常工作。而这里我们也确实发现系统的load极高。
从上面的进程详细信息来看，我们也确实发现该进程一直在等待一个latch，同时有其他的10个进程正在等待LMON进程，这其中的等待
就包括LMON,ASMB，ckpt进程等等。从diag的dump来看，提示lmon进程已经等待了216秒。

从process dump我们还可以看到该进程一直无法获得的latch是可能是被如下进程所持有：

possible holder pid = 792 ospid=15095

不过可惜的是，我搜索diag日志，居然找不到pid 792这个会话。 我们知道diag的trace中的process state dump信息是根据PID排序的。
我发现dump内容到process 69就结束了。从PID来看，该实例在出问题的时候，起码都800个process以上，dump的内容不可能只有这么一点。

从2节点的核心进程的日志也看不到有价值的信息。后面监控了一段时间发现该节点cpu几乎都是90%以上，很多时候甚至100%。

检查发现是CBC latch，而且都是一些报表的SQL。

对于这个case，我仍然感觉可能是资源异常导致LMON进程异常，最后Oracle 检测到该进程长时间没有心跳，最终终止了该实例。

基于这个假设，我打算在自己的VM Rac环境(Linux +10.2.0.5)测试一下，如果某个节点CPU使用率极高的情况下，是否会导致LMON进程异常。

不过遗憾的是，我并没有模拟出这种情况，如下是我的模拟过程：

利用shell 来模拟cpu的消耗：

调用该脚本即可：
[root@rac1 ~]# ./kill_cpu.sh 1
kill  17449 ;

这样测试了10分钟，发现Rac毫无反应，于是我又模拟了latch: cache buffer chains. 以此来尽可能的将该节点的CPU消耗光。

如下是该节点的CPU使用情况：

我们可以看到在08:43:16 到 08:46:44 之间，rac 节点1其实hang了很长时间，可惜这个数据库节点都没有挂。

我只能说Oracle 太强悍了，我檫。