undo表空间暴涨应先排查是否真不可回收：若v$undostat显示nospaceerrcnt为0且maxquerylen小于undo_retention，大概率是长事务未提交，需查v$transaction定位idle_mins>5且used_ublk>10000的挂起事务，而非盲目切换表空间。
undo 表空间暴涨不是必须立刻删文件，而是先看它是否真“不可回收”——很多情况下，undo 占用高但状态全是 unexpired，说明只是 undo_retention 设置过长或事务未提交，根本不用切换表空间。
v$undostat 查历史压力，别只盯当前大小
v$undostat 每10分钟一条记录，最多保留4天，比看 dba_data_files 的“已用GB”更有诊断价值：
-
UNDOBLKS高 +TXNCOUNT低 → 单个事务极大（比如全表DELETE） -
MAXQUERYLEN持续 >UNDO_RETENTION→ 查询太长，旧版本被强制保留 -
NOSPACEERRCNT> 0 → 已发生ORA-30036，必须干预
执行这条语句快速定位：
SELECT BEGIN_TIME, UNDOBLKS, TXNCOUNT, MAXQUERYLEN, NOSPACEERRCNT FROM v$undostat ORDER BY BEGIN_TIME DESC FETCH FIRST 10 ROWS ONLY;
如果 NOSPACEERRCNT 为 0，且 MAXQUERYLEN 明显小于 UNDO_RETENTION，那大概率是长事务没提交，直接查 v$transaction 更快。
v$transaction 找真凶，不是所有“占用”都该切
别一上来就建新 UNDOTBS2。先确认是不是有事务卡住：
SELECT s.sid, s.serial#, s.username, s.osuser, s.machine,
t.start_time, t.used_ublk, t.used_urec,
(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 > 10000→ 极可能是应用忘记COMMIT或阻塞挂起 -
username是业务账号（非DBA或SYSTEM）→ 联系对应开发确认逻辑 -
osuser/machine指向某台应用服务器 → 可临时重启该连接池
这时候切表空间没用：新表空间一样会被同一个事务撑爆。
切换 undo_tablespace 前，必须等 OFFLINE 状态
很多人执行完 ALTER SYSTEM SET undo_tablespace=undotbs2 SCOPE=BOTH 就去删旧文件，结果报 ORA-30013。原因：旧 UNDOTBS1 的 rollback segment 还没真正下线。
验证是否可删，只看这一条：
SELECT usn, status, xacts, rssize/1024/1024 MB FROM v$rollstat WHERE status != 'OFFLINE';
只要输出为空，才代表所有 segment 已释放。否则要等——有时需数分钟，尤其 RAC 环境各实例同步有延迟。
注意：v$rollstat 不显示 ACTIVE 事务，它只反映 segment 状态；真正活跃事务得靠 v$transaction。
删除旧 UNDOTBS1 文件时，DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 不一定安全
Oracle 11g 默认不支持 AND DATAFILES 自动删 OS 文件（尤其 ASM 或某些文件系统权限受限时）。更稳妥的步骤是：
- 先执行
DROP TABLESPACE undotbs1 INCLUDING CONTENTS - 再手动确认数据文件是否还在：
ls -lh /u02/oradata/db/UNDOTBS1* - 如果文件残留，且数据库已关掉归档或处于 MOUNT 状态，可用
rm安全删除；否则应通过ASMCMD（ASM）或 DBA 操作系统权限清理
另外，DBA_DATA_FILES 视图可能缓存旧路径，删完后执行 SELECT * FROM dba_data_files WHERE tablespace_name = 'UNDOTBS1' 应返回空行——若还有记录，说明 DROP 未真正生效，不能认为释放完成。
真实场景里，UNDO 涨得快往往不是配置问题，而是某张表被误执行了无 WHERE 条件的 UPDATE 或 DELETE，或者应用层批量任务没加 COMMIT。切表空间只是转移症状，不是根治。最该盯的永远是 v$transaction 和业务 SQL 日志。
