oracle 11g中undo表空间不释放物理空间是设计使然，根本原因是默认开启的\_undo\_autotune=true动态拉高tuned\_undoretention、数据文件非自动扩展、以及长事务或unexpired段堆积共同导致空间无法重用；真正释放磁盘须重建undo表空间。
Oracle 的 UNDO 表空间不会“自动释放”物理磁盘空间，这是设计使然——ALTER TABLESPACE undotbs1 SHRINK SPACE 或 ALTER DATABASE DATAFILE ... RESIZE 在 11g 及以后版本（包括 19c）必然失败，报 ORA-30036 或 ORA-1237。所谓“释放”，实际是指让空间可被新事务重用；而真正腾出磁盘，则必须重建。
为什么UNDO表空间看起来“占着不放”？
根本原因不是配置错或没清理，而是 Oracle 主动锁住了空间：
-
_undo_autotune=TRUE（默认开启）会动态拉高tuned_undoretention，远超你设的undo_retention；查SELECT MAX(TUNED_UNDORETENTION) FROM v$undostat，若返回值是几万秒（几小时），说明它正在把已提交但未到期的 undo 强制标记为UNEXPIRED，禁止覆盖 - 数据文件
AUTOEXTEND OFF时，Oracle 更倾向延长保留时间防ORA-01555，而非收缩文件；哪怕v$rollstat.XACTS = 0，DBA_UNDO_EXTENTS.STATUS里仍堆满UNEXPIRED - 长事务未提交或挂起（
v$transaction.used_ublk > 10000且idle_mins > 5）会持续占用 active undo 段，导致整个表空间无法进入 cleanup 流程
如何确认当前是否真需要重建？
别一上来就建新表空间。先跑三句诊断 SQL，看问题出在哪层：
- 查空间压力来源：
SELECT BEGIN_TIME, UNDOBLKS, TXNCOUNT, MAXQUERYLEN, NOSPACEERRCNT FROM v$undostat ORDER BY BEGIN_TIME DESC FETCH FIRST 10 ROWS ONLY—— 若NOSPACEERRCNT > 0，说明已发生ORA-30036，必须干预；若MAXQUERYLEN > undo_retention，说明有长查询在锁旧版本 - 查活跃事务：
SELECT s.sid, s.serial#, s.username, t.used_ublk, (SYSDATE - t.start_time) * 24 * 60 idle_mins FROM v$transaction t JOIN v$session s ON s.taddr = t.addr ORDER BY t.start_time—— 找出idle_mins > 5且used_ublk值大的会话，优先联系业务确认是否可提交或 kill - 查段状态：
SELECT segment_name, status FROM dba_rollback_segs WHERE tablespace_name = 'UNDOTBS1'—— 全部是OFFLINE才代表旧表空间真正空闲，可删；只要有一个ONLINE或PENDING OFFLINE，切换后立刻删会报ORA-01548
重建UNDO表空间的实操步骤（CDB/PDB 必须分清）
重建不是简单删了再建，关键在“切换时机”和“容器上下文”：
- 先确认当前容器：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL—— 若是CDB$ROOT，操作影响整个 CDB；若是 PDB，只改该 PDB 的undo_tablespace - 建新表空间（建议带
AUTOEXTEND）：CREATE UNDO TABLESPACE undotbs2 DATAFILE '+DATA' SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE 2G—— 初始大小按历史v$undostat.UNDOBLKS峰值估，别盲目设小 - 切换参数并持久化：
ALTER SYSTEM SET undo_tablespace=undotbs2 SCOPE=BOTH——SCOPE=BOTH确保重启不回退；切完立刻查v$parameter.undo_tablespace确认生效 - 等所有旧段 offline：
SELECT segment_name, status FROM dba_rollback_segs WHERE tablespace_name = 'UNDOTBS1'—— 必须全部返回OFFLINE；如果卡住，检查是否有隐式事务（如 PL/SQL 中未 commit 的 DML）或未关闭的 JDBC 连接 - 删旧表空间（含文件）：
DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES—— 这步才真正释放磁盘；若报ORA-01548，说明还有 active 回滚段，别硬删，回上一步排查
重建后容易被忽略的坑
重建完成不等于万事大吉，两个细节常被跳过：
- 旧 UNDO 表空间的数据文件即使被删，ASM 磁盘组里可能还留着 alias（尤其用
+DATA/.../undotbs1.dbf路径时）；手动进 ASM 查ls +DATA/<db_name>/UNDOTBS1</db_name>，有残留就rm掉，否则磁盘空间不真实释放 - 如果之前关过
_undo_autotune，重建后建议保持关闭，除非你明确需要自动调优；否则新表空间很快又会被tuned_undoretention拉满——它不认“刚建的空表空间”，只认负载
