经验：Library Cache Lock之异常分析-云和恩墨技术通讯精选

亲爱的读者朋友：

为了及时共享行业案例，通知共性问题，达成共享和提前预防，我们整理和编辑了《云和恩墨技术通讯》，通过对过去一段时间的知识回顾，故障归纳，以期提供有价值的信息供大家参考。同时，我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来，为您提供具有前瞻性的支持信息，保持对于当前最新的数据库新闻和事件的了解，其中包括重要数据库产品发布、警报、更新、新版本、补丁等。

本期目录：

• 新闻：2019年9月数据库流行度排行：MySQL 强劲增长
• 新闻：Oracle 20c数据库性能一览
• 频发：浅谈ITL事务槽
• 经验：Library Cache Lock之异常分析
• 经验：Oracle在HPUX IA64平台登陆缓慢问题分析
• 问题：Resize datafile偶遇enq: TX - index contention
• 问题：数据库性能“杀手”之标量子查询
• 警示：ORA-00600 15711 错误和GV$ 视图查询 OGG 的集成故障
• 公告：墨天轮征文令，我的DBA之路

抢先下载：https://www.modb.pro/doc/855（复制链接浏览器中打开，或者点击“阅读原文”）

往期技术通讯下载链接：https://www.modb.pro/doc/topic/5927（复制链接浏览器中打开，即可查看）

部分精选-经验：Library Cache Lock之异常分析-怀晓明 宋志强

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操作，必须经过严格的审核，避免产生类似问题。

出处：https://www.modb.pro/doc/855，（复制到网页中打开或者点击“阅读原文”）