11.2数据库登录出现library cache lock等待(一)

客户的11.2.0.2 RAC for Linux X86-64环境的数据库在登录时,发现出现长时间等待。
这一篇描述问题的现象的诊断。
出问题的时候我正好在客户现场,于是当时诊断了一下。
客户反映,问题发生在一个用户上,使用这个用户登录需要等待很长时间,而使用其他的用户登录则不存在问题。
首先检查了DBA_PROFILES,确认和密码以及登录有关的PROFILE是否存在限制,当前数据库已经都设置为UNLIMITED,那么问题应该和PROFILE无关。
检查出现问题的用户,也未发现任何特别之处。
在sqlplus上使用这个用户登录,经历了将近10秒左右的等待,终于成功登录。同时检查到会话当时出现library cache lock等待事件。
当再次尝试重现问题时,却已发现问题无法重现了,现在即使使用刚才的问题用户,也可以很快登录成功,并不会出现明显的登录等待。莫非一次成功的登录,就可以解决这个问题。
不过很快,问题再次出现,为了检查会话执行的具体操作,对这个问题用户创建了一个登录触发器,在登录触发器中设置会话的TRACE:

SQL> CREATE OR REPLACE TRIGGER T_AFTER_LOGON AFTER LOGON ON DATABASE
2 BEGIN
3 IF USER = 'GJT' THEN
4 DBMS_SESSION.SESSION_TRACE_ENABLE(TRUE, TRUE);
5 END IF;
6 END;
7 /
TRIGGER created.

虽然问题重现了,但是找到会话的TRACE信息,却没有发现任何异常之处,甚至在TRACE信息中都找不到任何library cache lock等待事件的信息。
而且此时还发现一个现象,就是利用这个用户登录时,即使用户名的密码输入错误,sqlplus也会等待很长时间,然后才会返回错误信息。而这个长时间的等待从V$SESSION视图中查询,恰恰就是library cache lock等待事件。
上面的两个现象说明,library cache lock的等待实际上是发生在用户登录之前的。其实从数据库V$SESSION视图中也可以看出这个问题:

SQL> SELECT sid, username, event, p1text, p1, p2text, p2, p3text, p3, seconds_in_wait
  2  FROM gv$session
  3  WHERE event = 'library cache lock';
        SID USERNAME                       EVENT              SECONDS_IN_WAIT 
----------- ------------------------------ ------------------ --------------- 
         19                                library cache LOCK              21
       2017                                library cache LOCK              20
       2062                                library cache LOCK               0
       2147                                library cache LOCK              10
       2210                                library cache LOCK              21

可以看到,所有出现library cache lock等待的会话用户名都是空。这些会话并不是Oracle后台进程,而是刚才提到的问题用户,这同样说明当方式这个library cache lock等待时,会话还没有成功的登录到数据库中。
那么现在问题有点棘手,如果会话没有登录,则没有办法检查会话执行了哪些操作,Oracle的文档中也没有提到过,会话登录之前会进行哪些操作,经历哪些等待。
分析一下这个问题,整个数据库目前只有这个用户出现了library cache lock的等待,而其他用户没有出现,说明问题肯定和这个用户的自身特点有关。而数据库中只存在默认的DEFAULT PROFILE,且所有限制都设置为UNLIMITED,那么问题应该和PROFILE没有关系。通过登录触发器设置TRACE后发现,会话登录后并无任何异常操作,且TRACE文件中看不到library cache lock等待信息。而且即使用户名密码错误,也会出现这个等待事件。这说明等待发生在登录之前,与用户登录后的行为无关。
简单总结一下,问题和当前用户的自身特性有关,且与DBA_PROFILE无关,也与用户登录后的行为无关。如果不考虑PROFILE,那么用户特有的属性恐怕就剩下了用户名和密码了。而且在一次成功的登录数据库后,这个现象曾短时间消失,这说明问题可能确实和密码有关系。
在11g中,Oracle的密码策略确实出现了一些改变,比如密码变成大小写敏感。这个问题很可能导致老的程序来连接数据库时出现密码错误的现象。此外,11g还新增了一个密码相关的特性——密码错误延迟验证:当用户连续的输入错误的密码,Oracle所需要的密码验证时间会逐步增加,这可以有效的避免有人试图通过暴力方式来破解密码。关于11g新增密码错误延迟验证的详细内容,可以参考:http://yangtingkun.itpub.net/post/468/505041
那么当前的问题和这个密码延迟验证有关系吗,如果是密码延迟验证的问题,那么至少要多次重复输入错误的密码。不过从刚才的V$SESSION视图中可以看到,问题用户存在多个会话在登录数据库,如果是程序连接数据库,且配置了错误的密码,那么基本上就可以确定问题了。
询问了相关程序人员,发现一个测试程序的密码确实配置错误,且这个程序目前仍然在后台不断的尝试连接数据库。
现在所有的疑问都解开了,用户程序已错误的密码不断登录,在加上11g的密码延迟验证,使得用户的验证等待时间不断加长。这也解释了为什么输入正确的密码登录后,这个现象曾短暂消失,因为用户成功登录,密码延迟验证的时间归零。
找到问题的原因后,在客户的数据库上以其他的用户尝试模拟这个现象,测试发现,如果一个会话登录数据库,即使每次密码都不正确使得延迟验证时间不断变长,也不会引发library cache lock的等待时间,但是只要该用户存在第二个登录会话,这时library cache lock会在两个会话同时出现,而且即使这个会话尝试使用正确的密码登录,在成功登录之前,也要等待library cache lock事件。
根据这个现象,个人推测Oracle为了实现延迟验证,必然需要在共享池中保存一个类似计数器的对象。这个计数器记录用户登录连续密码错误次数,从而确定延迟验证的等待时间。当用户成功登录,计数器清零。如果是一个会话,那么只需要独占这个计数器就可以了,当存在两个以上的会话,且两个会话都试图修改计数器的内容,那么资源竞争就出现了,而体现在数据库中的等待事件就是library cache lock。当然这只是个人的猜测而已,还没有看到Oracle官方对这种情况的说明。

This entry was posted in ORACLE and tagged , , . Bookmark the permalink.

2 Responses to 11.2数据库登录出现library cache lock等待(一)

  1. Pingback: 11.2数据库登录出现library cache lock等待(二) | yangtingkun

  2. qiaowei says:

    上周末遇到这个问题,看您的文章找出原因,您太棒了。

Leave a Reply

Your email address will not be published. Required fields are marked *