Tag Archives: library cache lock

密码延迟验证导致的系统HANG住

又是一个11g新特性导致的问题。 这个新特性很早之前就研究过,也在其他客户处碰到过类似的问题。从11g开始,如果一个用户使用不正确的密码尝试登录数据库,那么随着登录失败次数的增加,每次登录验证前延迟等待的时间也会增加: SQL> SET TIME ON 18:30:54 SQL> 18:30:58 SQL> conn test/test Connected. 18:31:25 SQL> 18:31:25 SQL> conn test/a conn test/a conn test/a conn test/a conn test/a conn test/a conn test/a conn test/test conn test/a ERROR: ORA-01017: invalid username/password; logon … Continue reading

Posted in ORACLE | Tagged , , , , | Leave a comment

统计信息收集出现DFS等待导致实例HANG死

客户10.2.0.4 RAC环境,出现大量的library cache lock和cursor: pin S wait on X等待,经分析是由于统计信息收集僵死导致的。 数据库在8点到9点期间,数据库两个节点都存在明显的cursor: pin S wait on X和library cache lock的等待: Event Waits Time(s) Avg   Wait(ms) %   Total Call Time Wait   Class cursor:   pin S wait on X 1,573,056 30,651 … Continue reading

Posted in BUG | Tagged , , , , | Leave a comment

9iRAC环境遭遇library cache lock和library cache load lock等待

客户数据库版本为9208 RAC FOR AIX,客户反应系统缓慢,检查告警日志,发现大量Library cache lock和Library cache load lock等待。 由于客户的原因,这个问题只是远程协助的方式帮忙检查了一下,因此没有留下任何的操作记录,这里只是简单描述一下问题。 客户反应数据库操作响应变慢,平时一个执行很快的基于主键的UPDATE操作也变得异常缓慢,且执行计划本身并未发生改变。 登录数据库后检查两个节点上的告警日志,并未发现任何异常报错。分别检查两个实例的等待信息,发现除了上面提到的大量Library cache lock和Library cache load lock以外,还有明显的gc等待。 但是随后发现,查询V$SESSION和GV$SESSION的结果居然没有区别,接着查询GV$INSTANCE视图,发现只有当前的实例存在,而此时恰好连接另一个节点的工具出现了断连,以至于我一度以为另外一个节点上的实例已经DOWN掉,但是随后重新登录到该节点上,发现数据库实例仍然存在,而且登录到数据库实例中也可以进行任何正常的操作。不过发现在当前节点所有的GV$视图都只会返回当前实例的信息,这与另外一个节点的情况完全一样。显然两个节点间的通信出现了问题,当前节点已经不清楚另外一个节点的状态的。 现在再去分析那些等待信息已经没有太多的意义了,因为整个数据库已经处于不正常的状态。不难推断,当前数据库的异常是由于节点间的通信异常导致。由于9i使用的操作系统的CLUSTER,还没有Oracle的clusterware,剩下只能由操作系统或硬件维护人员去进一步跟踪了。 最终数据库和系统在夜间闲时进行了重启操作,重启后数据库恢复正常,GV$视图的结果也恢复了正常。

Posted in ORACLE | Tagged , , , , , | Leave a comment

ORA-600(17087)错误

客户数据库出现这个ORA-600错误。 错误信息为: Mon Jun 28 10:27:07 2010 Errors IN file /oracle/admin/ccicdb/udump/ccicdb_ora_767494.trc: ORA-00600: internal error code, arguments: [17087], [0x70000076C3E8E90], [], [], [], [], [], [] 检查MOS发现,这是10.2.0.3上和CURSOR有关的bug,详情可参考文档Bug 7706062 – OERI [17087] following concurrent hard parses on same cursor [ID 7706062.8]。 当存在大量并发同一个cursor的硬解析存在时,可能会导致library cache … Continue reading

Posted in BUG | Tagged , , , | Leave a comment

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

客户的11.2.0.2 RAC for Linux X86-64环境的数据库在登录时,发现出现长时间等待。 这一篇描述现象重现过程。 11.2数据库登录出现library cache lock等待(一):http://yangtingkun.net/?p=279 上一篇描述了客户的11.2.0.2 RAC for Linux X86-64环境出现library cache lock的问题,同事回来后想要模拟这个现象,在Windows环境下的11.2.0.1上却没有模拟出来,我也在Windows上的11.2.0.1上尝试了一下,结果没有出现library cache lock等待,但是出现了row cache lock等待事件。 测试步骤很简单,开启三个sqlplus,其中一个设置SET TIME ON,获取时间信息,并不断的已错误的用户名密码尝试连接数据库。另一个会话以正确的用户名和密码连接到数据库,设置SQLPROMPT为SQL2>,以便于和第一个会话区别。最后一个会话以SYS登录数据库,检查会话的等待状态: SQL> SET TIME ON 08:34:41 SQL> CONN TEST/A@192.25.1.100/TEST112 ERROR: ORA-01017: 用户名/口令无效; 登录被拒绝   08:34:42 SQL> CONN TEST/A@192.25.1.100/TEST112 … Continue reading

Posted in ORACLE | Tagged , , | Leave a comment

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 … Continue reading

Posted in ORACLE | Tagged , , | 2 Comments