ora-01934是oracle内核级安全机制，禁止角色间循环授权；需用dba_role_privs视图及递归查询定位环路，修复应drop重建角色并遵循单向依赖原则，同时补足系统权限直接授予。
ora-01934：循环授权被oracle明确禁止
oracle在执行grant role_a to role_b时，会实时检测角色依赖图。一旦发现a→b→…→a这类闭环路径，立即报ora-01934: circular role grant detected，并中断当前语句——不会回滚前面已成功的授权，容易留下权限不一致状态。
这个限制与角色是否含实际权限无关，哪怕三个空角色互相授予也会触发。它不是bug，而是Oracle内核级安全设计，无法绕过或禁用。
怎么快速定位已存在的循环链
不能靠人工翻查，得用Oracle自带的依赖视图。重点查DBA_ROLE_PRIVS和递归查询结果：
- 先看直接授予关系：
SELECT granted_role, grantee FROM dba_role_privs WHERE grantee IN ('ROLE_A', 'ROLE_B', 'ROLE_C'); - 再跑递归SQL（需有
SELECT_CATALOG_ROLE）：SELECT LEVEL, granted_role, grantee FROM dba_role_privs START WITH grantee = 'ROLE_A' CONNECT BY PRIOR granted_role = grantee;
若结果中重复出现同一角色，说明存在环
修复时别直接REVOKE，优先用DROP ROLE重置
手动REVOKE容易漏掉中间环节，且不保证顺序正确。更稳妥的做法是：
- 停用所有相关角色：
ALTER USER ... DEFAULT ROLE NONE; - 逐个
DROP ROLE再重建（确保新角色不含反向依赖） - 重建时严格遵循“单向包含”原则：只允许
ROLE_APP_READ → ROLE_CORE_SELECT，绝不允许ROLE_CORE_SELECT → ROLE_APP_READ - 用脚本批量验证：
SELECT * FROM dba_role_privs WHERE grantee = 'ROLE_CORE_SELECT' AND granted_role = 'ROLE_APP_READ';结果应为空
真正难的是跨上下文权限稳定生效
循环授权只是表层报错，背后常连着更隐蔽的问题：比如角色设为DEFAULT后，在PL/SQL里仍查不到v$session，其实是SELECT ANY DICTIONARY没直接授给用户。Oracle对存储过程、DBMS_SCHEDULER任务、动态SQL都剥离角色权限——这时候光修循环没用，得补上关键系统权限的直接授予。
