Author Archives: yangtingkun

客户的11.2.0.2 RAC for Linux X86-64环境的数据库在登录时，发现出现长时间等待。 这一篇描述现象重现过程。 11.2数据库登录出现library cache lock等待（一）：https://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 →

客户的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 →