重启大法失效？详述Oracle11g因JDBC bug引发异常Library Cache Lock等待处理事件

墨墨导读：在Oracle 11g 版本中可能出现由于JDBC bug导致sql绑定变量无法共享，过期游标过多的情况，此时如果发生大量并发业务，很有可能造成异常library cache lock等待事件，造成数据库突发性能问题。在此，我们分享一次由jdbc bug和绑定变量长度问题共同“作案”引发数据库性能故障的案例。

本文节选自《云和恩墨技术通讯》（12月刊）
下载链接：https://www.modb.pro/doc/1593（点击阅读原文或者扫描下方二维码即可下载）

library cache lock等待事件是Oracle数据库较为常见的等待事件之一，在之前的几次月刊中，我们也提到过产生library cache lock等待出现的原因有很多，如登录密码错误尝试过多、热表收集统计信息和SQL解析失败等。

在Oracle 11g 版本中可能出现由于JDBC bug导致sql绑定变量无法共享，过期游标过多的情况，此时如果发生大量并发业务，很有可能造成异常library cache lock等待事件，造成数据库突发性能问题。在此，我们分享一次由jdbc bug和绑定变量长度问题共同“作案”引发数据库性能故障的案例，供各位参考。

问题描述

---

2019年10月11号晚22:00分左右，运维人员对生产系统数据库进行清理历史分区操作，执行近100个分区删除操作后（22:05左右）发现该数据库压力飙升，维护人员紧急停止历史分区清理操作，发现大量业务数据插入（INSERT）缓慢。

查看故障期间数据库发现大量library cache lock等待，数据库活动会话飙升至1000以上，数据库响应非常缓慢，业务受到严重影响。

问题分析

---

从故障期间ASH的整体运行情况看：

从22:00开始，数据库的活动会话飙升，每秒活动会话飙升至1000以上。故障时间段内的TOP EVENT主要表现在library cache lock和library cache: mutex X等待上。

查看故障期间数据库活动会话情况：

从10:00:08的ash信息来看，多个library cache lock被4276会话阻塞，4276会话被4374会话 “cursor : mutex S”阻塞，同时4374会话被8168“library cache lock”阻塞。从ash分析来看，大量的library cache lock会话的p3值都是5373954和5373955。5373954指的是mode=2，5373955的mode=3，只是持有的方式不同mode=3就是exclusive独占锁。

而4276会话library cache lock的p3值是5373955，对应的namespace HEX:52 —>DEC:82，mode=3。

SQL AREA BUILD说明library cache lock是在SQL解析上或SQL AREA上的问题。
发生等待是会话都是在执行g14zxrn7wyaxh  INSERT SQL语句：

/** PayOrderMapper.insert */
INSERT INTO TxxxxxxT T
  (T.ID,……T.SxxxO)
VALUES
  (SEQ_xxx.nextval,
   :1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,:20,:21,:22,:23,:24,:25,:26,:27,:28,:29,:30,:31,:32,:33,:34,:35,:36,:37,:38,:39,:40,:41,:42,:43,:44,:45,:46,SYSDATE,:47,SYSDATE,:48,: