无法直接查“ON CPU 最久”，因ASH仅存每秒采样快照，无start_time/end_time字段；只能通过ON CPU样本数最多来代理识别长期占用CPU的会话。
直接查不到“最久”——ASH只存采样快照，不是会话生命周期日志；但能找出在 ON CPU 状态下被采样次数最多、持续时间最长的会话。
为什么不能直接算“ON CPU 最久”
ASH 每秒对活动会话做一次采样，每个样本只记录那一刻的状态。一个会话在 CPU 上连续跑了 10 秒，ASH 最多存下 10 条独立样本（还可能因采样抖动或缓冲区覆盖而丢失）。所以没有 start_time 和 end_time 字段可相减，“持续时长”只能靠样本密度反推。
常见误解是用 MIN(sample_time) 和 MAX(sample_time) 相减，这实际算的是该会话在 ASH 中“首次被采到”到“最后一次被采到”的跨度，中间可能空了几十秒，毫无业务意义。
- ASH 默认保留约 1 小时数据（受 SGA 大小和系统负载影响），老样本会被覆盖
- 后台进程（如
ora_mmon_*）或短 SQL 可能高频触发 ON CPU，拉高样本数但不等于业务卡顿 -
session_state = 'ON CPU'不区分是执行业务逻辑、递归 SQL 还是索引分裂，需结合sql_opname和program判断真实来源
查 ON CPU 样本数最多的前 5 个会话
这是最实用、最贴近“谁在长期吃 CPU”的代理指标。样本越多，说明该会话在采样窗口内越频繁地处于 CPU 执行态。
运行：
SELECT session_id, session_serial#, program, module, COUNT(*) AS on_cpu_samples FROM v$active_session_history WHERE session_state = 'ON CPU' AND sample_time > SYSDATE - 1/24 GROUP BY session_id, session_serial#, program, module ORDER BY on_cpu_samples DESC FETCH FIRST 5 ROWS ONLY;
- 务必加
sample_time > SYSDATE - 1/24，否则可能查到已过期或被覆盖的老数据 - 关注
program：如果是oracle@host且含J000，大概率是未提交的 JOB 在后台刷 undo；module为BatchDelete或ETL_Load则指向业务批量操作 - 若
sql_id是0000000000000000或为空，配合sql_opname IN ('INSERT','UPDATE','DELETE')能确认是 DML 引发的后台维护（如索引分裂），不是前台 SQL 本身慢
关联 v$session 和 v$transaction 补全上下文
ASH 给出的是“现象”，真正要干预必须定位到会话和事务实体。光看样本数无法判断是否该 kill。
对上一步查出的高样本会话，立刻执行：
SELECT s.sid, s.serial#, s.username, s.status, s.sql_id, s.event,
t.used_ublk, t.start_time, s.program, s.module
FROM v$session s
LEFT JOIN v$transaction t ON s.taddr = t.addr
WHERE s.sid = &session_id AND s.serial# = &session_serial#;
-
status = 'INACTIVE'但t.used_ublk > 10000（即 >80MB）：极可能是客户端断连后残留事务，必须人工ALTER SYSTEM KILL SESSION 'sid,serial#' -
event = 'SQL*Net message from client'持续出现：应用端没发 commit，事务空挂，需联系开发检查事务边界 -
sql_id在v$session中存在，但在v$sql中查不到文本：说明该 SQL 已老化出共享池，此时应查sql_plan_hash_value和历史执行计划
真正难处理的从来不是“CPU 高”的会话，而是那些在 ASH 里只留下零星 ON CPU 样本、却在 v$transaction 中长期持有数万 used_ublk 的 INACTIVE 会话——它们不显山露水，却让新事务反复报 ORA-30036。
