查不到刚发生的cpu高峰是因为ash是每秒约1次的概率采样、仅保留约1小时内存数据，且必须用动态时间条件、rac需用gv$、过滤session_state='on cpu'、按sql_id聚合计数才能准确定位。
查 v$active_session_history 时为什么总查不到刚发生的 CPU 高峰？
因为 v$active_session_history 是内存环形缓冲区，只保留最近约 1 小时数据，且采样是概率性（每秒约 1 次），不是全量连续捕获。你看到“查不到”，大概率是时间范围没卡准，或者样本已被滚动覆盖。
务必用动态时间条件：SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE，别写死字符串如 '2026-08-27 02:50:00'——系统时区或 NLS 设置稍有偏差就返回空结果。
- RAC 环境必须用
gv$active_session_history，否则只看到本节点数据 - 单实例查
v$active_session_history即可 - 若问题发生在 03:12:47，但你限定
SAMPLE_TIME BETWEEN '03:12:45' AND '03:12:49'，仍可能漏掉——采样点未必刚好落在该区间，建议放宽到 ±15 秒
只统计 SESSION_STATE = 'ON CPU' 的样本才准
ASH 记录的是会话状态快照，SESSION_STATE 字段才是判断是否真在消耗 CPU 的唯一依据。混入 'WAITING' 或 'UNKNOWN' 样本会导致结果失真，把等待事件误判为 CPU 问题。
常见错误是漏加 WHERE SESSION_STATE = 'ON CPU'，导致查出来一堆 enq: TX - row lock contention 或 db file sequential read 的记录，干扰真正高 CPU 的 SQL 识别。
- 必须加
AND SESSION_STATE = 'ON CPU'过滤，这是定位 CPU 问题的第一道门槛 - 大小写敏感：
'ON CPU'不能写成'on cpu'或'On Cpu' - 别用
v$session_event或v$system_event替代——它们反映的是累计等待，不是瞬时 CPU 占用强度
按 SQL_ID 聚合计数，而不是看执行时间
ASH 不存执行耗时，只存“被采样到 ON CPU 状态的次数”。这个频次直接反映 CPU 占用强度：一条语句被采样到 120 次，意味着它在过去 5 分钟里平均占用了 120 秒 CPU 时间（等效单核满载 2 分钟）。
用 COUNT(*) 聚合比查 ELAPSED_TIME 更可靠，因为后者在 ASH 中不可用；也比依赖 V$SQL.CPU_TIME 更及时——那玩意儿要等 SQL 执行完才更新，而突发抖动往往在语句还没结束时就触发告警了。
- 聚合粒度必须是
SQL_ID，不是SQL_TEXT——后者受绑定变量、空格、大小写影响，同一逻辑 SQL 可能生成多个不同文本 - 如果
V$SQL查不到文本（SQL_TEXT IS NULL），说明该游标已老化出共享池，需立刻结合SQL_PLAN_HASH_VALUE和DBA_HIST_SQLTEXT回溯 - 注意
SQL_CHILD_NUMBER：同一SQL_ID下不同子游标可能因绑定变量窥探导致执行计划天差地别，别默认当成同一条语句处理
gv$active_session_history 在 RAC 下必须加 INST_ID 过滤
RAC 环境下，gv$active_session_history 返回所有实例的数据，但字段名和结构与单实例一致。如果不显式关联或过滤 INST_ID，容易误把节点 2 的高 CPU SQL 当作节点 1 的问题来优化。
更危险的是：某些 DBA 习惯性加 WHERE INST_ID = 1 后就以为覆盖全量，结果发现根本没抓到真实热点——因为问题实际发生在节点 3。
- 排查前先确认问题发生节点：
SELECT inst_id, COUNT(*) FROM gv$active_session_history WHERE SESSION_STATE = 'ON CPU' AND SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE GROUP BY inst_id - 定位到具体节点后，再查该节点的 top SQL：
WHERE INST_ID = ? AND SESSION_STATE = 'ON CPU' - 别省略
INST_ID字段输出，否则分析报告里无法区分跨节点行为
最常被忽略的一点：ASH 报告本身不带 SQL 文本，只存 SQL_ID。一旦共享池刷新，V$SQL 就查不到原始语句，此时若没提前抓取 DBA_HIST_SQLTEXT 或开启 SQL Trace，就只能靠 PLAN_HASH_VALUE 和对象访问路径反推逻辑——这对紧急响应是个硬伤。
