oracle library cache lock,刚刚处理了一个library cache lock的问题

刚刚处理了一个 library cache lock 的问题,给大家分享下, 以便兄弟们遇到类似的问题多一个解决思路.

数据库版本11GR2, OS Oracle Linux

故障描述， 用某个用户登录，一直hang住，不报错

具体情况，接到反馈说，某个页面不能打开，检查了下该页面的日志，发现该页面对应的某个帐户A不能登录数据库。

于是直接尝试用sqlplus连接数据库，发现连接hang在那里。

检查等待事件，发现是 library cache lock

并且发现，除了我们的登录进程，还有一大堆的已经登录的进程被阻塞在library cache lock.

立刻做了一个4分钟的statspack(没装EM，只能用statspack) ， 发现如下异常

Time Model System Stats  DB/Inst: xxxxx/xxxxx  Snaps: 1-2

-> Ordered by % of DB time desc, Statistic name

Statistic                                       Time (s) % DB time

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

connection management call elapsed             384,100.8     100.0

DB CPU                                              30.1        .0

sql execute elapsed time                            16.7        .0

PL/SQL execution elapsed time                        4.5        .0

parse time elapsed                                   1.2        .0

Avg          %Total

%Tim Total Wait   wait    Waits   Call

Event                               Waits  out   Time (s)   (ms)     /txn   Time

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

library cache lock                    250    0    384,116 ######      0.0   99.9

library cache: mutex X             19,736    0        162      8      3.3     .0

log file sync                         518    0         11     21      0.1     .0

db file sequential read                44    0          1     32      0.0     .0

write complete waits                   47    0          1     16      0.0     .0

和之前的现象一样，大量library cache lock导致登陆hang住，时间全部消耗在了 connection management call elapsed

看看下面的top sql 没发现特别的发现。

通过查询x$kgllk等相关表，发现持有锁的对象名是1488， 查了查dba_object表，没找到这个名字开头的对象， 进程也是来自一个weblogic 的模块，没什么特别的， 所以一时没了头绪。

后来查了下metalink, 发现一篇文章 LIBRARY CACHE LOCKS DUE TO INVALID LOGINATTEMPTS [ID 1309738.1].

这个是Oracle的一个bug, 用户多次尝试登陆失败会产生library cache lock, 这个很好的解释了我的问题。 下面的问题就简单了，找到产生library cache lock的源头(可以参照文档How to Find whichSession is Holding a Particular Library Cache Lock [ID 122793.1])

来源于weblogic的某个模块， 检查了该模块对应管理服务器的日志，果然发现了某个数据源多次连接失败的记录。

打开该数据源的配置，发现对应的帐户果然是存在问题的那个帐户。

询问了下管理员，他们是昨天晚上修改了DB帐户的密码，同时也修改了weblogic中数据源的密码，但是在设置密码的时候出现了错误，导致不正确的密码被保存进了中间件的数据源。

找到问题以后，解决就简单了，重新配置下这个数据源的密码，然后重启相关的管理服务器。之后又检查了下，一切都正常了。