又是一个11g新特性导致的问题。 这个新特性很早之前就研究过，也在其他客户处碰到过类似的问题。从11g开始，如果一个用户使用不正确的密码尝试登录数据库，那么随着登录失败次数的增加，每次登录验证前延迟等待的时间也会增加： SQL SET TIME ON:30:54 SQL :

又是一个11g新特性导致的问题。
这个新特性很早之前就研究过，也在其他客户处碰到过类似的问题。从11g开始，如果一个用户使用不正确的密码尝试登录数据库，那么随着登录失败次数的增加，每次登录验证前延迟等待的时间也会增加：

SQL> SET TIME ON
:30:54 SQL> 
:30:58 SQL> conn test/test
Connected.
:31:25 SQL> 
: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 are no longer connected TO ORACLE.
:31:26 SQL> ERROR:
ORA-01017: invalid username/password; logon denied
:31:26 SQL> ERROR:
ORA-01017: invalid username/password; logon denied
:31:26 SQL> ERROR:
ORA-01017: invalid username/password; logon denied
:31:27 SQL> ERROR:
ORA-01017: invalid username/password; logon denied
:31:29 SQL> ERROR:
ORA-01017: invalid username/password; logon denied
:31:32 SQL> ERROR:
ORA-01017: invalid username/password; logon denied
:31:36 SQL> Connected.
:31:36 SQL> ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected TO ORACLE.
:31:36 SQL>

可以看到，从第三次密码错误的登录开始，每次延迟时间开始变成2秒、3秒并一次递增。既是这时提供正确的密码登录，会话也会延迟N秒，然后进行验证。不过一旦验证成功，会将失败计数清零，后续的错误登录会重新计数。
不过这只是单一会话尝试失败登录的情况，如果同时存在两个会话，则很快延迟验证时间就会达到10秒、20秒的级别。如果同时大量的连接采用错误的密码，基本上这个用户的登录就会被完全HANG住。
客户的数据库就出现了类似的情况，数据库版本为11.2.0.3 RAC，在数据库中观察，三个节点每个节点的会话数都接近SESSIONS参数设置的上线3000，而后台高级日志已经出现了ORA-20错误。由于客户系统的关键用户只有一个，因此几乎所有的会话都无法正常的登录到数据库中。而在数据库上发现，大量的会话用户名、EVENT以及PROGRAM都信息都是NULL，这说明这些会话还没有完成验证成功的登录到数据库中。而当前主机的CPU资源使用并不高，那些已经连接到数据库中的进程也可以正常的工作。尝试使用SYSTEM等其他用户发现可以迅速的登录数据库。所有这一切都已经说明，当前有一个或多个中间件服务器在使用错误的密码连接数据库，由于密码延迟验证的策略，导致所有后续的连接都被HANG住。
任何一个新特性带来性能或功能上的提高的同时，也会引入相关的bug，显然这个安全性上的考虑，有时候也会带来验证的性能问题，甚至成为用来攻击数据库的一种手段。
之前几次并没有给出彻底屏蔽密码延迟验证的手段，而Oracle最强大之处就在于几乎所有的功能和特性都有对应的开关，通过设置EVENTS 28401可以屏蔽密码延迟验证：

SQL> ALTER SYSTEM SET EVENT = ‘28401 TRACE NAME CONTEXT FOREVER, LEVEL 1’ SCOPE = SPFILE；

设置该事件后重启数据库即可。

原文地址：密码延迟验证导致的系统HANG住, 感谢原作者分享。