11gR2_After Modify Passwd Normal User Conn Hang Solution-优快云博客

本文详细记录了在更新数据库应用账号密码后遇到的librarycachelock等待事件问题，通过检查v$session和v$session_wait视图，发现等待主要集中在librarycachelock上。经过进一步分析，确认为非数据库后台进程导致的问题。通过屏蔽密码验证延迟功能，重启数据库后问题得到解决。最终验证新密码并成功登录，librarycachelock等待事件消失。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

晚上陪着应用室同事弄数据库应用账号的口令加固工作，心想应该没什么大问题，一边等他们一边看电视，突然电话过来问题就出现了。
应用帐号批量修改密码后，若干应用帐号用新密码连接数据库无反应hang住不动，随即查看等待事件：

select event,count(event) from v$session group by event;

SQL> select event,count(*) from v$session_wait group by event;

EVENT COUNT(*)

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

SQL*Net message from client 12

ASM background timer 1

wait for unread message on broadcast channel 2

ges remote message 1

gcs remote message 4

pmon timer 1

row cache lock 25

rdbms ipc message 30

smon timer 1

library cache lock 202

Streams AQ: qmn slave idle wait 1

EVENT COUNT(*)

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

Space Manager: slave idle wait 2

GCR sleep 1

SQL*Net message to client 1

VKTM Logical Idle Wait 1

Streams AQ: qmn coordinator idle wait 1

Streams AQ: waiting for time management or cleanup tasks 1

DIAG idle wait 2

PING 1

VKRM Idle 1

20 rows selected.

发现等待积累在 library cache lock上面，继续查看：
select SQL_ID,SCHEMANAME from v$session where event='library cache lock';
发现，sqlid为空，并且除了sys用户外用户显示也是空的。断定为非数据库后台进程，由此说这些会话还没有连接到数据库，一直在等待验证状态。
此外，
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU                                           43,632         122.0
library cache lock                  541,513       1,747      3    4.9 Concurrenc
log file sync                       564,778         652      1    1.8 Commit
DFS lock handle                   1,017,685         290      0     .8 Other
latch free                           73,425         208      3     .6 Other
从上面的报告，也正好体现了问题的焦点是 library cache lock。

至此问题可有两种思路：
1 做hang分析进一步定位根源；
2 进一步去探测性X$视图： X$KGLLK

我这里迫于应用的压力直接找到mos文档： Library Cache Locks Due to Invalid Login Attempts (文档 ID 1309738.1)的solution： 把密码验证延迟功能（11g新特性 ） 进行屏蔽后重启库恢复正常：

Database opened.

SQL> SQL> SQL> SQL> alter system set events '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1';

System altered.

处理后修改新密码和登陆正常：

SQL> alter user pisap identified by xxxxx ; -----处理前就会hang住

User altered.

SQL> conn pisap/xxxx ;-----处理前就会hang住

Connected.

再看 library cache lock 等待也消失：

EVENT COUNT(EVENT)

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

SQL*Net message from client 10