Oracle 12c+不支持自动收缩临时表空间，ALTER TABLESPACE ... SHRINK SPACE 是需DBA手动执行的在线操作，仅在无活跃排序段、所有RAC实例空闲且tempfile未被锁定时才真正释放磁盘空间。
oracle 12c 及以上版本不支持“自动收缩”临时表空间——alter tablespace temp shrink space 是手动触发的在线操作，且仅在满足特定条件时才真正释放磁盘空间。
为什么 SHRINK SPACE 不是“自动”的
该命令不会随时间或空闲状态自动运行；它必须由 DBA 显式执行。执行后，Oracle 会尝试将临时段中未被使用的空间归还给操作系统，但前提是：临时文件（tempfile）本身未被其他会话锁定、没有活跃排序段、且当前没有大量并发 ORDER BY/GROUP BY 等操作正在使用该空间。
- 即使临时表空间已空闲数小时，
dba_temp_files.bytes仍显示原始大小 -
v$tempseg_usage中used_blocks为 0 并不表示可立即 shrink —— 排序段可能仍被缓存 - RAC 环境下，需在所有实例都无活动使用时才能安全 shrink，否则报错
ORA-12953
ALTER TABLESPACE ... SHRINK SPACE 的实际效果与限制
该命令只对临时表空间有效（不能用于永久表空间），且仅适用于 12c+ 单实例或 RAC 中所有节点均空闲的场景。它不会删除 tempfile，而是尝试截断其物理文件大小。
- 执行前建议先查：
SELECT tablespace_name, file_name, bytes/1024/1024 mb FROM dba_temp_files; - 执行后若未见磁盘空间释放，说明 Oracle 无法安全回收 —— 常见于 tempfile 被写满后又清空，但高水位线未回落
- 真实释放量取决于当前未被任何 session 持有的空闲 extent 数量，不是按“当前使用量”线性缩放
- 命令本身不阻塞 DML，但会短暂持有
TEMPORARY TABLESPACE级别锁
临时表空间持续膨胀的真正原因和应对思路
临时表空间变大，往往不是因为“没 shrink”，而是因为某次大排序（如 CREATE INDEX、ANALYZE TABLE 或报表 SQL）分配了巨大 tempfile，并且该文件后续被设为 AUTOEXTEND ON 后再未重置。
- 检查是否误启用了自动扩展：
SELECT file_name, autoextensible, maxbytes/1024/1024 max_mb FROM dba_temp_files; - 更稳妥的做法是：禁用
AUTOEXTEND，改用固定大小 + 多个较小 tempfile 分散压力（尤其 RAC 下） - 对长期运行的 OLAP 类应用，考虑设置
TEMP_UNDO_ENABLED=TRUE减少重做压力，间接降低临时段争用 - 重启实例确实能清空临时段，但生产环境通常不可行；替代方案是切换到新 tempfile 并 drop 旧的（需先
ALTER DATABASE TEMPFILE ... DROP INCLUDING DATAFILES）
一个可落地的操作流程示例
假设你发现 TEMP 表空间的 tempfile 已涨到 32GB，而实际峰值使用仅 200MB：
- 确认无活跃使用：
SELECT * FROM v$tempseg_usage;返回空集 - 尝试收缩：
ALTER TABLESPACE TEMP SHRINK SPACE; - 若无效，新建小 tempfile：
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/db/temp02.dbf' SIZE 512M; - 再把旧文件 offline 并 drop：
ALTER DATABASE TEMPFILE '/u01/oradata/db/temp01.dbf' DROP INCLUDING DATAFILES; - 注意：drop 前确保新 tempfile 已被分配并使用（可通过
v$tempfile查看status）
真正容易被忽略的是：临时表空间的“大小”本质是历史最大使用痕迹，不是实时占用。想让它变小，得主动干预文件结构，而不是等待系统自动清理。
