DROP USER ... CASCADE 会卡住或报错，因Oracle需按依赖顺序逐个清理对象，遇活跃会话、回收站残留、主键索引绑定、跨用户引用或锁争用即失败；必须前置查杀会话、清空回收站、解除依赖并确认无表空间绑定，否则易致半残状态。
必须用 DROP USER ... CASCADE，但直接执行大概率卡住、失败或残留——关键在前置检查和分步清理。
为什么 DROP USER username CASCADE 会卡住或报错
这不是语法问题，而是 Oracle 在后台逐个 drop 表、索引、LOB 段、回收站对象时触发的资源争用和锁等待。尤其当用户下有上万张表、大量 XMLTYPE 或 BLOB 列时，DROP USER CASCADE 可能持续数十分钟，期间阻塞数据字典（如 OBJ$），甚至导致 ORA-00604 / ORA-00600 错误。
- 常见卡点：回收站里残留的已删表（
RECYCLEBIN中非空） - 典型报错：
ORA-02429: cannot drop index used for enforcement of unique/primary key—— 说明主键索引是手动创建的，未随表自动删 - 另一个陷阱：
ORA-01940: cannot drop a user that is currently connected，哪怕只是 SQL*Plus 连着没断开，也会中断整个命令
执行前必须确认的三件事
跳过任何一项，DROP USER CASCADE 都可能中途失败并留下半残状态（比如部分表删了、部分没删，DBA_OBJECTS 里还有记录）。
- 查活跃会话：
SELECT sid, serial#, status FROM v$session WHERE username = 'USERNAME';，存在就先ALTER SYSTEM KILL SESSION 'sid,serial#' - 确认无默认表空间依赖：
SELECT username FROM dba_users WHERE default_tablespace = 'USERNAME_TS'，若有其他用户还用着这个表空间，后面删表空间会失败 - 清空回收站：
purge user_recyclebin;（当前用户）或PURGE DBA_RECYCLEBIN;（SYS 执行）——否则CASCADE会把它当“对象”拦住
删完用户后磁盘空间没变？这很正常
DROP USER CASCADE 只清理数据字典（DBA_TABLES、DBA_INDEXES 等），完全不碰物理文件。如果该用户专属一个独立表空间（比如 TQ_DATA），那对应的数据文件（如 /u01/oradata/ORCL/tq_data01.dbf）还在磁盘上。
- 真正释放空间要额外跑：
DROP TABLESPACE TQ_DATA INCLUDING CONTENTS AND DATAFILES; - 但注意：这条命令要求该表空间未被任何用户作为
DEFAULT TABLESPACE或TEMPORARY TABLESPACE使用，否则报ORA-12919 - 删完再查：
lsof | grep 'deleted'，若看到.dbf (deleted)，说明文件句柄还被 DBWn 持有，此时df -h不会反映变化；轻量处理是 kill 对应进程，彻底办法是SHUTDOWN IMMEDIATE+STARTUP
大数据量用户的替代方案：先 truncate 再删
如果用户下只有几张大表撑着体积（比如日志表、历史归档表），比硬删更稳的方式是提前收缩：
- 对每张大表执行：
TRUNCATE TABLE schema.table_name DROP STORAGE;（比DELETE快且不走回滚段） - 再删 LOB 段：
ALTER TABLE schema.table_name MODIFY (lob_col CLOB STORE AS (DISABLE STORAGE IN ROW));+ALTER TABLE ... MOVE LOB(lob_col) STORE AS (...)，避免删用户时 LOB 清理拖慢 - 最后再
DROP USER ... CASCADE，耗时可从小时级降到分钟级
真正麻烦的不是命令本身，而是删完后没人检查 DBA_DATA_FILES 是否还残留路径、也没人跑 lsof 看 deleted 文件句柄——这些才是磁盘空间“消失不见”的真实原因。
