ora-01918报错本质是权限元数据残留导致用户主体与dba_role_privs/dba_sys_privs记录不一致；需先查并清理grantee='old_user'的残留权限行，再执行revoke。
ORA-01918 错误不是因为“用户不存在”，而是权限元数据残留导致的清理中断
REVOKE 报 ORA-01918 的真实触发点
执行 REVOKE 时 Oracle 并不校验目标用户是否在线或存在，而是去查 DBA_ROLE_PRIVS 和 DBA_SYS_PRIVS 这两张数据字典表。如果用户已被 DROP USER CASCADE 中断、或手动删过但没清权限记录，这些表里仍存有 grantee = 'OLD_USER' 的行——此时 REVOKE 就会报 ORA-01918: user 'OLD_USER' does not exist，本质是权限元数据和用户主体状态不一致。
为什么 DROP USER CASCADE 之后还会留权限记录
常见原因包括：
-
DROP USER CASCADE执行中途被中断（比如遇到ORA-00054表锁、ORA-02429索引绑定），只删了部分对象，权限行没来得及清理 - 用户曾被授予角色（如
CONNECT、RESOURCE），而这些角色本身又被其他用户授予过，Oracle 权限链清理逻辑会跳过“间接持有”的残留行 - DBA 直接用
DROP USER（无CASCADE）删用户，系统不会自动清理其已授出的权限，只删用户本身
如何安全清理残留权限再执行 REVOKE
不要直接重试 REVOKE，先验证并清除元数据：
- 查残留：运行
SELECT granted_role FROM dba_role_privs WHERE grantee = 'OLD_USER';和SELECT privilege FROM dba_sys_privs WHERE grantee = 'OLD_USER'; - 逐条清理：对每个结果执行
REVOKE <role_or_priv> FROM OLD_USER;</role_or_priv>—— 即使报ORA-01918，只要语句语法正确，Oracle 仍会尝试清理字典行 - 终极兜底：若仍失败，用
DELETE FROM dba_role_privs WHERE grantee = 'OLD_USER';（需AS SYSDBA）——注意这不是标准操作，仅限确认无其他依赖时使用
容易被忽略的关键点
权限残留常和跨 schema 依赖、物化视图日志、TYPE 引用混在一起；单独处理 REVOKE 很可能反复失败。真正要做的不是“怎么让 REVOKE 成功”，而是先跑一遍完整的清理检查清单：活跃会话、DBA_DEPENDENCIES、约束绑定索引、权限字典表——漏掉任意一项，都可能导致后续所有 DDL 操作卡在元数据不一致状态。
