结论：alter database tempfile ... resize 大概率失败，shrink space 对临时表空间根本无效；唯一可靠方法是重建temp表空间——新建、切换默认、确认无活跃使用、drop including contents and datafiles。
Oracle TEMPFILE 无法真正 shrink，别试了
直接说结论：ALTER DATABASE TEMPFILE ... RESIZE 大概率失败，SHRINK SPACE 命令对临时表空间根本无效。这不是权限或语法问题，而是 Oracle 底层设计决定的：临时文件是稀疏文件（sparse file），高位可能残留已分配但空闲的区（extent），RESIZE 会因 ORA-03297 报错中断；而临时表空间不支持段空间管理（ASSM）级别的收缩逻辑。
查清“假满”状态：用对视图才能看到真实空闲空间
很多人看到 DBA_TEMP_FREE_SPACE 显示 FREE_SPACE = 0 就以为真没空间了，其实它只反映“未被任何临时段占用”的块，不体现高位碎片。真正能定位可回收空间的是：
-
V$TEMP_SPACE_HEADER：每行对应一个 tempfile，FREE_BLOCKS字段才是当前可立即重用的空闲块数 - 计算真实可用 MB：
SELECT tablespace_name, ROUND((free_blocks*block_size)/1024/1024) free_mb FROM v$temp_space_header; - 对比
DBA_TEMP_FILES.BYTES—— 如果free_mb远小于文件总大小，说明高位有“幽灵占用”，resize 必然失败
生产库安全重建 TEMP 表空间的最小操作链
这是唯一在 open 状态下、不中断业务、且能彻底释放磁盘空间的方法。关键不是“怎么缩”，而是“怎么换”。步骤必须严格顺序执行：
- 新建临时表空间：
CREATE TEMPORARY TABLESPACE temp2 TEMPFILE '/u01/oradata/ORCL/temp02.dbf' SIZE 2G AUTOEXTEND ON NEXT 100M MAXSIZE 8G;（路径、大小按实际规划） - 切换默认：
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;（所有新会话立即生效） - 确认旧 TEMP 无活跃使用：
SELECT sid, serial#, username, program FROM v$session WHERE tempseg_used > 0 AND tablespace = 'TEMP';（结果必须为空） - 删除旧表空间：
DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;（INCLUDING CONTENTS不可省，否则残留临时段）
注意：整个过程不要求停库，但需避开建索引、大表分析、大批量 ORDER BY 等高峰期，否则新 TEMP 尚未就绪时可能触发 ORA-01652。
为什么不能先 offline 再 resize？
有人想走捷径：ALTER DATABASE TEMPFILE ... OFFLINE → resize → online。这不可行，因为：
- 临时文件不支持
OFFLINE（会报 ORA-01516） - 即使强行用
ALTER TABLESPACE ... TEMPFILE OFFLINE，也只是标记为 offline，底层文件仍被 Oracle 进程持有，OS 层无法释放空间 - 临时文件没有 checkpoint 概念，offline 后无法保证所有内存中的排序上下文已清理干净
所谓“无损”，核心是避免 ORA-01652 和业务中断；所谓“收缩”，本质是用新文件替换旧文件——这才是生产环境里真正可落地、可验证、可回退的操作路径。
