删除角色需同时满足drop any role系统权限和对目标角色拥有with admin option授权，缺一不可；执行drop role后角色立即消失，但活跃会话仍可使用，新会话无法启用该角色。
删除角色前必须确认的权限条件
执行 DROP ROLE 不是只要有 DBA 身份就行，而是需要两个独立权限同时满足：DROP ANY ROLE 系统权限 + 对该角色拥有 WITH ADMIN OPTION 授权。缺一不可。
常见错误现象是报错 ORA-01031: insufficient privileges，此时不是权限没给全，而是只给了其中一个。比如 DBA 用户用 GRANT role1 TO user1; 授予角色，但没加 WITH ADMIN OPTION，那 user1 就无法删掉 role1，哪怕他有 DROP ANY ROLE 也不行。
- 查当前用户是否具备
DROP ANY ROLE：SELECT * FROM session_privs WHERE privilege = 'DROP ANY ROLE'; - 查是否对目标角色有
WITH ADMIN OPTION：SELECT * FROM dba_role_privs WHERE grantee = USER AND granted_role = 'ROLE_NAME' AND admin_option = 'YES'; - 注意：
dba_role_privs中的admin_option字段值为YES才算有效，NO或空值都不行
DELETE ROLE 实际执行与即时影响
DROP ROLE role_name; 成功执行后，角色立即从数据字典中消失，所有已授予该角色的用户/角色记录都会被清除——但不会中断任何活跃会话。
关键点在于“会话隔离”：正在使用该角色的用户，只要没断开连接，仍能继续执行依赖该角色的语句；但新登录的会话将完全无法启用该角色（SET ROLE 会失败），也无法再被授予该角色。
- 示例：
DROP ROLE app_developer;后，已连着的dev_user仍可建表（如果app_developer原含CREATE TABLE），但新开会话执行SET ROLE app_developer;会报ORA-01921: role name conflicts with another user or role name - 不建议在业务高峰期执行，尤其当多个应用账号共用同一角色时，后续新建连接会直接失败，而非静默降级
- 删除后无法回滚，没有类似
FLASHBACK DROP ROLE的机制
评估权限影响的三个必查维度
角色不是孤立存在，它可能嵌套授权、间接控制对象访问、甚至被其他角色依赖。盲目删除会导致权限链断裂，但 Oracle 不会主动提示这些隐式依赖。
真正影响往往藏在三类关系里：
-
谁被授了这个角色？ 查：
SELECT grantee, granted_role, admin_option FROM dba_role_privs WHERE granted_role = 'ROLE_NAME'; -
这个角色本身有哪些权限？ 分两部分查：
系统权限：SELECT privilege, admin_option FROM role_sys_privs WHERE role = 'ROLE_NAME';
对象权限：SELECT owner, table_name, privilege FROM role_tab_privs WHERE role = 'ROLE_NAME'; -
有没有其他角色依赖它？ 查嵌套关系：
SELECT granted_role FROM dba_role_privs WHERE grantee = 'ROLE_NAME';—— 如果结果非空，说明该角色是其他角色的“上游”，删它等于切断下游权限来源
删除后残留权限的典型陷阱
角色删了，但用户可能还保留着原来通过该角色间接获得的权限，尤其是那些被显式授予过、或通过其他路径继承来的权限。这会造成权限状态不一致，容易误判安全边界。
最典型的遗漏场景是：某个用户既被直接授予了 SELECT ON scott.emp，又被授予了含该权限的角色 app_reader；删掉 app_reader 后，SELECT ON scott.emp 依然存在，但管理员可能以为已全部回收。
- 验证用户真实权限，别只看角色：
SELECT * FROM dba_tab_privs WHERE grantee = 'USER_NAME';和SELECT * FROM dba_sys_privs WHERE grantee = 'USER_NAME'; - 特别注意
WITH GRANT OPTION链路：如果角色曾被授予某对象权限并带WITH GRANT OPTION，接收方可能已把权限转授出去，删角色不影响这些二级授权 - Oracle 不自动清理“孤儿权限”，一切靠人工核对——这也是为什么生产环境删角色前，必须导出
dba_role_privs、role_sys_privs、role_tab_privs三张表快照留痕
