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