【背景】今天中午的时候用户反馈需要修改数据库的和应用的连接密码，修改密码这种小事情，本以为不会不会出现问题的。没想到午休
【背景】今天中午的时候用户反馈需要修改数据库的和应用的连接密码，修改密码这种小事情，本以为不会不会出现问题的。没想到午休到一半的时候就接到用户的电话，系统连接不进去了。
【环境】
操作系统 linux6.3_64 数据库版本11.2.0.3【症状】用户修改密码之后通过应用连接一直连接不上，我登录主机通过sqlplus连接的时候，也是一直处于hang住状态，但是sys、system用户进行连接的时候速度就很快；
[oracle@ekpdbtest ~]$ sqlplus / as sysdba  (数据库可以正常登录） 
sql*plus: release 11.2.0.1.0 production on fri apr 10 17:37:42 2015 
copyright (c) 1982, 2009, oracle.  all rights reserved. 
connected to:
oracle database 11g enterprise edition release 11.2.0.1.0 - 64bit production
with the partitioning, olap, data mining and real application testing options 
sql>     
sql> conn sale/oracle （hang住了）
【备注】操作系统的cpu、内存、网络、磁盘空间都没有发现异常；
1、查看等待事件
通过查看awr报告，library cache lock等待严重
                                                          wait  % db         
event                                waits    time(s)  (ms)  time wait class
------------------------------ ------------ ----------- ------ ------ ----------
library cache lock                      866    145,056 2.e+05  92.0 concurrenc
row cache lock                          195      9,155  46948    5.8 concurrenc
2、恢复用户到修改前的密码
sql> conn sale/sale  （可以登录）
【问题原因】经过一番查找发现该问题属于oracle 11的一个新特性，如果一个用户使用不正确的密码尝试登录数据库，那么随着登录失败次数的增加，每次登录验证前延迟等待的时间也会增加。这个特性主要用于避免一些程序采用错误的密码进行尝试性的登录；所有这一切都已经说明，当前有一个或多个中间件服务器在使用错误的密码连接数据库，由于密码延迟验数据证的策略，导致所有后续的连接都被hang住。
用户的环境是怎么触发这个特性的了？
用户的环境中，连接数据库不仅有应用层，还有一些【地磅系统】，这些系统直接连接数据库，所以虽然更改了应用的密码，但是地磅系统由于数量众多且修改麻烦，，所以应用的连接密码修改后，地磅系统的连接密码并没有改，所以一直在用错误的密码进行登录，而触发了【密码延迟验证导致的系统hang住】
【解决方法】这个性特性可以提供系统的安全性，但同时也引入了bug，oracle最强大之处就在于几乎所有的功能和特性都有对应的开关，通过设置events 28401可以屏蔽密码延迟验证，重启数据库后解决。
sql> alter system set event = ‘28401 trace name context forever, level 1’ scope = spfile;
【总结】暂时性的关闭这个特性，然后再逐步修改每个系统的密码，又化解了一次危机；
本文永久更新链接地址：