查V$TEMPSEG_USAGE是最直接方式，它实时反映各会话当前正在使用的临时段（排序、哈希等），需关联dba_tablespaces换算MB，再联v$session获取会话上下文才能准确定位问题源头。
查 V$TEMPSEG_USAGE 是最直接的方式
Oracle 临时表空间的实时占用，核心就看 V$TEMPSEG_USAGE 视图。它记录每个会话当前正在使用的临时段（排序、哈希连接、LOB 操作等），不是历史累计值，也不是分配总量，而是「此刻正在用多少」。
注意：该视图只显示已实际分配并正在使用的临时段，空闲空间或预分配但未使用的空间不体现；且需 SELECT ANY DICTIONARY 或 SELECT_CATALOG_ROLE 权限。
常用查询示例：
SELECT session_addr, sql_id, segtype, blocks * <code>tbs.block_size</code> / 1024 / 1024 AS mb_used FROM v$tempseg_usage t, dba_tablespaces tbs WHERE t.tablespace = tbs.tablespace_name AND tbs.contents = 'TEMPORARY';
其中 blocks 是 Oracle 数据块数，必须关联 dba_tablespaces 获取 block_size 才能换算成 MB，硬编码 8192 是常见坑。
V$SORT_SEGMENT 只反映临时表空间整体状态
V$SORT_SEGMENT 显示的是每个临时表空间中所有临时段（sort segment）的聚合信息，比如总块数、已用块数、最大扩展次数，但它不绑定到具体会话，也无法区分是哪个 SQL 或用户在用。
典型误用场景：有人想靠它定位高消耗会话，结果发现 USED_EXTENTS 很高，但查不到是谁——因为这个视图没 session_id 字段。
它更适合做空间趋势监控，比如配合 AWR 报告观察临时表空间是否长期处于高位，而不是用于实时会话诊断。
- 字段
TOTAL_BLOCKS和USED_BLOCKS是整个表空间维度，非会话维度 - 没有
sql_id、username、osuser等会话上下文字段 - 重启实例后统计会重置，不能用于跨周期归因
结合 V$SESSION 关联才能定位真实会话
V$TEMPSEG_USAGE 的 session_addr 必须和 V$SESSION 的 saddr 关联，才能拿到用户名、机器名、SQL ID、模块等关键信息。单独查 V$TEMPSEG_USAGE 几乎无法落地处理。
推荐一次查全的写法：
SELECT s.sid, s.serial#, s.username, s.osuser, s.machine, s.program,
t.sql_id, t.segtype, t.blocks * tbs.block_size / 1024 / 1024 AS mb_used
FROM v$tempseg_usage t
JOIN v$session s ON t.session_addr = s.saddr
JOIN dba_tablespaces tbs ON t.tablespace = tbs.tablespace_name
WHERE tbs.contents = 'TEMPORARY'
ORDER BY mb_used DESC;注意点：
-
serial#必须带上，否则alter system kill session时会报错 ORA-00030 - 如果
sql_id为空，说明是递归操作（如索引维护）或 SQL 已被老化出共享池，此时要看sql_exec_start和prev_sql_id - 某些后台进程（如
ora_q001_*）也会出现在这里，属于正常并行执行，别一概 kill
临时表空间爆满时，V$TEMPSEG_USAGE 可能滞后或不完整
当临时表空间真的写满（报 ORA-01652），部分会话可能已无法写入新临时段，V$TEMPSEG_USAGE 中对应记录可能消失或停留在旧状态——因为 Oracle 在分配失败时不会更新该视图。
这时要交叉验证：
- 查
dba_temp_free_space确认剩余空间是否真为 0 - 查
v$sort_usage（旧版兼容视图，字段更少但更稳定） - 查
v$process+v$session找长时间未响应的会话，特别是status = 'ACTIVE'且last_call_et > 300
临时表空间不像数据文件那样支持在线 resize，扩容前务必确认磁盘可用空间，且 ALTER TABLESPACE ... ADD TEMPFILE 需要独占表空间 DML 锁，高峰期慎操作。
