ORA-01922错误本质是用户下存在数据库对象，必须用CASCADE强制删除；常见阻塞点包括活跃会话、权限不足、索引依赖；回收站、同义词、内部依赖等易被忽略，需逐一清理。
ORA-01922 错误本质是对象存在，不是语法写错
ORA-01922: “CASCADE must be specified to drop ‘username’” 这个报错根本不是你拼错了命令，而是 Oracle 在明确告诉你：该用户下有至少一个数据库对象（哪怕只是一张空表、一个同义词、甚至回收站里一个被删掉的表），所以不能用裸 DROP USER username。它不关心你有没有权限、连没连上，只看对象是否存在。
常见误解是以为加了 CASCADE 就能绕过检查——其实不是。这个错误出现时，CASCADE 是强制要求，不是可选项。
- 用户刚建完、还没执行任何
CREATE→ 直接DROP USER username成功 - 用户执行过一次
CREATE TABLE t(x INT)→ 必须用DROP USER username CASCADE - 用户删过表但没清回收站 →
RECYCLEBIN里残留对象也算“存在”，仍需CASCADE
执行 DROP USER CASCADE 前必须解决的三个阻塞点
DROP USER ... CASCADE 不是银弹，Oracle 会卡在三个典型条件上并直接报错中断，而不是跳过：
-
ORA-01940: cannot drop a user that is currently connected→ 先查SELECT sid, serial# FROM v$session WHERE username = 'USERNAME'，再用ALTER SYSTEM KILL SESSION 'sid,serial#'干掉活跃会话；注意状态为KILLED才算生效，INACTIVE仍可能阻塞删除 -
ORA-01031: insufficient privileges→ 必须用SYS或SYSTEM登录（sqlplus / as sysdba），普通用户即使删自己也不行 -
ORA-02429: cannot drop index used for enforcement of unique/primary key→ 说明该用户下有主键或唯一约束依赖的手动创建索引；得先删约束（ALTER TABLE t DROP CONSTRAINT pk_t）或改用DROP TABLE t CASCADE CONSTRAINTS清理表
别信“删完就干净”，回收站和依赖关系常被忽略
很多人执行完 DROP USER username CASCADE 就以为万事大吉，结果后续建同名用户失败，或发现某些系统视图里还有残留记录。这是因为：
- 回收站（
RECYCLEBIN）里的对象不会被CASCADE自动清空，得手动跑PURGE USER username或PURGE DBA_RECYCLEBIN（需 DBA 权限） - 如果该用户被其他用户通过
CREATE SYNONYM引用过，那些同义词不会自动失效或删除，可能引发后续查询报ORA-00980: synonym translation is no longer valid - 角色授予（
GRANT role TO username）本身不阻止删除，但如果该角色又被GRANT给其他人，删除用户不会影响角色定义，但角色内含的对象权限若指向该用户 schema 下对象，就会变成悬空引用
批量删系统用户时，触发器和隐式依赖容易翻车
像 XDB、WMSYS、MDSYS 这类预置用户，直接 DROP USER ... CASCADE 很可能失败，因为它们被 Oracle 内部组件强依赖。例如：
-
XDB用户下默认启用XDB_PI_TRIG触发器，必须先禁用：ALTER TRIGGER SYS.XDB_PI_TRIG DISABLE - 某些版本中
XS$NULL是虚拟用户，不能删；OUTLN可能被优化器统计信息引用，删前需确认是否启用 outline 功能 - 12c+ 的 CDB 环境中，
C##开头的公共用户要区分CONTAINER=ALL还是CONTAINER=CURRENT，否则报ORA-65047类错误
真正麻烦的从来不是命令怎么写，而是删之前没看清它到底绑了多少东西——对象、会话、触发器、同义词、回收站、跨容器上下文，漏掉任意一环都可能让 CASCADE 卡住或留下隐患。
