查不到数据主因是awr快照未覆盖目标时段，需先确认snap_id范围及statistics_level为typical/all，时间条件须用显式timestamp字面量，rac环境必须用dba_hist_active_sess_history。
查不到数据？先确认 awr 快照是否覆盖目标时段
直接查 dba_hist_active_sess_history 却返回 0 行，大概率不是 sql 写错，而是底层根本没归档。该视图依赖 awr 快照触发归档——每 10 秒采一次样，但只有在 awr 快照生成时，内存中的 ash 数据才会批量刷入磁盘。
实操建议：
- 运行
SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot WHERE end_interval_time BETWEEN TIMESTAMP '2026-05-14 02:00:00' AND TIMESTAMP '2026-05-14 03:00:00';，确认目标小时是否有快照 - 若无结果，说明该时段未生成 AWR 快照（比如数据库刚启动、
statistics_level是BASIC、或手动禁用了快照） - 检查参数：
SELECT name, value FROM v$parameter WHERE name = 'statistics_level';—— 必须为TYPICAL或ALL
时间条件必须用 TIMESTAMP 字面量，别信 SYSDATE - X
想查昨晚 2:17–2:22 的锁等待，写 SAMPLE_TIME BETWEEN SYSDATE - 1/24 AND SYSDATE - 1/24 + 5/1440 会出错：凌晨时段 SYSDATE 是当天上午，减 1 小时就跨到前一天，且计算精度受 NLS 设置干扰。
正确做法是显式指定带时区的 TIMESTAMP：
WHERE sample_time BETWEEN TIMESTAMP '2026-05-14 02:17:00' AND TIMESTAMP '2026-05-14 02:22:00'- 注意：
dba_hist_active_sess_history.sample_time是TIMESTAMP类型，不是DATE，不能用TO_DATE()强转 - 若不确定时区，加
AT TIME ZONE 'UTC'对齐（尤其跨地域 RAC 环境）
RAC 环境必须用 DBA_HIST_ACTIVE_SESS_HISTORY，不能用 GV$
gv$active_session_history 是实时内存视图，只存约 1 小时；而 dba_hist_active_sess_history 是磁盘历史表，已聚合所有实例数据。RAC 下若误用 v$ 或 gv$ 查历史，必然漏掉其他节点的样本。
关键点：
-
dba_hist_active_sess_history的dbid和instance_number字段可区分来源实例 - 查询时加
AND instance_number = 2可聚焦某节点，但默认应保留全实例数据用于阻塞链还原 - 不要试图用
UNION ALL拼多个gv$视图替代——历史归档逻辑与实时采样不同步，数据不等价
CPU 消耗量不能直接 COUNT(*)，得看占比和执行时长
看到某 sql_id 在 dba_hist_active_sess_history 中出现 200 次，就认定它是 CPU 根因？危险。该表采样粒度是 10 秒（v$active_session_history 是 1 秒），且只记录“活动”样本（session_state = 'ON CPU' 或 'WAITING'），不反映空闲或已结束会话。
更靠谱的判断方式：
- 过滤
session_state = 'ON CPU'，再算COUNT(*) / (SELECT COUNT(*) FROM dba_hist_active_sess_history WHERE ...)—— 看 CPU 样本占总活动样本比例 - 结合
sql_exec_start和sample_time差值：若差值稳定在 5–10 秒，说明 SQL 执行慢且未完成；若差值从 1 秒跳到 8 秒再跳到 15 秒，极可能是客户端超时后重试 - 避免单独依赖
event字段：比如SQL*Net message from client持续 60 秒，大概率是应用层已断连，服务端会话还在等下一条指令
真实场景中，最易被忽略的是采样稀疏性与快照依赖的耦合：你查的“历史”其实只是 AWR 快照的副产品，不是原始 ASH 的完整镜像。一旦快照缺失，那段窗口就彻底不可见——没有补救办法，只能靠当时是否启用了统一审计（unified_audit_trail）或应用层日志兜底。
