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

kelsoncong

刚刚处理了一个 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中数据源的密码，但是在设置密码的时候出现了错误，导致不正确的密码被保存进了中间件的数据源。

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

digdeep126

645930266

顶

myles521

54xw

demonat

mark下

wsuhenry

感谢分享

XKGLOB刀

11g,这个等待事件是: row cache lock (dc_user上的)

guoyJoe

太师傅威武

nb2sfc

可以 理解 为 HAND住了  就可能有  等待事件发生 是吧