前段时间某客户的一套核心系统Oracle RAC节点实例突然被重启，如下是简单的分析过程，供参考。
节点1 alert log如下：

我们可以看到，在14:06:28时，LMS1 进程被发现已经hung了超过70秒。 根据之前的时间点14:06:13 所报的信息来看，在14:06:13 时刻，已经LMS1进程等待gcs remote message超过95秒，这2个时间点前后相差了15秒。
根据时间点，我们可以大致推测至少在14:05:18时间点，LMS1进程已经hung。对于lms进程的check，Oracle 是20s检查一次，超过70s 无响应，则会被kill掉。根据这个原理，我们可以大致判断，lms1 进程hung的时间点到被kill的时间点，前后应该相差大概70+20=90秒。因此可能在14:04:43 时间点，lms1进程就出问题了。
由于lmhb进程负责check，那么我们首先来分析下该进程的trace内容，如下：

从上面的内容来看，14:05:13 报错lms1 进程超过38秒没有响应，根据计算，我们可以得知在14:04:35开始，lms1进程开始hung。hung的过程中表现出来的等待事件为gcs remote message。 同时也可以发现Oracle 认为在时间点CPU 使用率很高，而且还列出了TOP session.
然而仅仅从上述的分析，我们无法判断是什么原因导致实例被强行终止的。根据客户提供的信息，我还发现产生了一个diag文件，从该文件中我发现了如下的内容：

从上述信息我们可以看出，部分会话已经挂起。同时我们还能看出当时该数据库节点的load 其实并不高，平均只有2.5左右。同时数据库节点的物理内存还有2G的free memory。因此似乎从这一点仍然无法直接判断是否是因为资源的问题，导致LMS1进程hung。
在Oracle RAC的案例分析中，我们通常会去分析几个相关的核心进程，因此这里我们再来看下lmd进程是否有什么异常：

从节点1的lmd进程trace内容来看，从14：04：52左右开始出现类似kjddt2vb: valblk  [0.22] > local ts [0.21]这样的信息。这部分信息的出现，说明当时有数据块正在通过cache fusion进行传输，这与lms进程表现的gcs remote message 完全一致。 然而这仍然不能说明什么问题。
此外，我在trace中发现lms1 进程的call stack内容如下：

同时lms1进程的diag dump 信息如下：

根据上述的call stack信息，我认为根据Oracle bug 13539862 基本上完全一致。
Bug 13539862 : ORA-29770 AND LMHB (OSPID: 21429) IS TERMINATING THE INSTANCE
根据Oracle mos的描述，该bug所影响版本为11.2.0.2，但是并没说在之后的版本中已经修复，由于客户的环境为Oracle 11.2.0.4，因此是不是完全确认是这个bug 导致，这个难以确认；实际上，我们也遇到过多次bug在老版本出现，Oracle说明已经在新版本修复，但是发现仍然存在的这种情况。因此，我们不完全排除这个bug.
备注：该bug的call stack信息，需要使用Oracle 原厂账户进行查看。
除此之外，我认为还可能跟Oracle的read mostly locking特性有关系，这是Oracle DRM的功能之一；虽然Oracle support坚持认为trace中没有出现DRM相关的动作；即使如此，我们仍然建议屏蔽该特性。可以通过如下的方式：alter system set “_gc_read_mostly_locking”=false scope=spfile; alter system set “_gc_bypass_readers”=false scope=spfile;
上述是我的个人分析，然而oracle support似乎并不认同，认为可能是tickets不足导致的，实际上这一点很容易排除。 首先从故障前的awr数据也可以大致判断：

如果是ticket不足，那么flow controled的指标应该会比较高的。不过，这个awr是13-14点的，故障在14：05分，因此也不能完全否认。但是根据经验来看，我认为跟tickets不足的现象完全符合。
其次，从trace 内容也可以得到确认：

从trace 内容来看，实际上tickets还有750，只用了1/4。 基于这2种原因，我可以肯定的说，这不是tickets不足导致的。那么话又说回来，说了这么多，到底是神马问题导致的呢？ 前面说提到的Oracle Bug 13539862 吗？
我们从根本上来分析下，lms1进程为什么会hung ? 导致进程hung的原因，我认为无非就如下几种：
1） CPU 严重不足，即大家所说的CPU饥饿

2)  IO/memory问题，导致数据库极慢，以至于LMS1响应极度缓慢，例如swap使用极高。

3） cache fusion数据交互量极大

4)  Oracle bug

5） tickets不足（实际上，当数据交互较大时，就建议调整tickets数量)
上面的5个原因中，除了第4个，基本上其他的都可以排除。这里需要注意的是，如果要排除CPU的问题，那么我们可能还需要看数据库环境是什么？是虚拟化的还是物理机 ？比较巧合的是客户的这套环境正好是IBM PowerVM，这里我不否认PowerVM的优点，实际上在我们这一年的案例中，至少遇到3起PowerVM导致rac节点重启的案例。
其中比较关键的一点是PowerVM的processor folding功能，俗称CPU折叠，当该功能启用时，PowerVM会动态调节资源。这很可能会导致Oracle 进程无法获得资源的情况。
PowerVM的虚拟化比较复杂，其中包括微分区、VIOS等，微分区即是将CPU进行分片，一个CPU可以最多分1份，然后以1%的粒度来动态调整资源。那么这次故障是不是PowerVM的这个功能导致的呢？ 我认为可能性还是比较大的，暂时分析到这里！