查v$sort_usage是唯一能实时捕获TEMP溢出的视图，需关联v$session和v$sql定位语句；segtype为'SORT'/'HASH'/'LOB_TEMPORARY'分别对应排序、哈希、大字段溢出；blocks*8/1024得近似MB数；v$sql.sql_text为空时用sql_id+sid查DBMS_XPLAN.DISPLAY_CURSOR；v$sort_usage为空则依赖v$active_session_history中'direct path write temp'事件回溯；执行计划中TempSpc非零、SORT/HASH操作、Rows与A-Rows严重偏差均预示溢出。
直接查 v$sort_usage，它能立刻告诉你“谁正在写 TEMP、写了多少、为什么写”——这是唯一能抓到实时溢出的视图，其他都是补救或推测。
查 v$sort_usage 关联会话和 SQL
这个视图是第一手证据，但单独看没用，必须连上 v$session 和 v$sql 才能定位到具体语句。注意几个关键点：
-
segtype = 'SORT'表示排序溢出，'HASH'是哈希连接/聚合溢出，'LOB_TEMPORARY'多见于大字段处理 -
blocks * 8 / 1024是近似 MB 数（默认块大小 8KB），值持续增长说明该 SQL 正在实时写入 TEMP -
v$sql.sql_text可能为空：SQL 已执行完、被老化淘汰，或用了绑定变量且未缓存完整文本 - 若
v$sql拿不到，先记下sql_id和sid，再用DBMS_XPLAN.DISPLAY_CURSOR查最近执行计划
当 v$sort_usage 为空时，用 v$active_session_history 回溯
问题只在夜间批处理或某次窗口爆发？v$sort_usage 就是空的——它只记录当前活跃使用。这时得靠 v$active_session_history（ASH）采样数据，它每秒捕获一次活动会话，保留约 1 小时（默认）：
- 最准的信号是
event = 'direct path write temp'，比sort write更可靠 -
p1text = 'tablespace number'也值得过滤，尤其在多租户环境里可能混入其他 PDB 的事件 - 别只看
COUNT(*)，要结合AVG(time_waited)和MAX(sample_time)判断是否真正在写磁盘，而非短暂等待 - 如果 AWR 保留期太短（
dba_hist_wr_control.retention 天），ASH 是唯一能回溯的现场证据
验证执行计划里有没有 TempSpc 溢出动作
光知道 SQL 是哪条不够，得确认它为什么爆 TEMP。用 DBMS_XPLAN.DISPLAY_CURSOR 或 EXPLAIN PLAN 看执行计划，重点盯这些信号：
-
TempSpc列有数值（单位字节），说明该操作预估需要磁盘临时空间 -
Operation是SORT ORDER BY、HASH JOIN、GROUP BY且Bytes或TempSpc远超预期行数 -
Rows估算值和实际A-Rows（来自EXPLAIN PLAN ... FORMAT = 'ALLSTATS LAST'）差距巨大，比如估算 100 行，实际 200 万行 → 很可能 spill 到磁盘 - 嵌套子查询里有
ORDER BY但外层没用到排序结果？纯属白占内存，必溢出
真正难处理的不是“找不到 SQL”，而是找到后发现执行计划里 TempSpc 标了几十 GB 却无法改写——这时候得看 PGA 设置、连接列是否有索引、驱动表是否过小，而不是继续翻视图。
