查不到最近5分钟ON CPU样本是因为时间条件写错，必须用SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE动态表达式，禁用写死时间字符串或BETWEEN；RAC环境须用gv$active_session_history；务必过滤SESSION_STATE = 'ON CPU'并按SQL_ID聚合计数。
查不到最近5分钟的ON CPU样本？时间条件写错了
直接查不到，八成是用了写死的时间字符串，比如 '2026-10-26 19:40:00'。系统时区、NLS_DATE_FORMAT 或会话时区稍有偏差，结果就是空集。ASH内存只保留约1小时，且采样是概率性（每秒约1次），必须用动态表达式：SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE。别用 BETWEEN 包死区间——问题可能发生在19:41:59.7，而采样点只落在 .0/.1/.2 秒，BETWEEN '19:41:00' AND '19:42:00' 就会漏掉。
RAC环境只查v$active_session_history？你只看到1/4真相
RAC下必须用 gv$active_session_history，否则只查到当前节点的样本。CPU打满可能全在node3，你在node1上执行 v$active_session_history 查询，结果全是“没异常”。要确认实例号是否在线：SELECT instance_number FROM v$instance，再确保查询覆盖所有节点。如果漏掉 g 前缀，等于关掉三台监控摄像头只盯一台。
为什么按SQL_ID聚合计数比看执行时间更准？
ASH不存执行耗时，只存“被采样到 ON CPU 状态的次数”。一次采样=约1秒CPU占用（等效单核）。所以 COUNT(*) 越高，真实CPU消耗越重。常见错误是加了 WHERE event IS NOT NULL 或漏掉 SESSION_STATE = 'ON CPU'——混入 enq: TX - row lock contention 或 db file sequential read 样本，就把锁等待当CPU问题处理了。大小写也敏感：'ON CPU' 不能写成 'on cpu'。
查出SQL_ID但看不到SQL_TEXT？别急着翻AWR
V$ACTIVE_SESSION_HISTORY 只存 SQL_ID，文本得从共享池捞：SELECT SQL_TEXT FROM V$SQL WHERE SQL_ID = 'abc123xyz'。但如果这条SQL已被老化出共享池（比如执行完就不再调用），V$SQL 就查不到。这时别硬等AWR报告生成（通常滞后30分钟以上），先用 SQL_PLAN_HASH_VALUE 和 V$SQL_PLAN 看当前是否存在活跃子游标；若也没有，说明它已彻底退出内存——那就要立刻去应用日志或监控里反查这个 SQL_ID 对应的业务操作，而不是在数据库里空转。
