awr报告虽不直接显示连接池配置，但可通过processes资源利用率长期超85%、logon等待事件突增、connection idle高占比及ash中会话生命周期过短等现象，精准诊断连接池配置过小或缺失。
AWR报告本身不直接暴露连接池配置大小，但能清晰暴露连接池“撑不住”的后果——只要看到 processes 资源持续逼近上限、logon 等待事件突增、或大量会话卡在 connection idle 状态，基本可以断定应用层连接池配小了，或者根本没用连接池。
查 processes 资源利用率是否长期超 85%
Oracle 的 processes 参数是硬性上限，所有前台会话（包括应用连上来的每个连接）都算在内。AWR 报告里不叫“连接池”，但它记录了这个资源的真实压力：
- 在 AWR 的 “Resource Limit” 部分，找
resource_name = 'processes' - 重点看
MAX_UTILIZATION，不是CURRENT_UTILIZATION——后者只是快照结束那一刻的瞬时值，毫无意义 - 如果连续多个快照的
MAX_UTILIZATION / LIMIT_VALUE> 0.85，且LIMIT_VALUE不为 0 或 NULL，说明连接数已长期吃紧 - 配合
DBA_HIST_RESOURCE_LIMIT视图手动查更准：运行SELECT snap_id, MAX_UTILIZATION, LIMIT_VALUE FROM DBA_HIST_RESOURCE_LIMIT WHERE resource_name = 'processes' AND snap_id IN (SELECT snap_id FROM dba_hist_snapshot WHERE begin_interval_time > SYSDATE - 1)
盯 logon 和 connection idle 等待事件是否异常升高
连接池过小最典型的副作用，就是应用频繁新建连接、又快速释放，导致登录/登出动作成为瓶颈：
- 在 AWR 的 “Top 10 Foreground Events by Total Wait Time” 中，如果
logon出现在前五，尤其是占比超过 5%，必须警惕 - 同一页若同时出现高占比的
connection idle，说明大量连接建好后没被复用，很快空闲超时断开——这是连接池 minSize 设得太低或回收策略过激的信号 - 注意区分：纯
log file sync或db file sequential read高是 I/O 问题；而logon+connection idle组合高，大概率是连接管理问题
对比 ASH 中会话生命周期是否短于连接池 idle timeout
AWR 报告只给汇总数据，要确认是不是“建了就扔”，得下钻到 ASH（活动会话历史）：
- 执行
SELECT sql_id, COUNT(*) cnt FROM v$active_session_history WHERE event = 'logon' AND sample_time > SYSDATE - 1/24 GROUP BY sql_id ORDER BY cnt DESC，看是否有大量重复的匿名登录 SQL - 查典型会话的存活时间：
SELECT session_id, MIN(sample_time), MAX(sample_time), COUNT(*) FROM v$active_session_history WHERE session_id IN (SELECT session_id FROM v$session WHERE username IS NOT NULL) GROUP BY session_id HAVING COUNT(*) —— 若大量会话只活了 1~2 个采样点（即几秒），说明连接刚建就丢，池子没兜住 - 这个现象和应用端配置的
idleTimeout（如 UCP 的setInactiveConnectionTimeout）直接相关；若数据库侧观察到会话平均存活远低于该值，说明池子实际没生效
为什么不能只看应用日志或监控里的“连接数”？
很多团队在应用监控里看到“连接池使用率 30%”，就认为没问题。但这是错觉：
- 应用监控统计的是“池内当前分配出去的连接数”，而 Oracle 看的是“所有已建立、尚未关闭的 OS 进程数”——中间差了一个网络层、一个防火墙、甚至一个代理
- 连接池配置了
maxPoolSize=20，但应用有 5 个实例，每个都配了 20，实际可能打上来 100 个连接，而processes只设了 150，看似还有余量，实则一到高峰就卡死 - Oracle 19c 的
v$session中program列常显示jdbc thin client，无法区分是同一个池还是多个池；唯一可靠锚点是processes指标和等待事件模式
真正难的不是发现“连接池小”，而是确认“小在哪里”：是应用侧 max size 没调够？是没启用连接池直接裸连？还是连接泄漏导致池子被占满？AWR 提供的是客观证据链，但每条证据都要交叉验证，不能单看一个数字就下结论。
