必须限定时间范围并按SQL_ID与PLAN_HASH_VALUE聚合ASH数据以准确定位temp写抖动，因v$sort_usage的SQL_ID不可靠且ASH不存TEMP_SPACE_ALLOCATED字段；临时表空间I/O抖动持续时间短、爆发性强，不加时间过滤和正确聚合会导致结果稀释、响应慢、漏掉问题窗口。
直接查 v$active_session_history 中的 direct path write temp 等待事件，但必须加时间过滤和按执行计划聚合，否则结果无效。
为什么不能直接 SELECT * FROM v$active_session_history WHERE EVENT = 'direct path write temp'
因为临时表空间 I/O 抖动通常只持续几分钟，甚至几十秒；全表扫描 v$active_session_history 会：
- 拖慢查询本身（ASH 表可能有数百万行）
- 返回大量低采样、无意义的历史记录，稀释真实问题窗口
- 完全错过真正高负载的那几秒——抖动峰值往往被平均掉
- DELTA_TIME 在短事件中常为 0 或被合并，用 SUM(DELTA_TIME) 统计反而失真
必须限定时间范围并按 SQL_ID + PLAN_HASH_VALUE 聚合
临时写入不是按“SQL 文本”发生的，而是按“实际执行计划”触发的。尤其并行 SQL：多个 PX 进程共享同一 SQL_ID，但各自写 temp，若只 GROUP BY SQL_ID，会把一次执行误算成 N 次，误导定位。
- 时间范围建议从最近 5–10 分钟开始：
sample_time > SYSDATE - 1/144（10 分钟）或更窄，如- 1/288（5 分钟） - 必须
GROUP BY SQL_ID, PLAN_HASH_VALUE，不能省略后者 - 统计用
COUNT(*)（采样次数），它反映该执行计划在抖动窗口内被观测到的频次，比耗时类指标更稳定
典型语句：
SELECT SQL_ID, PLAN_HASH_VALUE, COUNT(*) samples FROM v$active_session_history WHERE EVENT = 'direct path write temp' AND sample_time > SYSDATE - 1/288 GROUP BY SQL_ID, PLAN_HASH_VALUE ORDER BY samples DESC FETCH FIRST 5 ROWS ONLY;
别信 v$sort_usage.SQL_ID，它和当前写 temp 的 SQL 几乎无关
v$sort_usage 里的 SQL_ID 来自 v$session.prev_sql_id，只要会话执行了新语句，旧临时段就“断连”。你看到的可能是 20 分钟前的一条简单查询，而此刻正在狂写 temp 的是另一条未被捕获的并行报表 SQL。
- ASH 是唯一能捕获“溢出发生瞬间”的来源——每秒采样一次，带完整上下文（含当时真实的
SQL_ID和PLAN_HASH_VALUE） - 查到高采样 SQL 后，下一步不是杀会话，而是立刻用
DBMS_XPLAN.DISPLAY_CURSOR看执行计划，确认是否存在磁盘排序路径（如SORT ORDER BY、HASH JOIN、TEMP TABLE TRANSFORMATION） - 如果计划里没这些节点，说明写 temp 可能来自隐式操作（如大对象处理、索引重建），需结合
sql_id查v$sql的command_type和sql_text上下文
临时段归属错误是生产环境高频误操作点
靠 v$sort_usage 找到的 session，90% 以上不是真正的问题源头。一旦误杀，不仅解决不了 I/O 抖动，还可能中断关键事务或报表作业。真正的线索藏在 ASH 的采样快照里——它不依赖会话状态，只忠实记录“那一秒发生了什么”。时间窗越窄、聚合维度越准（SQL_ID + PLAN_HASH_VALUE）、统计方式越简单（COUNT），定位就越可靠。复杂度不在查询本身，而在对采样逻辑和临时段生命周期的理解是否到位。
