以前同事发过来一个rac log，让帮忙分析一下，该问题2011年我也看过，当时没有详细分析，这次我们再来看看，
能否找到根本的原因，首先我们来看database的alert log：

从上面错误可以清楚的看到，在时间点Mon Sep 17 10:35:00 2012 出现故障，数据库实例的asmb进程出现故障，导致
数据库实例无法跟asm进行交互。

这里补充一下，数据库实例和asm实例都存在asmb进程，我猜测应该是数据库实例的asmb进程和asm实例的asmb进程
进行交互，只要其中一个asmb进程出现故障，那么可能都会导致数据库crash。

我们来看上面提到的trace cmsdb31_asmb_1155.trc内容，如下：

我们看到这个trace基本上没有什么信息，就只有ora-15064和ora-03113错误，这2个错误很好理解，不多说。
后面还有一句ksuitm: waiting for [5] seconds before killing DIAG 其实也值得我们关注。

这个oracle 10g中是通过一个隐含参数来进行控制的：

该参数默认是5s，也就上面错误提到的5s，下面是关于该参数的描述：
number of seconds ksuitm waits before killing diag

这里解释下ksu是什么意思：kernel service user 的简称。所以这里不难猜测ksuitm是一个函数，大概是下面的简称：
kernel service user diag wait time。

也就是说diag进程默认等待超过5s，就会被kill掉。

接着我们来继续看asm实例的alert log，如下：

从上面信息可以看到，在Mon Sep 17 10:35:15 2012，asm实例启动了asmb进程，这里说明一下，asm实例的asmb进程
是需要进行数据交互时，才会启动，否则不会启动，我通过vm asm环境测试发现的。

另外通过分析asm的pmon trace，发现大量如下信息：

通过查询mos发现，这个是一个bug，不过无关紧要，如下描述:

从前面的信息，我们可以发现，都没有什么具体价值的东西，下面我们来看看diag的trace，看看能不能找到一些蛛丝马迹。

搜索asmb，找到如下信息：

似乎没有什么异常，ASM background timer是一个idle event，虽然wait time挺长的，但是这里是一个累积值。

另外看下了diag进程的信息，也没有什么特别的，如下：

可以看到diag 的等待时间确实挺长的，以至于该进程被kill。

通过strace 跟踪asm和数据库实例的asmb进程发现都是如下类似的几个函数，没有别的：

不过至于具体是怎么交互，就不清楚了。

从diag trace看也没有发现任何的死进程，如下：
Orapids on dead process list: [count = 0]

综上所掌握的信息来看，就是数据库实例的asmb进程crash，然后导致数据库实例crash，进而被crs给重启了。

到最后我们都没有搞清楚数据库实例的asmb进程为何会crash 掉。 从数据库alert log看，故障前6天都是正常的，alert中
只有redo切换信息，而且并不频繁，所以最后我不得不再次怀疑是oracle bug了。

我记得该客户除了这3套10.2.0.3 rac(asm)外，还有另外2套10.2.0.4、10.2.0.5的asm rac，几乎从来没有出现过问题。

最后还是没有找到根本原因，不知道是不是应该直接建议该客户直接升级得了。

mos有个bug 有点沾边，虽然是说的11.1.0.7，但是以下版本可能也会受影响，但是关于该bug的具体信息看不到，比较遗憾。

Bug 9246245 – Instance crash due to ORA-15064 in RAC [ID 9246245.8]

另外一种猜测就是有可能当前系统负载过高，可能触发什么bug之类的，不过这些都是猜测，总的来说，bug的可能性是非常之大的。