ora-01918报错主因是dba_role_privs中残留授权记录，需先查清并逐条revoke；若角色已删则须以sys/system as sysdba直删sys.sysauth$，同步清理dba_sys_privs和dba_tab_privs，最后验证重建同名用户全流程成功。
ORA-01918 报错时，DBA_ROLE_PRIVS 里还有残留行
执行 DROP USER CASCADE 后再查 DBA_ROLE_PRIVS，发现 grantee = 'YOUR_USER' 的记录仍存在，这是最常见的残留源头。Oracle 不会自动清理这些授权元数据，尤其当角色本身已被删、但授权记录滞留时，后续重建同名用户会直接触发 ORA-01918: user 'xxx' does not exist——报错对象其实是这条“僵尸”授权行，不是用户本身。
验证方式很简单：
SELECT granted_role, admin_option FROM dba_role_privs WHERE grantee = 'YOUR_USER';
只要结果非空，就必须处理。常规做法是逐条 REVOKE，但若角色已不存在（比如 SELECT role FROM dba_roles WHERE role = 'XXX' 返回空），REVOKE 会失败，此时只能直操作数据字典：
- 必须以
SYS或SYSTEM身份连接，且带AS SYSDBA - 先备份：执行
CREATE TABLE sysauth_bak AS SELECT * FROM sys.sysauth$ WHERE grantee# = (SELECT user_id FROM dba_users WHERE username = 'YOUR_USER'); - 再删除：执行
DELETE FROM sys.sysauth$ WHERE grantee# = (SELECT user_id FROM dba_users WHERE username = 'YOUR_USER'); - 最后
COMMIT;，并确认DBA_ROLE_PRIVS中该用户记录清空
DBA_SYS_PRIVS 和 DBA_TAB_PRIVS 也得同步扫一遍
角色授权只是冰山一角。系统权限（如 CREATE TABLE）和对象级权限（如对某张表的 SELECT）同样可能残留，它们分别存于 DBA_SYS_PRIVS 和 DBA_TAB_PRIVS。不清理会导致新用户建同名时权限混乱，甚至影响审计日志准确性。
检查命令：
SELECT privilege, admin_option FROM dba_sys_privs WHERE grantee = 'YOUR_USER';<br>SELECT owner, table_name, privilege FROM dba_tab_privs WHERE grantee = 'YOUR_USER';
清理策略分两层：
- 对还能识别的角色/对象，用标准
REVOKE privilege FROM YOUR_USER;或REVOKE SELECT ON owner.table_name FROM YOUR_USER; - 对已不存在的
owner或失效的privilege字段值（比如owner是空字符串或INVALID），同样需进sys.sysauth$或sys.objauth$手动删对应行——注意objauth$中grantee#和obj#需联合匹配
别漏掉 PUBLIC 授予的权限
GRANT SELECT ON scott.emp TO PUBLIC; 这类语句不会在 DBA_ROLE_PRIVS 或 DBA_SYS_PRIVS 中体现，但它确实绑定在对象上。如果被删用户曾是某张表的 OWNER，而这张表又被 GRANT ... TO PUBLIC 过，那么即使用户没了，DBA_TAB_PRIVS 里 grantee = 'PUBLIC' 的行仍指向该用户拥有的对象——这不算“残留”，但会影响你判断“是否真清干净”。
真正要盯的是反向依赖：查这张表是否还在 DBA_OBJECTS 里，以及是否有其他用户通过同义词或视图间接依赖它。执行前跑一遍：
SELECT owner, object_name, object_type FROM dba_objects WHERE status != 'VALID' AND owner = 'YOUR_USER';
如果返回非空，说明有编译失败的对象残留（比如 PACKAGE BODY 引用了已被删的 TYPE），这类对象虽不显式出现在权限视图中，但会让 DROP USER CASCADE 下次执行时卡住。
清理后务必验证数据字典一致性
手动删 sysauth$ 或 objauth$ 后，不能只信 SELECT 结果为空就完事。Oracle 内部还有缓存和依赖链，最稳妥的验证方式是尝试重建同名用户：
- 执行
CREATE USER your_user IDENTIFIED BY pwd;—— 成功说明角色/权限层面无硬冲突 - 再执行
GRANT CONNECT TO your_user;—— 成功说明系统权限链完整 - 最后
DROP USER your_user CASCADE;—— 成功且无任何 ORA- 错误，基本可判定清理到位
真正容易被忽略的是：这些操作必须在数据库 open 状态下完成，且不能有其它会话正在查询 DBA_* 视图（尤其是 DBA_ROLE_PRIVS），否则可能因 dictionary cache 不一致导致误判。简单说，清理完别急着走，等 30 秒再验证。
