一次处理大量library cache lock等待

上周5个库出现大量library cache lock等待，现象为：

1、每个库均出现400多个libaray cache lock等待事件。

2、前台业务未出现性能问题，业务系统登录正常。

3、各数据库性能未出现明显下降，主机性能未出现明显下降，CPU,IO内存均正常。

4、system用户登录异常，出现登录时断时续的现象。

library cache lock以前在9I时经常遇到，通常出现该等待事件表现为CPU明显增高，系统响应缓慢等。出现该等待通常原因为高解析或高并发环境下进行编译，这次现象根据现象来看很奇怪。经检查各系统硬解析都不高，查看v$shared_pool_reserved视图也未发现明显异常。

检查KGLLK：

select kgllkhdl ,kgllkreq , kglnaobj 

from x$kgllk where kgllkses in

( select saddr from gv$session where event= 'library cache lock')

and kgllkreq > 0;

kgllkhdl kgllkreq kglnaobj 

-------- ---------- ------------------------------------------------------------

00RE80TEAZJR          2   5

没看明白5是个什么对象？？在数据字典里也查不到5，晕死。

select kgllkses ,kgllkhdl ,kgllkmod ,kglnaobj 

from x$kgllk lock_a

where kgllkmod > 0

and exists (select lock_b.kgllkhdl from x$kgllk lock_b

where kgllkses  in

( select saddr from gv$session where event= 'library cache lock')

and lock_a.kgllkhdl = lock_b.kgllkhdl

and kgllkreq > 0);

检查持有和阻塞也发现所有的OBJECT都是5，没明白，看来只有从SESSION入手来看看有没共通点了，检查阻塞会话游标SQL，居然全是安全集成商部署的登陆检查TRRIGER SQL，又从阻塞和请求的SESSION检查，居然发现所有进程均为system用户使用JDBC连接。业务系统居然用SYSTEM用户做JDBC连接。

顺带做了一个systemstat:

sqlplus / nolog

conn /as sysdba

oradebug setmypid

oradebug unlimit

oradebug dump systemstate 266

检查trace文件waiting for 'library cache lock'，发现所有被阻塞和阻塞的会话均来自同一台windows主机发起的连接。与查看kgllk和session表中的结果一致。

通知网络和硬件相关人员，发现该主机为上线前部署的一台监控主机发起的JDBC连接，关闭该主机杀掉相关进程，系统正常。

后再MOS上搜索，发现一篇文档，记录了在11.2.0.2以后，如果并发大量会话使用错误密码登陆，将造成library cache lock等待。

不过后续比较奇怪的是SYSTEM密码前几天已经改掉，居然还有SYSTEM使用JDBC连入数据库建立连接，看来系统的安全管理还需要加强！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23371754/viewspace-756879/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23371754/viewspace-756879/