love wife love life —Roger的Oracle/MySQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

LMHB terminating RAC instance due to ora-29770

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL数据恢复博客

本文链接地址: LMHB terminating RAC instance due to ora-29770

前段时间某客户的一套核心系统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的这个功能导致的呢? 我认为可能性还是比较大的,暂时分析到这里!

Leave a Reply

You must be logged in to post a comment.