如何查看Oracle当前正在运行的SQL消耗的Temp空间量？

查TEMP空间需关联v$sort_usage与v$session获取SQL文本，注意sql_id对应prev_sql_id；查不到时用ASH或DBA_HIST视图定位；临时段释放有延迟，需综合多视图分析。

查正在执行的SQL用了多少TEMP空间，用 v$sort_usage + v$session 关联

直接查 v$sort_usage 能看到当前会话在临时表空间里的实际块数（blocks），但必须和 v$session 关联才能拿到真实 sql 文本。注意：这里的 sql_id 来自 v$sort_usage，它对应的是 v$session.prev_sql_id，不是当前正在跑的 sql_id —— 如果会话刚切了新 sql，旧 sql 已结束但排序段还没释放，v$sort_usage 仍显示前一条。

• v$sort_usage.blocks 是已分配的 Oracle 数据块数，需乘以 db_block_size 才得字节数
• 别用 v$sqlarea，它已废弃；改用 v$sql，且要通过 address + hash_value 或更稳妥的 sql_id 关联
• 如果查不到 sql_text，说明该 SQL 已从共享池老化，可尝试查 v$sql_plan 或历史视图 dba_hist_active_sess_history

为什么查到的 SQL 看起来很简单，却占了几百 MB TEMP？

常见错觉来源是执行计划里隐含的大排序或哈希操作。比如一个 ORDER BY 没加索引、GROUP BY 字段多、或 UNION ALL 后接 ORDER BY，都可能触发大量内存外溢（spill）到 TEMP。Oracle 不会在 SQL 文本里标出“我用了 TEMP”，只在运行时根据 PGA 内存不足自动落盘。

• 查执行计划：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('xxx_sql_id', NULL, 'ALLSTATS LAST'))，重点看 Operation 列是否有 SORT ORDER BY、HASH JOIN、TEMP TABLE TRANSFORMATION
• BYTES 和 TEMP_SPACE 列（如果可用）比 rows 更能反映实际开销
• 单条语句的 blocks 值高 ≠ SQL 写得差，可能是数据量突增或绑定变量导致优化器选错计划

查不到 SQL 文本时，怎么定位真正的问题语句？

当 v$sort_usage 关联不到 v$sql.sql_text，说明该 SQL 已不在共享池。这时得靠历史视图反推，核心是 gv$active_session_history（ASH）—— 它每秒采样一次，保留默认 1 小时（或按 AWR 保留策略），记录了 temp_space_allocated。

• 查最近 30 分钟内 TEMP 消耗 Top 5：SELECT sql_id, SUM(temp_space_allocated)/1024/1024/1024 gb FROM gv$active_session_history WHERE temp_space_allocated > 0 AND sample_time > SYSDATE - 30/1440 GROUP BY sql_id ORDER BY gb DESC FETCH FIRST 5 ROWS ONLY
• 再用 sql_id 查完整文本：SELECT sql_text FROM v$sql WHERE sql_id = 'xxx'；若无结果，查 dba_hist_sqltext
• 注意：ASH 中的 temp_space_allocated 是累计值，单位是字节，不是瞬时占用；所以更适合找“谁长期吃得多”，而不是“此刻谁最卡”

dba_temp_free_space 显示 Free Space 为 0，但查询还能跑？

这是 Oracle 临时表空间的典型行为：空闲空间不等于“可立即分配”的空间。dba_temp_free_space 统计的是未被任何会话使用的 tempfile 物理空间，但临时段（sort segment）是动态创建/释放的，且每个会话独占一个 segment。即使 free space 为 0，只要 tempfile 设置了 AUTOEXTENSIBLE=YES，就能继续扩展；否则会报 ORA-01652: unable to extend temp segment。

• 别只看 dba_temp_free_space，要同步查 dba_temp_files 的 maxbytes 和 autoextensible
• 临时文件扩展会阻塞当前 SQL，但不会中断已运行的语句 —— 所以你看到“还能跑”，其实是它正卡在扩展 I/O 上
• 真正危险的信号是 v$sort_usage 里出现大量相同 sid + 不同 segfile# 的记录，说明频繁创建/销毁临时段，可能触发 latch 竞争

查 TEMP 消耗不能只盯一个视图，v$sort_usage 给实时快照，gv$active_session_history 补历史脉络，dba_temp_files 和 dba_temp_free_space 说物理底线 —— 三者缺一不可。最容易被忽略的是：临时段释放有延迟，刚 kill 掉会话，v$sort_usage 里记录可能还挂着几分钟。