删不掉UNDOTBS1是因为它仍被实例作为活动undo使用；需先查SHOW PARAMETER undo_tablespace和dba_rollback_segs确认无ONLINE段，再用ALTER SYSTEM SET undo_tablespace=... SCOPE=BOTH切换，关闭闪回、清理长事务后，执行DROP TABLESPACE UNDOTBS1 INCLUDING CONTENTS AND DATAFILES。
删不掉 UNDOTBS1？不是权限问题，而是它还在被 Oracle 当“活 Undo”用着——哪怕你改了参数，事务没清完、回滚段没下线，DROP TABLESPACE 就会卡在 ORA-30013。
确认当前生效的 undo 表空间和活跃回滚段
别信配置文件里写的，得看实例此刻真正在用哪个。执行这两条最直接：
-
SHOW PARAMETER undo_tablespace—— 显示当前生效值 -
SELECT tablespace_name, status FROM dba_rollback_segs WHERE status IN ('ONLINE', 'PENDING OFFLINE');—— 查哪些回滚段还挂着，尤其关注旧表空间名（比如UNDOTBS1）下有没有ONLINE的段
如果第二条查出旧表空间里还有 ONLINE 段，说明切换没真正完成。这时候硬删一定会报 ORA-30013。
切换必须用 ALTER SYSTEM SET ... SCOPE=BOTH
只改 pfile 或只写 SCOPE=SPFILE，重启前不会生效；只写 SCOPE=MEMORY，重启后就失效。真正让实例立刻切换的命令是：
ALTER SYSTEM SET undo_tablespace = 'UNDOTBS2' SCOPE=BOTH;
执行完立刻再查 SHOW PARAMETER undo_tablespace 和 SELECT * FROM v$rollname;，确保新表空间名出现，且旧表空间名不再出现在回滚段列表里。中间可能有几秒延迟，等一等再查。
删除前必须关闪回、清长事务、带完整子句
即使回滚段都 offline 了，Oracle 还可能因闪回功能或延迟清理保留旧 undo 数据，导致删除失败。关键动作：
- 临时关闭闪回：
ALTER DATABASE FLASHBACK OFF;（删完可再开） - 检查长事务：
SELECT start_time, used_ublk FROM v$transaction ORDER BY start_time;，start_time 过老（比如几小时以上）的记录要联系业务确认是否能提交/回滚 - 删表空间必须带完整语法：
DROP TABLESPACE UNDOTBS1 INCLUDING CONTENTS AND DATAFILES;—— 少了AND DATAFILES，物理文件还在磁盘上，空间根本没释放
如果删的时候卡住或报 ORA-01548，大概率是闪回或未清理的 deferred rollback segment 在拦路。
删完别忘了手动清理残留数据文件
DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 会删字典元数据 + OS 层文件，但前提是数据库能正常访问那些文件路径。如果之前数据库异常关闭过，或者文件被其他进程占用，OS 层文件可能删不掉。这时得：
- 确认数据库已 shutdown（不是
shutdown immediate，而是彻底停掉） - 进操作系统，用
ls -l看对应路径下的.dbf文件是否还在 - 手动
rm（生产环境务必先核对路径，别手抖删错盘）
最容易被忽略的是：删表空间命令本身不保证物理文件 100% 被 OS 删除，尤其在 NFS、ASM 或权限受限环境下，得人肉兜底。
