Oracle临时表空间不释放是设计行为，非bug；真实空闲空间需查v$temp_space_header的free_blocks，SHRINK SPACE和COALESCE无效，RESIZE常失败，LOB操作易长期占用，唯一可靠解法是重建临时表空间。
Oracle临时表空间持续增长却不释放，不是bug，是设计行为——临时文件（tempfile）一旦扩展，高位已分配的extent不会自动回收，哪怕所有会话都结束了。
查真实空闲空间必须用 v$temp_space_header，别信 DBA_TEMP_FILES
DBA_TEMP_FILES.bytes 只显示文件大小，不是可用空间；v$sort_usage 查不到活跃会话，也不代表空间真空闲。真正反映“还能不能分新临时段”的，只有 v$temp_space_header：
-
free_blocks是当前可分配的空闲区数，used_blocks是已标记为“已用”但可能实际空闲的块 - 计算真实空闲 MB：
SELECT tablespace_name, round((free_blocks * block_size) / 1024 / 1024) free_mb FROM v$temp_space_header; - 如果
free_mb接近 0，哪怕DBA_TEMP_FILES显示还有几十 GB，你也随时会遇到ORA-01652
ALTER TABLESPACE ... SHRINK SPACE 对 TEMP 表空间完全无效
这个命令只作用于永久表空间的段（segment），而 TEMP 表空间底层用的是 tempfile，管理逻辑完全不同。Oracle 文档明确限定不支持对 TEMP 执行 SHRINK SPACE：
- 执行后无报错 ≠ 生效，只是语法通过，实际什么都没做
-
ALTER DATABASE TEMPFILE ... RESIZE也常失败，报ORA-03297：高位有未释放 extent，无法缩容 -
ALTER TABLESPACE TEMP COALESCE对临时表空间无意义，它只合并永久段的相邻空闲区
LOB 操作是隐藏的长期占用元凶
应用通过长连接读取含 CLOB/BLOB 字段的表，并做 ORDER BY 或 GROUP BY 时，Oracle 会分配 TEMPORARY LOB_DATA 段，但不会在语句结束后主动清理——这部分空间会一直卡住，直到会话断开或显式调用 DBMS_LOB.FREETEMPORARY：
- 检查方法：
SELECT sid, sql_id, contents FROM v$sort_usage WHERE contents = 'TEMPORARY LOB_DATA'; - 确认来源：
SELECT sid, username, program, machine FROM v$session WHERE sid IN (...); - 这类占用在监控中极难发现，
v$sort_usage里显示为contents = 'TEMPORARY LOB_DATA'，而非常规的'SORT'
重建 TEMP 表空间是唯一可靠解法
临时文件不收缩、SMON 不回收高位 extent、RESIZE 失败——绕不开重建。关键点在于顺序和验证：
- 新建：
CREATE TEMPORARY TABLESPACE temp2 TEMPFILE '/u01/oradata/ORCL/temp02.dbf' SIZE 2G AUTOEXTEND ON NEXT 100M MAXSIZE 16G; - 切换默认：
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;（不影响已连会话） - 确认无残留：
SELECT sid, serial#, username FROM v$session WHERE tempseg_used > 0 AND tablespace = 'TEMP';（结果必须为空） - 删除旧表空间：
DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;（INCLUDING CONTENTS必须加，否则物理文件删不掉）
整个过程数据库无需重启，但必须确保没有后台作业正在跑大规模排序或建索引——否则新会话可能因 temp2 尚未完全就绪而失败。最容易被忽略的是：tempseg_used > 0 的判断条件，仅靠 v$sort_usage 或 v$session.status = 'ACTIVE' 都不足以证明旧 TEMP 已空闲。
