需求：

oracle数据库密码过期了，需要修改密码，数据库是RAC环境，同时连接数据库的有多套环境。

事件过程：

停了其中一个环境后（其他环境忘记停了）直接修改某用户数据库密码，第一次修改成功，过了十几分钟后发现用新的用户密码通过PLSQL连接数据库时会卡住，用sqlplus连接也会卡住，用DBA用户二次修改某用户数据库密码，同样会卡住，一直提示excuting。下面是报错截图：

解决思路：

1、初步以为用户给锁定了，但是alter user XX account unlock也会锁住，对其他用户操作没有影响,用该用户连接数据库也会hang住，但是其他用户不受影响

2、从网上资料了解到很有可能是由于11g的密码错误延时验证，造成library cache lock。

一开始检查可以看到，处于library cache lock都是JDBC的应用，sql id是空（即还没有开始跑sql）。

检查ash，发现应用唯一的一个sql id是b84cknyvnyq25，是update user$ 表。这就很容易让人联系起来登陆时用户的验证。

11g有个密码错误延时验证，当应用以错误的密码连接上来时，会持续不断的循环CPU，同时伴随library cache lock。

所以我这里设置event 28401来禁用这个特性。

具体的修改过程：

SQL>show parameter event 
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
event string
xml_db_events string enable
SQL>alter system set event='28401 trace name context forever,level 1' scope=spfile;
System altered.

-----问题来了，需要重启才能生效，但是我们的数据库是集中式数据库，不能重启！

3、查看该用户的session，发现有48个会话数，通过里面一个字段（记录了服务器hostname）发现有其他环境连接了数据库服务器，后来才想起外网也有一套环境应用还是用老的密码在连这个数据库，将外网环境停止，释放连接后过段时间用正确的账号密码可以连接，会话数也是释放了。

此时再启动应用也可以正常访问。

总结：

虽然之前一直知道oracle有这个特性，但还是疏忽大意了，上面是今天在处理事故的一个过程，希望对大家有点帮助。

在修改数据库密码的时候提前查看是不是有其他会话正在用这个账号密码连接数据库，确定没有其他session再做修改密码的操作会更安全。

后面会分享更多关于DBA内容，感兴趣的朋友可以关注下~