查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 里记录可能还挂着几分钟。
