Oracle 11g+ 不支持 UNDO 表空间自动收缩，ALTER TABLESPACE ... SHRINK SPACE 对撤销表空间无效，所有版本均报 ORA-30044；唯一可行方法是创建新 UNDO 表空间、切换、等待事务过期后删除旧表空间。
Oracle 11g+ 不支持 UNDO 表空间自动收缩
直接说结论：alter tablespace ... shrink space 对撤销表空间无效，所有版本的 oracle（包括 11g、12c、19c、21c）都不允许对 undo 表空间执行 shrink 操作。尝试执行会报错：ora-30044: invalid tablespace type for shrink operation。
这是因为撤销表空间的内部结构由 Oracle 自动管理，其数据文件中的“空闲空间”不是传统意义上的碎片，而是被保留用于事务回滚、读一致性、Flashback 等场景的动态缓冲区。即使 DBA_FREE_SPACE 显示有大量空闲块，也不能像普通表空间那样直接收缩。
为什么不能直接 resize undo 数据文件？
即使你看到 undotbs1.dbf 当前大小是 8GB，但实际已用空间只有 1.2GB，也不能简单执行 ALTER DATABASE DATAFILE '.../undotbs1.dbf' RESIZE 2G —— 极大概率会失败并报 ORA-03297: file contains used data beyond requested RESIZE value。
原因在于：撤销段（undo segment）的区（extent）是按需分配、循环重用的，高水位（HWM）位置由最老的未过期撤销记录决定，而这个位置可能远高于当前活跃事务所需范围。Oracle 不允许把 HWM 之后仍可能被 Flashback Query 或未提交事务引用的数据区域裁掉。
常见误操作场景：
- 在
UNDO_RETENTION设为 1800 秒（30 分钟）时，一个长查询运行了 45 分钟，它依赖的撤销数据仍在保留窗口外但未被覆盖 → HWM 被钉住 - 启用了
RETENTION GUARANTEE，导致已提交事务的撤销数据强制保留，无法被覆盖 → 即使空间不足也不会收缩 HWM - 存在长时间未提交的事务（如开发环境忘记
COMMIT），持续占用撤销段且阻止空间回收
真正可行的收缩路径：换表空间 + 切换 + 删除
这是 Oracle 官方认可且唯一稳定的方式，本质是“重建式收缩”，适用于 11g 及以上所有版本：
步骤顺序必须严格遵守：
- 创建新撤销表空间（指定合理初始大小，例如
SIZE 2G，禁用AUTOEXTEND或设MAXSIZE 4G）：CREATE UNDO TABLESPACE undotbs_new DATAFILE '/u01/oradata/db/undotbs_new01.dbf' SIZE 2G; - 切换当前实例使用新表空间：
ALTER SYSTEM SET undo_tablespace = undotbs_new;（该参数是动态的，无需重启） - 等待旧表空间中所有事务完成或过期（可通过
V$TRANSACTION和V$UNDOSTAT确认无活动事务） - 删除旧撤销表空间（含数据文件）：
DROP TABLESPACE undotbs_old INCLUDING CONTENTS AND DATAFILES;
注意：切换后，旧表空间不会立即清空；必须确保 V$ROLLSTAT.STATUS 中对应段全为 EXPIRED 或 OFFLINE，否则 DROP 会报 ORA-30013: undo tablespace 'UNDOTBS_OLD' is currently in use。
收缩后容易被忽略的关键点
换完表空间不等于万事大吉。以下三点常被跳过，直接导致后续再次膨胀或报错：
-
UNDO_RETENTION值必须与业务负载匹配：如果批量作业平均运行 2 小时，UNDO_RETENTION至少设为7200，否则会频繁触发ORA-01555 - 新表空间的数据文件路径和权限需与旧的一致，尤其在 RAC 环境下，要确认所有节点都能访问该路径，否则启动时报
ORA-01157: cannot identify/lock data file - 删除旧表空间后，务必检查操作系统层面文件是否真被清除（特别是 ASM 磁盘组里残留的 alias），避免磁盘空间未释放却误以为已清理
