问题发生在一个用户上，使用这个用户登录需要等待很长时间，而使用其他的用户登录则不存在问题,查看等待事件发现:
SQL> set linesize 200
SQL> select sid,p1, P1RAW,p2,p3,event from v$session_wait where event like '%library cache%';
SID P1 P1RAW P2 P3 EVENT
---------- ---------- ---------------- ---------- ---------- ----------------------------------------------------------------
45 3999290432 00000000EE605440 3997366320 5177346 library cache lock
49 3999290432 00000000EE605440 3994244816 5177346 library cache lock
SQL> select sid, serial#,username, blocking_session, event
from v$session
where event like '%library cache%' 2 3
4 ;
SID SERIAL# USERNAME BLOCKING_SESSION EVENT
---------- ---------- ------------------------------ ---------------- ----------------------------------------------------------------
22 143 library cache lock
32 67 22 library cache lock
可以看到，所有出现library cache lock等待的会话用户名都是空。这些会话并不是Oracle后台进程，而是刚才提到的问题用户，
这同样说明当方式这个library cache lock等待时，会话还没有成功的登录到数据库中。
在11g中，Oracle的密码策略确实出现了一些改变，比如密码变成大小写敏感。这个问题很可能导致老的程序来连接数据库时出现密码错误的现象。此外，11g还新增了一个密码相关的特性——密码错误
延迟验证：当用户连续的输入错误的密码，Oracle所需要的密码验证时间会逐步增加，这可以有效的避免有人试图通过暴力方式来破解密码。关于11g新增密码错误延迟验证的详细内容，
那么当前的问题和这个密码延迟验证有关系吗，如果是密码延迟验证的问题，那么至少要多次重复输入错误的密码。不过从刚才的V$SESSION视图中可以看到，问题用户存在多个会话在登录数据库，如果
是程序连接数据库，且配置了错误的密码，那么基本上就可以确定问题了。
询问了相关程序人员，发现一个测试程序的密码确实配置错误，且这个程序目前仍然在后台不断的尝试连接数据库。
现在所有的疑问都解开了，用户程序已错误的密码不断登录，在加上11g的密码延迟验证，使得用户的验证等待时间不断加长。这也解释了为什么输入正确的密码登录后，这个现象曾短暂消失，因为用户
成功登录，密码延迟验证的时间归零。
找到问题的原因后，在客户的数据库上以其他的用户尝试模拟这个现象，测试发现，如果一个会话登录数据库，即使每次密码都不正确使得延迟验证时间不断变长，也不会引发library cache lock的等
待时间，但是只要该用户存在第二个登录会话，这时library cache lock会在两个会话同时出现，而且即使这个会话尝试使用正确的密码登录，在成功登录之前，也要等待library cache lock事件。
根据这个现象，个人推测Oracle为了实现延迟验证，必然需要在共享池中保存一个类似计数器的对象。这个计数器记录用户登录连续密码错误次数，从而确定延迟验证的等待时间。当用户成功登录，计
数器清零。如果是一个会话，那么只需要独占这个计数器就可以了，当存在两个以上的会话，且两个会话都试图修改计数器的内容，那么资源竞争就出现了，而体现在数据库中的等待事件就是library
cache lock。当然这只是个人的猜测而已，还没有看到Oracle官方对这种情况的说明。
