无法直接删除undotbs1，需先确认其是否被使用：执行show parameter undo_tablespace和select tablespace_name, status from dba_rollback_segs where status in ('online', 'pending offline')；若存在undotbs1的online段，则说明仍在使用，必须等待所有段转为offline且v$transaction中无相关事务后，再执行drop tablespace undotbs1 including contents and datafiles。
确认当前undo表空间和活跃回滚段
直接删不掉 UNDOTBS1？先查它是不是还在被用。执行 SHOW PARAMETER undo_tablespace 看当前生效值，再跑：SELECT tablespace_name, status FROM dba_rollback_segs WHERE status IN ('ONLINE', 'PENDING OFFLINE');
只要结果里还有 UNDOTBS1 下的 ONLINE 段，就说明实例仍在用它——哪怕你刚改过参数，事务没提交完，回滚段就不会释放。
切换前必须等“Pending Switch-Out”完成
执行 ALTER SYSTEM SET undo_tablespace = 'UNDOTBS2' SCOPE=BOTH 后，旧表空间不会立刻空闲。Oracle 会在 alert 日志里持续打印类似：[xxxx] active transactions found in undo Tablespace 1 - moved to Pending Switch-Out state.
这不是报错，是提示“正在等”。此时要盯住：
-
SELECT segment_name, status FROM dba_rollback_segs WHERE tablespace_name = 'UNDOTBS1';—— 所有段状态必须变成OFFLINE -
SELECT * FROM v$transaction WHERE xidusn IN (SELECT segment_id FROM dba_rollback_segs WHERE tablespace_name = 'UNDOTBS1');—— 结果应为空
DROP TABLESPACE 会卡住或报 ORA-30013。删除命令必须带 INCLUDING CONTENTS AND DATAFILES
只写 DROP TABLESPACE undotbs1 或 INCLUDING CONTENTS 是危险操作：
- 前者只删数据字典记录，物理文件还躺在磁盘上，占着空间又不被管理
- 后者删了段但不删文件，下次建同名表空间可能因文件已存在而失败
- 真正安全的是
DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES，它同时清理字典+数据文件
ARCHIVELOG），否则会报 ORA-01548；如果启用了闪回，先临时关掉：ALTER DATABASE FLASHBACK OFF。物理文件残留必须手动清理
DROP TABLESPACE ... AND DATAFILES 能删 ASM 或 OMF 管理的文件，但对普通文件系统路径（如 /u01/oradata/db/undotbs1.dbf）只发 rm 系统调用——如果权限不足、挂载点异常或文件正被其他进程占用，OS 层可能删失败，而 SQL 层不报错。所以删完后务必：
- 查
dba_data_files确认记录已消失 - 进 OS 执行
ls -l /path/to/undotbs1.dbf，文件不存在才算真干净 - 若文件还在，别硬删；先查
lsof | grep undotbs1看是否有残留句柄，再决定是否重启数据库实例
