重建temp表空间是唯一可靠解法，因其不自动回收已分配临时段；需新建temp2、切换默认、确认无会话使用旧temp、再drop tablespace including contents and datafiles。
oracle 的临时表空间段不会“不再使用”后自动消失——它根本不会被标记为“可清理”，除非你主动重建 temp 表空间或触发 smon 清理，而后者在多数生产场景下已失效。直接查 dba_segments 对 temp 表空间毫无意义，因为临时段不走段管理逻辑。
为什么 SELECT * FROM dba_segments WHERE tablespace_name = 'TEMP' 查不到东西
临时段（如排序、哈希连接产生的 segment）不记录在 dba_segments 中，它们只存在于 v$sort_usage 和 v$tempseg_usage（12c+）这类动态视图里，且生命周期与会话绑定。一旦会话结束，段应被释放；但若因异常中断、SMON 未及时扫描或高位 extent 被占用，就会残留“已分配但空闲”的状态——此时 dba_free_space 也查不到空闲块，dba_temp_free_space 显示 100% 使用率，却找不到活跃会话。
-
dba_segments只管永久段（表、索引等），对临时段完全不可见 -
v$sort_usage是唯一能实时看到“谁正在用、用了多少块”的视图，但它只反映当前活跃使用，不包含已分配未释放的残留段 - 试图用
ALTER TABLESPACE temp DROP SEGMENT或类似命令？Oracle 不支持该语法，会报 ORA-02158
怎么确认 TEMP 表空间里真有残留段
别依赖“有没有会话在用”，要看底层空间是否真的可回收。关键指标来自 v$temp_space_header（注意不是 v$tempfile 或 dba_free_space）：
SELECT tablespace_name, round((free_blocks*block_size)/1024/1024) free_mb FROM v$temp_space_header WHERE tablespace_name = 'TEMP';
如果返回 FREE_MB 接近 0，但 v$session 和 v$sort_usage 都为空，说明存在高位未释放 extent —— 这就是典型残留。此时 ALTER DATABASE TEMPFILE ... RESIZE 必然失败，报 ORA-03297。
- 必须用
v$temp_space_header，它是唯一反映 tempfile 实际空闲块数的视图 -
dba_temp_free_space的FREE_SPACE字段常失真，尤其在 autoextend 启用后 - 不要执行
ALTER TABLESPACE TEMP COALESCE：对临时表空间无效，语句成功但无实际效果
真正有效的清理动作只有两个：重建 or 诊断事件
重建是首选，诊断事件是应急兜底。没有“清理段”的中间态操作：
- 重建流程必须完整：
CREATE TEMPORARY TABLESPACE temp2→ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2→ 确认v$session中tablespace = 'TEMP'的结果为空 →DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES - 诊断事件
alter session set events 'immediate trace name DROP_SEGMENTS level <ts>'</ts>仅在紧急且无法新建表空间时使用；需先查sys.ts$得到 TEMP 的TS#，再加 1 填入 level；该操作不保证 100% 成功，且可能引发短暂 latch 冲突 - 别信
ALTER TABLESPACE temp INCREASE 1+INCREASE 0：这是老版本 Metalink 的 hack，12c+ 基本失效，SMON 不再响应这种抖动
最易被忽略的一点：临时表空间可以没有数据文件，但不能没有文件还维持表空间存在——如果你删光了所有 tempfile 却没 DROP TABLESPACE，新排序操作会立刻报 ORA-01652，而不是静默降级。重建不是“优化”，是唯一能重置分配位图的操作。
