AWR报告本身不直接展示连接数趋势，DBA_HIST_RESOURCE_LIMIT才是记录历史连接使用峰值的唯一来源，它存储每个快照点上processes和sessions的实际使用值、最大值及限制值；需通过比对相邻快照的MAX_UTILIZATION定位飙升时间点，并关联ASH与SQL统计进一步分析根因。
AWR里查不到连接数暴增？先确认你查的是哪个视图
AWR报告本身不直接展示连接数趋势，DBA_HIST_RESOURCE_LIMIT才是记录历史连接使用峰值的唯一来源。很多人翻遍AWR报告的“Report Summary”和“Instance Activity Stats”，却漏掉这个表——它存的是每个快照点上processes和sessions的实际使用值、最大值、限制值。
常见错误是只查v$resource_limit（当前实时值），但问题往往发生在几小时前，必须回溯历史快照。
-
RESOURCE_NAME = 'processes'对应操作系统进程上限，'sessions'是会话上限，二者都得看 - 查之前先确认快照保留期：
SELECT retention FROM dba_hist_wr_control，默认8天，超时数据已自动清理 - 别用
DBA_HIST_SNAPSHOT里的end_interval_time直接拼时间条件——快照ID才是准的，时间字段有四舍五入误差
怎么写SQL定位连接数飙升的时间点和峰值
核心是比对相邻快照的MAX_UTILIZATION，不是看当前值。下面这条SQL能快速找出过去24小时内processes使用率突破90%的所有快照：
SELECT s.snap_id, TO_CHAR(s.begin_interval_time, 'yyyy-mm-dd hh24:mi') AS snap_time, a.CURRENT_UTILIZATION, a.MAX_UTILIZATION, a.LIMIT_VALUE, ROUND(a.MAX_UTILIZATION / a.LIMIT_VALUE * 100, 1) AS pct_used FROM DBA_HIST_RESOURCE_LIMIT a JOIN dba_hist_snapshot s ON a.snap_id = s.snap_id AND a.dbid = s.dbid WHERE a.resource_name = 'processes' AND s.begin_interval_time > SYSDATE - 1 AND a.MAX_UTILIZATION > 0.9 * a.LIMIT_VALUE ORDER BY s.snap_id;
注意几个关键点：
- 用
MAX_UTILIZATION而非CURRENT_UTILIZATION，后者只是快照结束瞬间的瞬时值，没参考价值 - 如果
LIMIT_VALUE为0或NULL，说明该资源未设限（极少见），需排查参数是否被动态修改过 - 结果里如果多个快照连续出现高占比，说明不是毛刺，而是持续性连接堆积
查到峰值后，下一步必须关联ASH和SQL统计
知道“什么时候连不上”还不够，得知道“谁在连、为什么连不完”。AWR里SQL Statistics → SQL ordered by Executions页能暴露高频短连接：比如单个SQL每秒执行上百次，但每次只跑几十毫秒——这往往是应用层没复用连接，反复建连/断连。
更直接的办法是查v$active_session_history（ASH）在峰值快照区间内的活跃会话分布：
SELECT sql_id, COUNT(*) AS sample_count, program, module, action FROM v$active_session_history WHERE sample_time BETWEEN (SELECT begin_interval_time FROM dba_hist_snapshot WHERE snap_id = &peak_snap_id) AND (SELECT end_interval_time FROM dba_hist_snapshot WHERE snap_id = &peak_snap_id) GROUP BY sql_id, program, module, action ORDER BY sample_count DESC;
重点关注：
-
program列显示客户端类型（如jdbc thin client或oracle@host），能区分是应用还是运维脚本引发 - 如果大量会话
sql_id为空且event为client connection或SQL*Net message from client，基本坐实是连接未释放 - 配合
module和action字段，可定位到具体业务模块或代码路径
别忽略序列CACHE值过小这个隐蔽杀手
连接暴增有时根本不是连接池问题，而是SQL卡在序列获取上，导致应用层不断重试建连。AWR里Top 5 Timed Events若出现大量enq: SQ - contention，就是典型信号。
检查方式很简单：
- 查当前序列CACHE值：
SELECT sequence_name, cache_size FROM dba_sequences WHERE sequence_name IN ('SEQ_A', 'SEQ_B'); - 对比AWR中
SQL ordered by Gets里涉及这些序列的INSERT语句，看逻辑读是否异常高（说明频繁访问序列缓存块） - 19c+环境下，还可查
DBA_HIST_SEG_STAT里sequence$基表的logical_reads增量，确认是否真在拖慢
一个cache=20的序列，在高并发插入场景下，每20次INSERT就要一次序列号申请+全局锁争用，很容易把连接卡住——这种问题不会出现在连接池配置里，但会让连接数在几分钟内翻倍。
