记一次，oracle修改密码后性能变差的经历-GBlog

由于现场环境oracle密码设置比较简单，所以近期修改了一次密码。

修改后，几天内是好好的，但是有个服务突然挂掉了（其他服务好好的），发现是用户被锁，查了下原因，医院有一个监控平台，没有修改oracle的新密码，不断地使用错误密码尝试连接导致了oracle的账户被锁。ORA-28000 the account is locked 。

使用下面的sql查看，那些错误密码连接的日志。里面能看到主机名和连接配置文件（里面有ip）。

SELECT T.OS_USERNAME,
       T.USERHOST,
       T.TIMESTAMP,
       T.ACTION_NAME,
       T.COMMENT_TEXT
  FROM DBA_AUDIT_TRAIL T
  -- USERNAME是被锁定的用户名
 WHERE T.USERNAME = 'USERNAME'
   -- LOGON表示登录操作
   AND T.ACTION_NAME = 'LOGON'
   -- 1017表示用户名/密码无效
   AND T.RETURNCODE = '1017'
 ORDER BY T.TIMESTAMP DESC;

先保证这个服务先启动把，使用解锁命令，解除oracle的锁定 alter user scott account unlock;

但是服务还没起来的时候，账号就被锁了。为了先启动服务，再联系监控平台解决密码问题，于是通过下面的命令修改了，oracle的默认错误密码校验次数 ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 1000; 然后保证服务的正常启动了。但是后面医院反馈系统非常慢，根据日志查看了，系统产生大量慢sql。根据addm和awr性能分析报告说是未知问题占用了性能。

感觉和监控平台的使用错误密码有关系，果然监控平台的厂家还没联系上，还是10秒一次使用错误密码进行连接。恢复默认错误密码次数后，系统瞬间变快了，于是查了下这个问题。
恢复默认密码错误次数的sql ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 10;

另外建议

11G的bug有点多，如果有条件请升级。上次有个业务量比较大的医院，出现游标错误，导致整个oracle卡死。
oracle默认配置，尽量不要修改，鬼知道触发什么奇怪的bug。

找到了一篇文章给读者们参考下，感觉说的很有道理，文章地址 https://www.yisu.com/jc/263871.html

文章原文

从Oracle 11.1开始，错误的用户名密码登录可能会导致在数据库层面看到显著的“row cache lock”等待。
很多用户认为这是一个bug，而实际上这是一个数据库保护机制。
Oracle的sqlplus工具会在3次错误密码输入后自动断开连接，但是外部应用程序却可以编码，不断调用登录API进行密码尝试。所以如果没有一个数据库层面的安全控制，这将是非常危险的。
从Oracle 11.1开始，数据库会在对同一个用户3次错误的密码尝试之后，开始锁定这个用户3秒钟，才允许下一次登录。这个锁定时间将从3秒逐渐延长，不断增加。
所有以该用户登录的session都会等待“row cache lock”，哪怕他是用正确的密码登录的。

很多用户不理解这样做是为了帮助用户避免风险，而对看到的“row cache lock”等待提出抱怨。
所以Oracle在Bug 7715339的修复中提供了一个方法（event 28401）来绕过这段代码，来供用户做不同选择。
event="28401 trace name context forever, level 1" # disable logon delay
必须说明的是，这实际上并不是一个bug，而是一个功能增强。用户必须清楚如果设置了这个事件，将使您的数据库暴露在密码猜测的风险之下。

Bug 7715339的修复被包含在11.2.0.1 PSU之中。而在11.1.0.7上打补丁7715339，默认已经相当于打开event 28401了。
在11.2.0.2之后，Oracle修改代码，将这一段“row cache lock”等待修改成了“library cache lock”等待。
总结一下：
1)11.1.0.X上，错误的用户名密码登录，将导致显著的“row cache lock”等待。
用户可以在11.1.0.7上打补丁7715339，不用设置event 28401，就可绕过这段安全控制代码。
2)11.2.0.1上，错误的用户名密码登录，将导致显著的“row cache lock”等待。
用户不用打补丁（因为已经包含在11.2.0.1中了），直接设置event 28401，就可绕过这段安全控制代码。
3)11.2.0.2以上的版本（包含11.2.0.2），错误的用户名密码登录，将导致显著的“library cache lock”等待。
用户不用打补丁（因为已经包含在11.2.0.1中了），直接设置event 28401，就可绕过这段安全控制代码。

必须再次说明的是，用户必须清楚如果打补丁或者设置了这个事件，将使您的数据库暴露在密码猜测的风险之下。

正题：
有用户反馈，即使设置了event 28401，仍会观察到错误的用户名密码登录导致“library cache lock”等待，这是为什么呢？为此，我们做了以下测试进行说明：

起10个进程，同时进行错误的用户名密码登录，并测试未设置event 28401和设置event 28401进行比较，从V$SYSTEM_EVENT中多次观察获取平均等待时间：
select total_waits,Time_waited_fg/total_waits
from V$SYSTEM_EVENT
where event='library cache lock'

未设置event 28401：
91   1395.252747252747252747252747252747252747
98   2352.959183673469387755102040816326530612
106   2687.698113207547169811320754716981132075
116   3495.862068965517241379310344827586206897

<========library cache lock的平均等待时间很快从13.95秒逐渐增加到34.95秒，并且持续增加。

设置event 28401之后：
23142   2.97325209575663296171463140610146054792
24329   3.03592420568046364421061284886349623906

<========即使在24329次等待之后，library cache lock的平均等待时间仍然稳定在0.03秒。

也就是说，event 28401是生效的，“等待时间从3秒逐渐增加的”的安全机制被绕过了，但是“library cache lock”却无法避免。
这是因为，错误的用户名密码登录仍会在数据库内部更新该用户的登录次数，错误登录次数，上次登录时间等信息，需要申请“library cache lock”。
而“library cache lock”的等待时间跟并发登录的进程数和数据库性能有关。
如果有多个用户进行不断的进行错误的密码尝试，可能仍会观察到较高的“library cache lock”等待。
因为“错误的密码尝试”应用程序的代码逻辑一般都是非常疯狂的，正确的登录可能一次就过了，而一旦错误会反复尝试并且没有sleep等待，这将导致一秒钟可能会发起几百次上千次的尝试，
而多个进程并发时就容易观察到平均等待几十毫秒甚至几百毫秒的“library cache lock”了。因为会不断尝试，在数据库层面会累积而很容易观察到。
但是设置event 28401之后，一般不会有几十秒上百秒的单次等待了，因为单次递增的等待机制被绕过了。

总体来讲，数据库管理员应该尽快发现并解决错误的用户名密码登录问题（它们一般是因为数据库密码被更改而应用程序没有及时同步造成的），而不应该过度依赖event 28401。
因为无论从哪个角度来看，错误的用户名密码登录都是一个应用层面的异常问题，是应该被避免的。

目录CONTENT

记一次，oracle修改密码后性能变差的经历

评论区