上周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/