怎样在Oracle中使用ASH找出消耗CPU最多的Top SQL-Oracle-PHP中文网

查V$ACTIVE_SESSION_HISTORY须加时间窗口和SESSION_STATE='ON CPU'，因默认仅存1小时采样数据且为概率采样；RAC环境必须用GV$视图并带上SQL_CHILD_NUMBER；查到SQL_ID后应立即用DBMS_XPLAN.DISPLAY_CURSOR验证实时执行计划。

怎样在oracle中使用ash找出消耗cpu最多的top sql

查 `V$ACTIVE_SESSION_HISTORY` 必须加时间窗口和 `SESSION_STATE = 'ON CPU'`

不加时间过滤，V$ACTIVE_SESSION_HISTORY 默认只保留最近 1 小时数据，且采样是概率性（每秒约 1 次），不是连续记录。你看到“查不到高 CPU SQL”，大概率是时间没卡准，或者样本已被滚动覆盖。

必须用动态时间条件，比如：SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE。别写死字符串（如 '2026-10-26 18:00:00'），NLS 设置或时区偏差会导致查空。

只统计 SESSION_STATE = 'ON CPU' 的样本——这是 CPU 真正被占用的明确信号；混入 WAITING 样本会稀释结果，把 I/O 等待误判为 CPU 消耗。

按 `SQL_ID` 聚合计数，别依赖 `SQL_TEXT` 或执行时间字段

COUNT(*) 是最稳的指标：一个 SQL 在 CPU 上跑了 3 秒，大概率被采样 3 次；另一个跑 10 秒但中间频繁切换状态，可能只记 1–2 次。用 SUM(DELTA_TIME) 反而不可靠，短事件中该值常为 0 或被合并。

聚合时只用 SQL_ID，不要 GROUP BY SQL_TEXT——绑定变量缺失会让同一逻辑语句生成几十个不同 SQL_ID，但文本相似度高；反过来，若强制按文本分组，又会把不同 SQL_ID（如不同子游标）错误合并。

示例语句（单实例）：

SELECT SQL_ID, COUNT(*) SAMPLES
FROM V$ACTIVE_SESSION_HISTORY
WHERE SESSION_STATE = 'ON CPU'
  AND SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE
GROUP BY SQL_ID
ORDER BY SAMPLES DESC
FETCH FIRST 5 ROWS ONLY;

RAC 环境必须用 `GV$ACTIVE_SESSION_HISTORY`，且注意 `SQL_CHILD_NUMBER`

单节点查 V$ 视图只能看到本实例样本，而 CPU 高峰可能集中在 node2 或 node4。RAC 下必须用 GV$ACTIVE_SESSION_HISTORY，否则直接漏掉问题源头。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

SQL_ID 相同不代表执行计划一致。同一 SQL_ID 下不同 SQL_CHILD_NUMBER 可能因绑定变量窥探、统计信息陈旧导致计划天差地别。排查时务必带上 SQL_CHILD_NUMBER，后续查 DBMS_XPLAN.DISPLAY_CURSOR 才能对上真实计划。

示例（RAC）：

SELECT INST_ID, SQL_ID, SQL_CHILD_NUMBER, COUNT(*) SAMPLES
FROM GV$ACTIVE_SESSION_HISTORY
WHERE SESSION_STATE = 'ON CPU'
  AND SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE
GROUP BY INST_ID, SQL_ID, SQL_CHILD_NUMBER
ORDER BY SAMPLES DESC
FETCH FIRST 5 ROWS ONLY;

查到 `SQL_ID` 后，立刻用 `DBMS_XPLAN.DISPLAY_CURSOR` 看实时执行计划

别急着改 SQL 文本。先确认它当前是否真在走高 CPU 路径：重点看执行计划里有没有这些物理操作节点：

SORT ORDER BY / SORT GROUP BY（内存不足触发排序溢出）
HASH JOIN / HASH GROUP BY（哈希表太大，反复重试）
TEMP TABLE TRANSFORMATION（尤其带大量插入的 WITH 子句）

执行：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('abc123xyz', 123456789));，注意看 TempSpc 列是否有数值（单位字节）——有值说明 CBO 预估已知要落盘，但实际是否发生，还得结合 ASH 的 direct path write temp 事件交叉验证。

真正难缠的是那些 SQL_ID 查不到文本的情况：说明它已被老化出共享池。此时得靠 SQL_PLAN_HASH_VALUE 和历史 AWR 记录反推逻辑意图，而不是盯着空 SQL_TEXT 干等。