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

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

library cache: mutex X引发的故障

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

本文链接地址: library cache: mutex X引发的故障

客户一套10gR2 rac升级到11.2.0.3 rac 后,出现了严重性能问题,其中表现为一个节点负载极高,响应缓慢。

ucp库3节点负载很高,主要原因的latch过多导致,通过等待事件可以发现,存在大量的library cache latch争用:

另外,同awr报告我们可以也发现top 5排在第一位的也是该等待事件。
library cache: mutex X引发的故障插图

我们这里以时间点20121010 12:16:06进行分析:

我们可以看到785session 阻塞了672,同时被206所阻塞,785 session持有的event正是gc buffer busy acquire。

事实上再上述时间段内,上面2个event的等待也是比较高的,如下查询:

正好印证了Bug 12998795 – RAC hang with signature ‘gc current request’<='gc buffer busy acquire' [ID 12998795.8] 通过查询oracle metalink我们可以发现,该bug其实跟Bug 12847466 - RAC hang with waits 'gc current request'<='gc buffer busy acquire' 是一回事,可以通过调整oracle隐含参数_gc_read_mostly_locking 来解决。 这里补充一下: gc buffer busy acquire和gc buffer busy release 其实是以前版本中gc buffer busy的一个细粒度划分。 read mostly locking实际上是11.2 引入的一个特性,通过在mos查询,我们可以看到该特性还可能导致如下的几个bug(并且还都是rac环境):

我们知道导致library cahce:mutex X争用的无非就如下几个原因: 1) 硬解析过高 2) SQL High Version Counts 3) high reloads in the sql area 4) Shared pool设置问题 5) oracle bug(例如cursor_sharing设置为similar,force都可以导致,当然similar熟悉在11.2被废弃了) 从第一次的awr看,硬解析确实有些高,所以客户调整了cursor_sharing为force,硬解析降下去了,但是问题仍然没有解决。 从目前的信息来看,调整了cursor_sharing为force,并没有从根本上解决问题,甚至还有副作用。 从该现象来看,该问题也命中了oracle Bug 12797420 "library cache: mutex X" waits on DB instance handle with CURSOR_SHARING,通过检查 数据库alert log发现,cursr_sharing参数是在9号下午调整的:

通过分析Bug 12797420 - "library cache: mutex X" waits on DB instance handle with CURSOR_SHARING [ID 12797420.8]文档,可以发现 该bug其实在11.2.0.3的最新psu 11.2.0.3.3中已经修复 而前面提到的bug事实上也都在11.2.0.3.1 或11.2.0.3.2等psu中修复了,所以,我建议不采取调整隐含参数或安装个别patch的方式来解决 该问题,而是直接安装11.2.0.3的最新psu,这样不但能解决问题,而且还能避免一些其他的未知bug。 补充:由于部分bug例如12777508 在11.2.0.3.3中仍然未能修复,虽然目前未遭遇该bug,但是该bug是一个比较致命的bug,且在12.1版本中 才能修改,故建议仍然调整参数 "_gc_read_mostly_locking"=false。 最后我们来看一下上面提到的这个特性 read mostly locking,该特性只有在rac环境中才会存在,从gc参数就可以发现,是针对global cache, 从高查询文档发现该特性其实是从11.2.0.2才引入的,在11.2.0.1都中不存在。 通过观察试图V$CURRENT_BLOCK_SERVER 我们可以找到一些相关想信息:

我们来看官方文档针对这几个字段的描述: CLEANDC Reserved for internal use RCVDC Number of lock down-converts to S (shared) caused by instance recovery QUEUEDC Number of queued lock down-converts to NULL EVICTDC Number of lock down-converts to NULL caused by an SGA shrink WRITEDC Number of dirty blocks in read-mostly objects which were written and the X (exclusive) lock down-converted to S (shared) locks 这里的关键字段WRITEDC比较特性,提到了提个read-mostly objects的概念,从上面的描述我们不难猜出是这个含义: 针对global cache bufer中的脏块,如果oracle发现某些对象的脏块同时被read的比较多,那么会把 这些脏块所被持有的lock 级别降低,即从X lock降低到S lock模式。 当然,这里oracle必然存在一个监控的机制,比如它如何判断哪些对象的脏块仍然存在大量的read操作?以及是如何量化 这个多少的标准?我想应该是通过几个隐含参数来进行控制的。 我们知道对于mode为6的X lock,能降低到S lock模式,是一个非常好的设计,可以很大程度上降低lock争用。 只是oracle往往推出的一些新特性,都伴随着大量的bug,这个虽然令人厌烦不过也是一种进步! 这样再次说明,升级到新版本中,强烈建议安装最新的psu!

4 Responses to “library cache: mutex X引发的故障”

  1. oracle 11gR2 rac library cache: mutex X引发的故障 | EvilCode 邪恶代码 Says:

    […] 原文博客地址链接: library cache: mutex X引发的故障 […]

  2. Kevin Zhang Says:
  3. 那片飘飞的叶子 Says:

    风一次又一次打碎了叶子的梦,没有了往日的那份骄傲,有的只是一次又一次无奈的凄凉,一次又一次无望的抗争。终于,她飘落离了枝头。在漫长的刺骨寒冷的冬天里,叶子历尽了千辛万苦,尝尽了无尽

  4. 枕霜卧雪 Says:

    追寻block源头的session等待事件的时候是怎么做的?我看了半天也没明白为查找什么路径是这样的 session 1750-> session 672  -> session 785 -> session 206

Leave a Reply

You must be logged in to post a comment.