意思是这是11g里的一个新特性，密码延时认证功能，即如果一个用户使用不正确的密码尝试登录数据库，那么随着登录失败次数的增加，每次登录验证前延迟等待的时间也会增加，导致数据库出现过多的 library cachelock 等待事件。
在了解应用那边的情况后，确实是有用户一直在尝试登录操作，却一直登不上。
3.解决方法
为了应急处理，协调应用停止应用，设置28401事件后重启数据库进行业务验证，实时监控数据库，发现没有再产生 library cachelock 等待事件，业务恢复正常。
经过验证确实是属于11g 错误密码验证延时功能所导致。
4.密码延时验证功能实验
为了深入了解该延时认证特性，于是在自己的学习环境进行实验：
SQL> select *from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release11.2.0.4.0 - Production
CORE 11.2.0.4.0Production
TNS for Linux:Version 11.2.0.4.0 - Production
NLSRTL Version11.2.0.4.0 - Production
SQL> set timeon
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 denied
Warning: You areno longer connected to ORACLE.
18:31:26 SQL>ERROR:
ORA-01017:invalid username/password; logon denied
18:31:26 SQL>ERROR:
ORA-01017:invalid username/password; logon denied
18:31:26 SQL>ERROR:
ORA-01017:invalid username/password; logon denied
18:31:27 SQL>ERROR:
ORA-01017:invalid username/password; logon denied
18:31:29 SQL>ERROR:
ORA-01017:invalid username/password; logon denied
18:31:32 SQL>ERROR:
ORA-01017:invalid username/password; logon denied
18:31:36 SQL>Connected.
18:31:36 SQL>ERROR:
ORA-01017:invalid username/password; logon denied
Warning: You areno longer connected to ORACLE.
18:31:36 SQL>
可以看到，从第三次密码错误的登录开始，每次延迟时间开始变成2秒、3秒并依次递增。即使这时提供正确的密码登录，会话也会延迟N秒，然后进行验证。不过一旦验证成功，会将失败计数清零，后续的错误登录会重新计数。
不过这只是单一会话尝试失败登录的情况，如果同时存在两个会话，则很快延迟验证时间就会达到10秒、20秒的级别。如果同时大量的连接采用错误的密码，基本上这个用户的登录就会被完全HANG住。
5.引起 Library cache lock 等待事件的其他可能原因
library cachelock等待事件解释：
library cachelock(库高速缓存锁)等待事件与库高速缓存并发性有关。当会话尝试在库高速缓存中修改或检查给定对象时产生该事件。会话必须获取对象句柄的库高速缓存锁，以阻止其他会话同时访问它，或维持一段较长时间的依赖性，或在库高速缓存中给对象定位。
Library cachelock 有3种模式：
（1）Share(S): 当读取一个library cache object的时候获得
（2）Exclusive(X): 当创建/修改一个library cacheobject的时候获得
（3）Null(N)： 用来确保对象依赖性
比如一个进程想要编译某个视图，那么就会获得一个共享锁，如果我们要create/drop/alter某个对象，那么就会获得 Exclusive lock。Null 锁非常特殊，我们在任何可以执行的对象(cursor，function)上面都拥有 NULL 锁，我们可以随时打破这个 NULL 锁，当这个 NULL 锁被打破了,就表示这个对象被更改了，需要重新编译。
NULL锁主要的目的就是标记某个对象是否有效。比如一个SQL语句在解析的时候获得了NULL锁，如果这个SQL的对象一直在共享池中，那么这个NULL锁就会一直存在下去，当这个SQL语句所引用的表被修改之后，这个NULL锁就被打破了，因为修改这个SQL语句的时候会获得 Exclusive 锁，由于NULL锁被打破了，下次执行这个SQL的时候就需要重新编译（解析）。
MOS的文档[122793.1]给出了 library cachelock 等待事件常见的两种原因：
1）A DML operation that is hanging because the table which is accessedis currently undergoing changes (ALTER TABLE). This may take quite a long timedepending on the size of the table and the type of the modification (e.g. ALTERTABLE x MODIFY (col1 CHAR(200) on a table with thousands of records)
In this case, V$LOCK will show that thesession doing the 'ALTER TABLE' with an exclusive DML enqueue lock on the tableobject (LMODE=6, TYPE=TM where ID1 is the OBJECT_ID of the table). The waitingsession however does not show up in V$LOCK. So in an environment with a lot ofconcurrent sessions, the V$LOCK information will be insufficient to track downthe culprit blocking your operation.
解释：某个表正在被修改的情况下，另一个DML操作需要访问这个表会HANG住，HANG的时间需要根据这个表的大小或修改类型来决定。
2）The compilation ofpackage will hang on Library Cache Lock and Library Cache Pin if any users areexecuting a procedure/function defined in the same package.
解释：即当有用户正在执行包里的一个存储过程或函数的同时，其他用户对该包对象进行了编译操作，此时会产生该等待事件。
而在本次案例的故障中，由于查询v$session视图的结果里username列大多都是空的，可以排除以上两种产生 library cachelock 的原因。
6.总结
密码延时验证功能作为11g的一个新特性，任何一个新特性带来性能或功能上的提高的同时，也会引入相关的bug，显然这个安全性上的考虑，有时候也会带来验证的性能问题，甚至成为用来攻击数据库的一种手段。而Oracle最强大之处就在于几乎所有的功能和特性都有对应的开关，通过设置EVENTS 28401可以屏蔽密码延迟验证功能：
SQL> ALTERSYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE；
设置该事件后重启数据库即可生效。
作者: 郑全 时间: 2017-4-24 21:36
附从审计日志中查询最近7天口令错误无法登陆的记录:
select username, os_username, userhost, substr(comment_text,instr(comment_text,'HOST=')+5, 13), trunc(timestamp), count(*) failed_logins
from dba_audit_trail
where returncode = 1017
and timestamp > sysdate - 7
group by username, os_username, userhost, substr(comment_text,instr(comment_text,'HOST=')+5, 13), trunc(timestamp);
| 欢迎光临 重庆思庄Oracle、Redhat认证学习论坛 (http://bbs.cqsztech.com/) | Powered by Discuz! X3.2 |