Oracle 19c的UNDO表空间无法直接RESIZE或SHRINK，因其数据文件头部固定存放回滚段元数据，HWM不可后退，强行RESIZE会报ORA-03297或静默失败；唯一可靠方法是创建新UNDO表空间、切换、等待旧段离线后删除。
Oracle 19c 的 UNDO 表空间无法直接 RESIZE 或 SHRINK，因为数据文件头部固定存放回滚段头，高水位（HWM）不可后退——强行执行 ALTER DATABASE DATAFILE ... RESIZE 会失败或被忽略。
为什么 RESIZE 对 UNDO 表空间无效
UNDO 表空间的数据文件在 Oracle 19c 中属于“不可收缩型”：即使 v$rollstat 显示所有回滚段 STATUS 为 ONLINE 且 XACTS = 0，RESIZE 命令仍可能报错 ORA-03297 或静默不生效。根本原因是 UNDO 文件的第 1 个数据块（block 0）永久绑定回滚段元数据，Oracle 不允许截断该区域。
- 执行
SELECT file_name, bytes/1024/1024 FROM dba_data_files WHERE tablespace_name = 'UNDOTBS1'查到的大小，不代表实际活跃数据量 -
ALTER DATABASE DATAFILE 2 RESIZE 100M在 UNDO 表空间上基本无效，尤其当原大小 > 1G 时几乎必然失败 - 自动扩展开启时，
AUTOEXTEND ON可能导致文件持续膨胀，但关闭后也无法回收已分配空间
唯一可靠方法：切换 + 重建
生产环境唯一被 Oracle 官方文档和 19c 实测验证可行的方式，是创建新 UNDO 表空间、切换、等待旧段离线、再删除旧表空间。整个过程需确保无长事务残留，否则 DROP TABLESPACE 会卡住。
- 先查当前使用状态：
SELECT tablespace_name, status FROM dba_tablespaces WHERE contents = 'UNDO' - 创建新 UNDO 表空间（建议显式指定
RETENTION GUARANTEE避免意外覆盖）：CREATE UNDO TABLESPACE undotbs2 DATAFILE '/u01/oradata/db/undotbs2_01.dbf' SIZE 2G AUTOEXTEND OFF - 切换并持久化：
ALTER SYSTEM SET undo_tablespace = undotbs2 SCOPE=SPFILE；然后SHUTDOWN IMMEDIATE; STARTUP - 确认旧表空间内所有回滚段已离线：
SELECT usn, status FROM v$rollstat WHERE usn IN (SELECT usn FROM v$rollname WHERE name LIKE 'SYS%')；若仍有PENDING OFFLINE，需等事务自然结束或杀掉对应SID,SERIAL#（查v$transaction关联v$session） - 删除旧表空间：
DROP TABLESPACE UNDOTBS1 INCLUDING CONTENTS AND DATAFILES；注意 Windows 下可能需手动删 OS 文件（Linux 通常自动清理）
容易踩的坑：事务未清空、路径权限、参数冲突
操作中途失败，90% 源于这三个点。
-
v$transaction中仍有活跃事务时执行DROP，语句会挂起，且数据库无法响应新 UNDO 分配请求——务必先运行SELECT s.sid, s.serial#, s.username, t.start_time FROM v$session s, v$transaction t WHERE s.taddr = t.addr ORDER BY t.start_time - 新建数据文件路径所在磁盘空间不足，或 Oracle 用户无写权限，会导致
CREATE UNDO TABLESPACE报ORA-01119或ORA-27040 - 忘记修改
undo_retention参数（默认 900 秒），在重建后遇到短事务高峰，可能因 UNDO 不足触发ORA-01555；建议同步执行ALTER SYSTEM SET undo_retention = 1800 SCOPE=BOTH
重建不是“一键缩容”，而是用可控停机窗口换空间回收。真正难的不是命令本身，而是判断何时所有回滚段真正释放——别只看 v$rollstat.STATUS，要交叉验证 v$transaction 和 v$session 的实时关联。
