延迟密码验证特性引起的数据库HANG死及宕机

来源：这里教程网时间：2026-03-03 16:24:35 作者：

延迟密码验证特性特性简述

为了防止用户密码的暴力破解,从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 DisconnectImpact 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=’*’;