历史废弃角色须同时满足：无用户/角色被授予、非对象所有者、未被PL/SQL以DEFINER模式调用；DROP前需逐项验证授权链、对象归属及会话激活状态，并清理PUBLIC隐式权限依赖，删后须检查失效对象与审计失败事件。
确认哪些角色属于“历史废弃角色”
不能只看角色名带 OLD、TEST 或年份就直接删——Oracle里角色可能被隐式依赖：比如某视图的 DEFINER 是该角色，或某存储过程用 AUTHID DEFINER 绑定它，甚至被其他角色通过 GRANT ... TO role_name 间接授予。真正废弃的角色必须同时满足：无用户被授予、无其他角色被授予、未作为对象所有者存在、不被任何 PL/SQL 单元以 definer 模式调用。
执行以下查询定位候选角色：
SELECT r.role
FROM dba_roles r
WHERE r.role NOT IN (
SELECT grantee FROM dba_role_privs WHERE grantee = r.role -- 自身没被其他角色授予（避免循环依赖）
UNION
SELECT grantee FROM dba_sys_privs WHERE grantee = r.role
UNION
SELECT grantee FROM dba_tab_privs WHERE grantee = r.role
)
AND r.role NOT IN (
SELECT owner FROM dba_objects WHERE object_type IN ('PACKAGE', 'PROCEDURE', 'FUNCTION', 'VIEW')
)
AND r.role NOT IN (
SELECT distinct owner FROM dba_source WHERE upper(text) LIKE '%AUTHID%DEFINER%'
);DROP ROLE 前必须检查依赖对象和权限链
DROP ROLE 不会级联清理依赖项，一旦误删，可能导致已有 PL/SQL 编译失败（PLS-00201: identifier must be declared）、视图失效（ORA-00942: table or view does not exist），甚至应用连接池初始化报错（因连接时预设了 SET ROLE）。
务必逐条验证以下几点：
- 运行
SELECT * FROM dba_role_privs WHERE granted_role = '<role_name>';确认没有用户或角色被显式授予该角色 - 运行
SELECT * FROM dba_tab_privs WHERE grantee = '<role_name>';确认该角色没被授予权限（即它不是“权限中转站”） - 运行
SELECT * FROM dba_objects WHERE owner = '<role_name>';确认该角色名下没有表、序列、同义词等对象（角色可作为对象所有者，虽少见但合法） - 对关键应用账号执行
SELECT * FROM session_roles;，确认当前会话未激活该角色（尤其在连接池 warm-up 阶段）
批量清理需绕过 PUBLIC 角色的隐式绑定风险
很多 DBA 忽略一个关键点：PUBLIC 是个特殊角色，所有用户默认拥有它。如果你曾执行过 GRANT EXECUTE ON utl_file TO PUBLIC;，而后来创建了一个叫 OLD_UTIL_ROLE 的角色并也授了 utl_file，那么即使没人用 OLD_UTIL_ROLE，它仍可能因与 PUBLIC 共享权限路径而被误判为“安全可删”。更危险的是，某些老版本 Oracle（如 11.2.0.3）在 DROP ROLE 后，若 PUBLIC 仍有同名权限，会导致 utl_file 权限残留但归属混乱，引发后续 ORA-01031: insufficient privileges。
稳妥做法是：先用 REVOKE execute ON utl_file FROM <role_name>; 清空其权限，再确认 dba_tab_privs 中无记录，最后再 DROP ROLE。不要依赖“没查到授权就等于没权限”——权限可能来自角色继承链末端，而非直接授予。
清理后必须验证数据字典一致性
DROP ROLE 是 DDL，立即生效且不可回滚。但它的副作用不会立刻暴露：比如某后台 job 定期执行 SET ROLE <role_name>，删完后首次运行才报错；或者某审计策略依赖该角色做条件过滤，删掉后审计日志漏记录。
建议在维护窗口内执行后，立刻运行：
SELECT owner, name, type, status
FROM dba_objects
WHERE status != 'VALID'
AND (owner, name) IN (
SELECT owner, name FROM dba_dependencies
WHERE referenced_owner = '<dropped_role>'
);如果返回结果，说明有已编译对象依赖该角色，需人工修复或重建。另外，检查 dba_audit_trail 中最近 1 小时是否有 ROLE 相关失败事件，比单纯查对象状态更能发现运行时问题。
