Failed Logon Delay排Top 2说明存在大量登录失败，本质是连接池密码未同步导致ORA-01017频发；需查DBA_HIST_RESOURCE_LIMIT中processes的MAX_UTILIZATION是否持续超90%，结合监听日志与统一审计定位失败IP和账号。
Failed Logon Delay排进Top 2，基本可以断定是连接池在反复重试失败登录，而不是连接数本身暴增。
查DBA_HIST_RESOURCE_LIMIT确认是否真连不上
AWR报告不直接展示连接数趋势，DBA_HIST_RESOURCE_LIMIT才是唯一能回溯历史连接峰值的视图。重点不是看当前v$resource_limit，而是查过去几小时里processes和sessions的MAX_UTILIZATION是否连续突破90%：
- 用
MAX_UTILIZATION而非CURRENT_UTILIZATION——后者只是快照结束瞬间的瞬时值，毫无参考价值 - 如果
LIMIT_VALUE为0或NULL，说明该资源未设限，需立刻检查processes参数是否被动态改过 - 多个快照连续高占比，说明是持续堆积，不是毛刺；若只有一两个快照突起，大概率是中间件在重试登录
盯住Failed Logon Delay等待事件本身
这个等待事件在19c里默认不启用，一旦出现在AWR Top 2，说明FAILED_LOGON_DELAY已被显式设置（比如设为3秒），且失败登录已成规模。它不消耗CPU、不读盘，就是纯睡，但会把DB Time顶得很高：
- 一次失败登录≈1秒DB Time（默认值），1万次失败≈2.78小时DB Time
- 它不会触发
ORA-00020报错，应用层看到的是“连接超时”或“获取连接失败”，实际数据库进程数可能远未到上限 - 别急着把
FAILED_LOGON_DELAY调成0——这等于关掉安全阀，可能让暴力探测更猖獗
结合监听日志和统一审计定位源头
AWR只能告诉你“有多少次失败”，要确定“谁在连、为什么连错”，必须交叉验证：
- 查监听日志：
$ORACLE_HOME/network/log/listener.log，过滤TNS-01189或ORA-01017，看IP、时间、用户名是否集中 - 查统一审计：
SELECT * FROM unified_audit_trail WHERE event_name = 'LOGON' AND return_code = 1017，确认失败账号是否来自中间件配置的固定用户 - 如果发现大量相同IP+相同用户名的失败记录，基本锁定是中间件连接池密码未同步——比如应用升级后没更新数据库密码，池子启动时就疯狂重试
别漏掉DBA_PROFILES里的用户级限制
RAC或高并发场景下，连接池复用的会话容易撞上CONNECT_TIME或IDLE_TIME限制，被数据库主动KILL，现象就是连接池不断重建新连接：
- 执行
SELECT resource_name, limit FROM dba_profiles WHERE profile = (SELECT profile FROM dba_users WHERE username = 'YOUR_APP_USER') - 重点关注
CONNECT_TIME（单位分钟）——设成10意味着会话最多活10分钟，连接池长连接会频繁失效 - 修复不是简单调大，而是确认中间件是否启用了连接有效性校验（如
testOnBorrow），避免无效连接堆积
真正棘手的不是连接数涨了多少，而是失败登录背后那个没被同步的密码、那个被忽略的profile限制、或者监听器与中间件保活探测时间不匹配——这些细节藏在日志和配置里，不在AWR图表中。
