drop user cascade 会卡住或报错，因需按依赖顺序清理对象，遇锁住对象、活跃会话、跨用户引用（如type、同义词）、未回收权限或物化视图日志等即失败；必须提前查杀会话、清理依赖、回收权限、删除特殊对象，否则无法完成。
drop user cascade 为什么有时会卡住或报错
因为 oracle 在执行 drop user cascade 前，会尝试按依赖顺序逐个清理对象（比如先删视图、再删表、最后删用户），一旦遇到锁住的对象、正在运行的会话、或被其他用户引用的同义词/权限，就会中断并报错，比如 ora-01918: user 'xxx' does not exist（其实是中途失败后状态不一致）或更常见的 ora-00054: resource busy and acquire with nowait specified。
常见诱因包括：用户仍有活跃会话、存在 DBA 角色授予的系统权限未回收、有基于该用户的物化视图日志、或该用户拥有被其他 schema 引用的 TYPE（尤其在使用 CREATE TYPE ... AUTHID CURRENT_USER 场景下）。
- 执行前务必查
SELECT sid, serial#, status FROM v$session WHERE username = 'YOUR_USER'，用ALTER SYSTEM KILL SESSION 'sid,serial#'清掉残留会话 - 检查是否有跨用户依赖：
SELECT owner, type, name FROM dba_dependencies WHERE referenced_owner = 'YOUR_USER'，这类 TYPE 或 PACKAGE BODY 往往要先手动删掉被引用方 -
DROP USER CASCADE不会自动回收通过GRANT ... TO PUBLIC授予的权限，得先手动REVOKE
强制清理前必须手动干掉的三类对象
Oracle 的 CASCADE 并不真正“强制”，它只是递归删除本用户拥有的对象，但对某些跨 schema 或系统级绑定对象无能为力。以下三类必须提前人工干预，否则 DROP USER CASCADE 必然失败：
-
DBA_ROLE_PRIVS和DBA_SYS_PRIVS中残留的权限记录：用REVOKE CONNECT, RESOURCE, DBA FROM your_user清空；若提示 “role does not exist”，说明角色已被删但授权记录还在，需直接删数据字典（仅限紧急且懂风险时）：DELETE FROM sys.sysauth$ WHERE grantee# = (SELECT user_id FROM dba_users WHERE username = 'YOUR_USER')（需AS SYSDBA） - 物化视图日志（
MATERIALIZED VIEW LOG）：即使物化视图本身不在该用户下，只要日志属于该用户，就必须先DROP MATERIALIZED VIEW LOG ON other_schema.table_name - 外部表（
EXTERNAL TABLE）的目录对象依赖：检查dba_directories是否被该用户用CREATE TABLE ... ORGANIZATION EXTERNAL引用，若有，先DROP DIRECTORY或改权限
真·强行清理：绕过数据字典校验的底层操作
当所有常规手段失效（比如用户已损坏、dba_users 里显示存在但 SELECT * FROM your_user.tab 报错），只能走底层路径。这不是推荐操作，而是“只剩这招了”的兜底方案：
- 确保数据库处于
MOUNT状态（非 OPEN），启动时加RESTRICT：STARTUP MOUNT RESTRICT - 用
AS SYSDBA连接后，直接删数据字典记录：DELETE FROM sys.user$ WHERE name = 'YOUR_USER'；注意别漏掉DELETE FROM sys.user_astats$ WHERE user# = (SELECT user# FROM sys.user$ WHERE name = 'YOUR_USER') - 重建控制文件不是必须的，但建议立刻
ALTER DATABASE OPEN RESETLOGS后做一次全库 RMAN 备份——这类操作可能让字典不一致，后续 DDL 可能触发ORA-00600
这种操作在 12c+ 的多租户环境里风险更高：如果用户属于 PDB，必须在对应 PDB 内执行，且不能跨容器删 CDB$ROOT 中的残留条目。
清理后验证是否干净的三个检查点
别以为 DROP USER CASCADE 返回成功就完事了。Oracle 的延迟清理机制可能导致对象残留数小时（尤其在高并发或 AWR 快照期间）。必须立刻验证：
- 查
DBA_USERS：确认SELECT COUNT(*) FROM dba_users WHERE username = 'YOUR_USER'返回 0；若还有，说明删了一半，可能是user$和obj$不同步 - 查
DBA_OBJECTS：用SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE owner = 'YOUR_USER' GROUP BY owner, object_type—— 即使用户不存在，对象仍可能挂在字典里（尤其 TYPE、SYNONYM） - 查监听和 TNS：如果该用户曾配置过
tnsnames.ora别名或监听器静态注册，记得同步清理，否则下次建同名用户时连不上
最隐蔽的坑是审计策略（UNIFIED AUDIT POLICY）：如果该用户被显式加入过审计策略，删用户后策略不会自动剔除它，下次启用策略时会报 ORA-46372，得手动 ALTER AUDIT POLICY ... REMOVE USERS (YOUR_USER)。
