应看Transactions per Second与Logical reads per Second突增点，因DB Time是累计值，无法区分夜间批处理与在线业务洪峰；真洪峰需四指标同步抬升且同比变化率显著。
直接看 Load Profile 里每秒事务数（Transactions per Second）和每秒逻辑读（Logical reads per Second）的突增点，不是看 DB Time 总量
为什么不能只看 DB Time 或 DB CPU 总量
DB Time 是累计值，会把低频高耗时 SQL 和高频轻量操作混在一起。比如一个报表 SQL 单次跑 45 分钟，它拉高 DB Time，但不代表业务系统在“洪峰”——它可能是夜间批处理。真正反映在线业务洪峰的是单位时间内的工作密度。
常见错误现象：DB Time 高但 Transactions per Second 不高 → 实际是后台任务或单一大查询，非业务洪峰；DB CPU 累计 3600 秒，但 AAS（Average Active Sessions）仅 1.2 → 并发极低，只是某条 SQL 慢，不是负载集中爆发。
- 必须交叉验证：洪峰一定伴随
Transactions per Second、Executions per Second、Logons per Second三者同步抬升 - 若
Logons per Second突增而Transactions per Second没跟上 → 可能是连接池泄漏或应用重连风暴，不是真实业务请求上涨 - AWR 快照间隔默认 60 分钟，会平滑掉 5–10 分钟级洪峰；生产环境建议调为 15 分钟，否则根本捕不到尖峰
Load Profile 中哪些指标组合才算“真洪峰”
单独看任一指标都不可靠。要盯住它们的同比变化率（相比前一快照或基线周期），而非绝对值。
-
Transactions per Second较前一快照 +80% 以上，且Executions per Second同步 +70% → 典型业务请求量激增 -
Logical reads per Second+120%，但Physical reads per Second仅 +15% → 缓存效率尚可，负载上升由业务驱动，非 IO 瓶颈引发 -
Redo size per Second突增 +200%，同时Commit per Transaction接近 1 → 大量短事务提交，可能对应秒杀、抢购类场景 - 反例：
Logical reads per Second+90%，但Buffer nowait %从 99.98% 降到 92.3% → 缓存已开始争用，此时洪峰已开始冲击系统稳定性
如何排除“伪洪峰”干扰
有些指标飙升是统计假象或非业务因素导致，需快速过滤。
-
Parse count (hard) per Second> 100 → 不是业务洪峰，是硬解析失控。检查sql_text是否含大量字面量（如WHERE order_id = 12345），而非绑定变量 -
Physical reads direct per Second显著上升 +300%，而db file scattered readAvg Wait (ms) -
SQL*Net more data to client进了 Top 5 → 客户端取数慢，服务端早已执行完，不是数据库侧洪峰 - RAC 环境下
Logons per Second仅节点 1 暴涨 → 检查 TNS 配置是否漏设LOAD_BALANCE=on，属接入层不均，非整体负载升高
结合 ASH 定位洪峰发生的具体分钟级窗口
AWR 报告只能告诉你“这一小时发生了什么”，但洪峰常集中在某几分钟。必须用 ASH 补位。
执行以下语句定位精确时间点（替换 begin_time 为 AWR 快照起始时间）：
SELECT TRUNC(sample_time,'MI') minute_window,
COUNT(*) active_sessions
FROM v$active_session_history
WHERE sample_time BETWEEN &begin_time AND &begin_time + 1/24
GROUP BY TRUNC(sample_time,'MI')
ORDER BY active_sessions DESC
FETCH FIRST 5 ROWS ONLY;
关键点：
- 结果中
minute_window对应的分钟如果active_sessions>CPU_COUNT× 1.2，才是真实并发洪峰 - 若该分钟内
event高度集中于db file sequential read或log file sync，说明洪峰已触发资源瓶颈，不只是请求多 - 别依赖 AWR 的 “Top SQL” 页面——它按累计耗时排序，会淹没掉那些在洪峰分钟内高频执行、单次仅耗 200ms 的 SQL；要用 ASH 查
sql_id在该分钟内的执行次数和平均等待
洪峰识别最易被忽略的一点：它从来不是孤立指标，而是 Transactions per Second、Executions per Second、Logons per Second、Redo size per Second 四条曲线同步拐头向上的那个交点。少看一条，就可能把一次备份任务误判成双十一流量洪峰。
