当前位置: 首页 >> 技术文章 >> 经验:Library Cache Lock之异常分析-云和恩墨技术通讯九月精选
经验:Library Cache Lock之异常分析-云和恩墨技术通讯九月精选
发布时间:2019-09-25 发布人:怀晓明 宋志强 951


图示


Oracle利用library cache lock和library cache pin来控制对library cache object的并发访问,library cache lock是在访问或修改库高速缓冲期的对象时,对库高速缓冲区具柄获得的锁,在获取library cache lock的过程中,如果发生争用,则等待library cache lock事件。当大量library cache lock等待出现时,很可能对数据库的性能造成较大的影响。在此我们分享一个近期的客户故障案例,供大家参考。


问题描述


某客户生产系统核心数据库在9月9日上午11点发出告警,信息显示该库有3522条运行超过30秒的超时会话,并且,应用人员反馈系统服务出现异常。


图示


图示


问题分析


该数据库的告警监控是每5分钟检测一次,而在10:55并未有超时短信报出,这说明超时会话的数量是在最近5分钟内积累起来的,数据库应当遭遇到了某种计划外的操作,才会导致如此大量的超时。


查看故障期间的等待事件信息,发现当时数据库有大量的library cache lock和library cache: mutex X等待事件,数据库压力较大。11:01:23时数据库的等待事件状况如下图所示:


图示


查看产生这两个等待事件的SQL信息,发现两条sql语句分别是9jypktq9h6p3r和7hzh3urqxjz6n。


图示


图示


查看这两条SQL的具体文本,发现均是对表uxxxxxxr进行查询。

9jypktq9h6p3r的sql文本为:select m.aaaaa,m.bbbb ……from  uxxxxxxrwhere m.dddd=:17hzh3urqxjz6n的sql文本为:select a.*,b.yyyyyyfrom uxxxxxxr a,nxxxxxxs bwhere ……(省略部分信息)


并且,查看数据库的DDL脚本监控,发现在故障期间表uxxxxxxr的索引有重建动作,最早一个发生在10:57:26表uxxxxxxr的一个主键分区进行过rebuild的操作:


图示


产生library cache lock的原因通常有三种:登录密码错误尝试过多、热表收集统计信息和SQL解析失败。而索引重建会引起统计信息变化,统计信息变化引起SQL重新解析,并且表uxxxxxxr是该数据库上的核心表之一,也是该库的热表,使用主键访问表uxxxxxxr又是一个热点行为。所以统计信息的变化导致这类通过主键访问的SQL的游标失效,导致大量会话对同一SQL需几乎同时做重新解析,于是就引发了大量的library cache lock和library cache: mutex X等待,进而导致系统故障。


问题解决


本次故障主要是由于业务高峰期对表主键索引进行重建导致的,对于已在线的业务表和索引的DDL操作,必须经过严格的审核,避免产生类似问题。