今天开发领导要求将两个测试数据库服务器的IP地址互换，也就是不动应用代码切换数据库，而两个数据库的密码是不一样的，在IP切换完成后，修改用户密码时夯住。此时就知道是由于11g的这个新特性导致的，11g号称防止暴力破解密码而推出的这个新功能，还不如说是个BUG，竟然在连续密码错误后会遇到全局的等待事件library cache lock，从而导致数据库基本瘫痪。

SQL> select username,event from v$session where username ='SYS';

USERNAME                       EVENT
------------------------------ ------------------------------
SYS                            library cache lock
SYS                            SQL*Net message from client
SYS                            cursor: pin S wait on X
SYS                            row cache lock
SYS                            row cache lock

以上，有3个会话在修改密码，有一个是在DROP DIRECTOTY操作，还有一个，就是在执行这个查询操作，查询错误密码登录情况，这个数据库开着审计，可以直接查询AUD$数据字典得到。

USERID                         USERHOST                                 TO_CHAR(A.   COUNT(*)
------------------------------ ---------------------------------------- ---------- ----------
MIGSP                          CL010A-3482                              2016-05-09          5
CHGSHS                         SL010A-prodservices.sit.com              2016-05-09         28
CHGSHS                         localhost.localdomain                    2016-05-09          1
CHGSHS                         WORKGROUP\USER-20151130TX                2016-05-09          1
CHGSHS                         SL010A-noif.uat.com                      2016-05-09          1
CHGSHS                         LD010A-2720                              2016-05-09          1
MIGSP                          WorkGroup\Sc-201511121444                2016-05-09          3
CHGSHS                         SL010A-IVADT4                            2016-05-09          3
CHGSHS                         CD010A-2182                              2016-05-09          1
CHGSHS                         WORKGROUP\WIN-FF3EAU9O1L5                2016-05-09          3
CHGSHS                         SL010A-iOrder.test.com                   2016-05-09          5
CHGSHS                         SL010A-iGoods.test.com                   2016-05-09         31
CHGSHS                         HUIMAI\CL010A-2946                       2016-05-09          1
PRODTASK                       SL010A-ipartner.test.com                 2016-05-09         22
CHGSHS                         SL010A-iSwSYS.test.com                   2016-05-09          7

15 rows selected.

因为这个数据库在切换前没人使用，所有我直接按天做的分组，可见，密码错误次数已经很高了。根据经验，一般连续40次错误密码登录，数据库基本就会瘫痪了。

可以通过28401事件来禁用这个新特性来解决这个问题，但是坑爹的是这是个静态参数，需要重启数据库才能生效。

SQL>  ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER' SCOPE=SPFILE;

System altered.

关闭监听后，问题没有及时解决，数据库依然瘫痪，由于是刚切换IP的测试数据库，测试人员还没有正式使用，只是应用程序自动的连接导致的这个问题，果断ABORT的方式关闭数据库。

alter user VOUCHER identified by xxxxxxxx account unlock
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 33916
Session ID: 195 Serial number: 1

先不要启动监听，重启数据库，修改密码后，再启动监听，否则又一堆错误密码的连接过来了，在没有使用28401事件屏蔽这个功能时，数据库又要瘫痪。由于修改面操作非正常停止，在ABORT的方式关闭数据库的时候，遇到了03113错误。

在重启数据库后，由于监听没有启动，不会有使用错误密码的连接进来，很快就修改了密码，之后启动监听，将数据库注册到监听器，问题解决。

本文固定链接: https://www.dbdream.com.cn/2016/05/11g%e6%96%b0%e7%89%b9%e6%80%a7%e5%af%86%e7%a0%81%e9%94%99%e8%af%af%e5%bb%b6%e8%bf%9f%e4%b8%a5%e9%87%8d%e5%af%bc%e8%87%b4%e6%95%b0%e6%8d%ae%e5%ba%93%e5%a4%af%e4%bd%8f/ | 信春哥，系统稳，闭眼上线不回滚！