查v$active_session_history必须加动态时间窗口，因ash内存仅保留约1小时且高负载下更短；应使用sample_time > sysdate - interval '5' minute，避免写死时间字符串导致漏样；rac环境须用gv$active_session_history以覆盖全实例。
查 v$active_session_history 时必须加动态时间窗口
ash 内存只保留约 1 小时，且高负载下可能更短。写死时间字符串（如 '2026-06-22 14:00:00'）极易因时区、nls 设置或采样非连续性漏掉关键样本。
- 正确做法是用
SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE—— 精确覆盖最近 5 分钟，不受会话时区影响 - 别用
BETWEEN包死区间：采样点落在边界外（比如问题发生在14:02:59.8，而你查14:02:00–14:03:00），但采样只在 .0/.1/.2 秒发生，就可能错过 - RAC 环境必须用
gv$active_session_history，否则只看到当前节点的样本，卡顿若发生在 node2，你在 node1 上查不到
区分“真执行慢”和“假性耗时长”
ASH 中某条 sql_id 出现大量 sample_time 间隔长的记录，不等于它单次执行花了几十秒——更可能是被阻塞、解析卡住或 PL/SQL 循环调用。
- 看
session_state和event组合：session_state = 'ON CPU'且event为空 → 真正在跑；session_state = 'WAITING'且event = 'enq: TX - row lock contention'→ 实际卡在锁上 - 查
v$sql验证：elapsed_time / executions平均值若只有几毫秒，但 ASH 里一堆 30s+ 样本，基本可排除真实执行慢，转向查阻塞链或硬解析 -
sql_id相同但child_number不同，可能对应完全不同的执行计划；别只聚合sql_id，漏掉子游标差异
定位波动根源：计划变更 or 数据倾斜？
执行时间突增，90% 情况不是 SQL 本身变慢，而是优化器选了劣质计划，或绑定变量值触发了数据倾斜。
- 用
dbms_xplan.display_cursor('xxx', null, 'outline +peeked_binds')查当前内存中计划，重点看是否走了全表扫描、连接方式是否合理、分区裁剪是否生效 - 用
dbms_xplan.display_awr('xxx')对比历史计划，确认plan_hash_value是否变化；若变了，再查dba_tab_statistics看相关表统计信息是否过期 - 如果计划没变、统计信息也新，但某次执行突然巨慢，立刻检查绑定变量值：
where status = :b1，:b1 = 'Z'返回 500 万行，而优化器按平均值估算只选了 nested loop
SQL_TEXT 为空时怎么还原上下文？
v$active_session_history 只存 sql_id，不存文本。查 v$sql 返回空，大概率是该 SQL 已老化出共享池。
- 优先查
DBA_HIST_SQLTEXT：它从 AWR 快照里捞历史文本，只要该 SQL 曾进过 AWR，就有机会恢复 - 若仍为空，用
sql_plan_hash_value关联DBA_HIST_SQL_PLAN，至少能还原执行计划结构，判断是否走错索引或连接顺序 - 别忽略
sql_opname字段：比如sql_opname = 'CREATE'但event = 'library cache lock'，说明不是 SQL 执行慢，而是 DDL 卡住导致后续查询排队
真实问题往往藏在 sql_id 相同但 child_number 或 plan_hash_value 不同的细微差别里，还有就是 RAC 下跨节点采样遗漏——这些点不手动验证，光看汇总结果很容易归错因。
