延迟密码验证特性 特性简述
为了防止用户密码的暴力破解,从11G开始引入了一个新特性：密码延迟认证。
等待用户输入密码的时间，随着输入错误密码的次数而不断延长。以此缓解暴力破解Oracle用户密码。
特性潜在引发问题
- 修改用户密码引发大量Library Cache Lock 数据库密码应该是定时修改，以提高数据库安全性，防止黑客攻击。但是, 大部署大量程序的业务 系统里，难免会有遗漏的情况。在修改完密码后，数据库会出现大量的Library Cache Lock等待事件。在MOS 上有说明：High 'library cache lock' Wait Time Due to Invalid Login Attempts(1309738.1)
- BUG 用户登录数据库，哪怕正常登录，每次登录的时间都在延长。
一 问题说明
10日17点左右得知某数据库出现数据库用户锁定的情况，登上去后发现一节点数据库hang死，二节点数据库宕机，进行处理排查后，业务正常运行，以下为排查过程。
二 故障具体日志分析
报告分析
我们取一节点故障点16 点到17 点以及9 日相同时间点的AWR 报告进行对比发现：
发现故障点dbtime 相比高了24 倍，其中top10 的等待事件中， library cache lock 达到了总dbtime 的75.5%
查看时间模型：
connection management call elapsed time 该统计信息达到了dbtime 的77%
报告分析
同样我们取故障点的addm 报告：
|
Activity During the Analysis Period ----------------------------------- Total database time was 499730 seconds. The average number of active sessions was 138.12. Summary of Findings ------------------- Description Active Sessions Recommendations Percent of Activity -------------------------------- ------------------- --------------- 1 Session Connect and Disconnect 106.79 | 77.32 1 2 Shared Pool Latches 104.22 | 75.45 0 3 Unusual "Cluster" Wait Event 11.32 | 8.2 2 4 Unusual "Concurrency" Wait Event 4.42 | 3.2 4 5 Buffer Busy - Hot Objects 4.18 | 3.03 0 6 Unusual "Cluster" Wait Event 2.83 | 2.05 2 |
可以看到在同一时间，排名第一 的 Session Connect and Disconnect
|
Finding 1: Session Connect and Disconnect Impact is 106.76 active sessions, 77.32% of total activity. ----------------------------------------------------------- Session connect and disconnect calls were consuming significant database time.
Recommendation 1: Application Analysis Estimated benefit is 106.79 active sessions, 77.32% of total activity. ---------------------------------------------------------------------- Action Investigate application logic for possible reduction of connect and disconnect calls. For example, you might use a connection pool scheme in the middle tier. |
报告给出的分析为：会话连接和断开连接调用消耗了大量的数据库时间。
故障时间ash 报告分析
我们取故障时间点16 点至17 点的ash 报告：
同样的，我们可以获取到跟awr 报告相同的等待时间及时间模型。
我们可以看到16:35 开始数据出现大量的library cache lock
我们获取到该等待事件的p1,p2,p3 值，分别代表该等待事件的句柄地址，锁地址，锁模式及命名空间。
我们将p3 的值十进制转换为16 进制获取到它的命名空间值为79 ，再在数据库中将其查出：
|
select distinct KGLHDNSP, KGLHDNSD from x$kglob where KGLHDNSP=79 ； KGLHDNSP KGLHDNSD ---------- ------ 79 ACCOUNT_STATUS
|
可以看到，该锁指向了账户状态，综上所述，结合之前应用反馈的用户锁问题，我们有理由认定此次故障是由于错误密码的大规模登录数据库，导致出现大量的library cache lock ，最终拖垮了数据库，导致数据库的hang 死。
三 故障总结
故障结论分析
结合第二章节的故障分析，结合之前应用反馈的用户锁问题，我们有理由认定此次故障是由于错误密码的大规模登录数据库，导致出现大量的library cache lock ，最终拖垮了数据库，导致数据库的hang 死，至于哪些应用导致的大规模错误密码登录，还得结合应用去排查。
解决方案
从上述3.1 节的分析，给出如下建议：
1. 密码策略优化
|
密码过期时间，从11g 开始，oracle 对数据库所有密码默认过期时间180 天： SQL> alter profile default limit PASSWORD_LIFE_TIME unlimited;
密码登陆错误次数，对于输入错误密码导致数据库账号被锁定： SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS unlimited; 或 修改为100 次 alter profile default limit FAILED_LOGIN_ATTEMPTS 100;
密码大小写敏感，该参数默认值是TRUE ，因此，默认情况下密码大小写是敏感的 SQL> alter system set SEC_CASE_SENSITIVE_LOGON=false;
密码错误延迟登录，11G 引入了延迟密码验证，在输入错误的密码后，后续如果还是采用错误的密码登陆，将会导致密码延迟验证，从第三次开始，后续的每次登陆导致密码延迟1 秒左右 而且会导致失败登陆延长，可以通过如下事件来屏蔽密码的延迟验证 SQL> ALTER SYSTEM SET event='28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE=SPFILE SID='*';
禁止OCI 程序登录风暴，初始化参数SEC_MAX_FAILED_LOGIN_ATTEMPTS 的默认设置为10 ，表示在连接尝试达到指定次数后会自动断开连接。即使未启用口令概要文件，也会强制实施此参数。 此参数可以防止程序连接到数据库，然后成百上千次地尝试口令以通过验证。如果认为该参数没有特别的必要性，可以考虑调大： alter system set sec_max_failed_login_attempts=2147483647 scope=spfile sid=’*’;
|
3. Sql 优化
|
Awr 报告发现数据库存在比较大的解析及硬解析，查看后发现比较多的sql 没有使用绑定变量 建议： 1. 优化sql ，使用绑定变量 2. 尽量使用索引 |
四 附录
官方文档： Doc ID 1309738.1
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69993859/viewspace-2752646/ ，如需转载，请注明出处，否则将追究法律责任。
