AWR快照无法反映秒级性能尖刺，根本原因在于其默认60分钟周期性聚合采样机制，仅保存离散时间点的累计统计值，无法捕获两次快照间毫秒级突发活动；定位此类问题必须依赖v$active_session_history视图的秒级真实采样。
AWR快照无法反映秒级性能尖刺，根本原因在于它的采样机制是聚合式、周期性的，而非连续实时捕获——它只记录每小时（默认）一个时间点的累计统计值，而尖刺往往发生在两次快照之间、持续几秒甚至毫秒。
AWR快照的时间粒度天生不适合抓尖刺
AWR默认每60分钟生成一次快照，每个快照保存的是该小时内所有会话活动的聚合统计（如总DB Time、总逻辑读、平均等待时间）。哪怕某条SQL在14:22:17–14:22:22这5秒内CPU打满、逻辑读飙升10倍，它也会被摊平到整个60分钟窗口里，最终只表现为“Elapsed Time Per Exec +0.08ms”这种无感波动。
-
dba_hist_snapshot中的end_interval_time是离散时间点，不是连续流 - 快照间无数据插值：两个快照之间发生的一切，AWR不存、不推、不猜
- 即使把快照间隔调到5分钟（
MODIFY_SNAPSHOT_SETTINGS），仍可能错过23秒的尖刺——尤其当它恰好跨在两个快照中间时
v$active_session_history 才是秒级尖刺的唯一证据源
真正能定位“14:22:19卡住那1秒”的，只有内存中每秒采样的 v$active_session_history（或 RAC 下的 gv$active_session_history）。它不是聚合值，而是真实拍下的会话状态快照：
- 每一行对应一个会话在某一秒的状态：
session_state（ON CPU或WAITING）、event（如db file sequential read）、sql_id、blocking_session - 连续3个样本落在同一
sql_id+enq: TX - row lock contention，就是锁争用尖刺的铁证 - 必须加时间过滤：
SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE，否则内存已刷出、查不到
为什么AWR报告里的“ASH Data”链接也不可靠
AWR报告末尾常带“ASH Data”超链接，但它只是对 v$active_session_history 的二次聚合——按分钟分组、去重、截断，丢失了原始秒级精度：
- 点击后看到的是“14:22–14:23 分钟内共 17 次
log file sync等待”，但不知道是均匀分布还是集中在 14:22:44–14:22:49 这6秒 - 无法关联
blocking_session或sql_plan_hash_value，也就没法判断是否为执行计划跳变引发的连锁卡顿 - 若问题发生在快照生成前1分钟，而该分钟内ASH样本被老化清理，链接直接返回空结果
真要抓尖刺，必须绕过AWR报告直查视图
别等 awrrpt.sql 输出HTML，也别信报告里的摘要链接。定位秒级尖刺只有一条路径：
- 先确认问题发生时间（应用日志、监控告警、用户反馈），精确到分钟级
- 立即查
v$active_session_history：SELECT TO_CHAR(sample_time, 'HH24:MI:SS'), event, sql_id, session_state FROM v$active_session_history WHERE sample_time BETWEEN TIMESTAMP '2026-09-17 14:22:00' AND TIMESTAMP '2026-09-17 14:22:30' ORDER BY sample_time - 重点看
session_state = 'ON CPU'且sql_id高频出现的区间，或event集中爆发的连续样本 - 若
sql_id为空，转向program和module，排查 PL/SQL 匿名块或递归调用
复杂点在于：ASH内存只保留约1小时（高负载下更短），且样本是否写入受 _ash_sampling_frequency 隐含参数影响——这意味着你得在尖刺发生后尽快动手，晚了就真的没了。
