问题描述
某客户生产系统核心数据库在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=:1 7hzh3urqxjz6n的sql文本为： select a.*,b.yyyyyy from 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操作，必须经过严格的审核，避免产生类似问题。
相关推荐：《云和恩墨技术通讯》 集锦
