Oracle UNDO表空间不可直接删文件或强制resize，必须先确认v$rollstat中所有回滚段状态为OFFLINE，再通过创建新UNDO表空间、切换undo_tablespace参数、验证无活跃事务后，方可安全删除旧表空间。
直接删文件或强制 resize 几乎必然失败——oracle 的 undo 表空间不是普通表空间，它的数据文件里可能“尾部还存着活跃事务的回滚块”，哪怕 v$transaction 看起来空了，v$rollstat 里的 segment 状态没真正 offline，就动不了文件。
查清楚是不是真“涨死了”，别被 dba_data_files 的数字吓住
很多人一看到 bytes/1024/1024/1024 显示 30G 就急着收缩，结果卡在 ORA-03297。先看历史压力和真实占用：
-
v$undostat比当前大小重要得多：执行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 且NOSPACEERRCNT = 0→ 不是空间不够，是长事务没提交，查v$transaction更快-
UNDOBLKS高 +TXNCOUNT低 → 单个大事务（比如全表DELETE）撑爆了，不是配置问题
确认旧 UNDO 表空间是否可安全切换
切换前最常踩的坑是：执行完 ALTER SYSTEM SET undo_tablespace=UNDOTBS2 SCOPE=BOTH 就去删文件，立刻报 ORA-30013。因为旧表空间的 rollback segment 还没真正下线。
- 查 segment 状态：
SELECT usn, xacts, status, rssize/1024/1024, hwmsize/1024/1024 FROM v$rollstat ORDER BY rssize - 所有
status必须是OFFLINE（不是PENDING OFFLINE或ONLINE） - 等不到全部 OFFLINE？说明有会话仍绑定旧 UNDO，检查
v$session中undo_change# > 0且username是业务用户，联系开发确认是否能 kill - RAC 环境下，每个实例必须单独确认自己的 UNDO segment 状态，不能只查一个节点
重建 Undo 表空间时，create undo tablespace 的关键参数
新建表空间不是随便 size 500m 就行，它要扛住峰值事务压力，否则切过去立刻又爆：
- 初始大小建议 ≥ 当前活跃事务峰值占用的
UNDOBLKS × db_block_size（从v$undostat最近高点估算） - 务必加
AUTOEXTEND ON NEXT 128M MAXSIZE 8G（禁用无上限扩展，防再次失控） - 不要设
RETENTION GUARANTEE，除非你明确接受空间无法复用导致频繁扩展——它会让过期 undo 强制保留，反而加剧膨胀 - 文件路径优先用 ASM 别名（如
+DATA/.../undotbs2.285.xxx），避免手工删 OS 文件时误删其他实例的文件
删旧表空间前，最后一步验证和风险点
执行 DROP TABLESPACE UNDOTBS1 INCLUDING CONTENTS AND DATAFILES 前，只剩一个动作：确认没有 session 正在用它。
- 再跑一次：
SELECT s.sid, s.serial#, s.username, t.start_time, t.used_ublk FROM v$transaction t JOIN v$session s ON s.taddr = t.addr WHERE t.xidusn IN (SELECT usn FROM v$rollname WHERE name LIKE 'SYS%') - 如果返回空，且
v$rollstat全 OFFLINE，才能删；否则删到一半会 hang 住，只能重启实例 - 删完别忘了检查 OS 层：ASM 中文件不会自动消失，要用
asmcmd rm；文件系统则要看ls -l是否真没了，没删干净可能下次启动报 ORA-01157 - 重启不是必须步骤，但如果你改过
spfile里的undo_tablespace，且担心SCOPE=BOTH没写进持久化配置，重启是最保险的验证方式
最易被忽略的是：UNDO 膨胀往往不是空间问题，而是应用层事务控制缺陷。切完、删完、重启完，如果同一批批量任务下周又把新 UNDO 撑到 40G，那该修的是代码里的 COMMIT 位置，不是 DBA 的操作流程。
