Oracle 11g中用角色构建三层权限模型完全可行，但须规避存储过程中角色失效、默认角色未激活、循环授权三类硬性限制，否则执行时报ORA-00942或ORA-01031；角色权限在PL/SQL中不生效，关键系统权限必须直接授予用户。
直接给结论：oracle 11g里用角色构建三层权限模型（系统 + 对象 + 角色嵌套）完全可行，但必须绕开存储过程中的角色失效、默认角色未激活、循环授权这三类硬性限制，否则权限看似授了，实际执行时就报 ora-00942 或 ora-01031。
角色不能自动在存储过程中生效
这是最常踩的坑——用户明明被授予了含 SELECT ANY DICTIONARY 的角色，但在自己写的存储过程中查 v$session 却报权限不足。Oracle 在编译/运行 PL/SQL 时会剥离所有通过角色获得的权限，只保留直接授予用户的系统权限和对象权限。
- 必须显式把关键系统权限（如
SELECT ANY DICTIONARY、EXECUTE ANY PROCEDURE）直接授予用户，而非仅靠角色 - 若需保持权限集中管理，可用脚本定期检查并补全：
SELECT grantee, privilege FROM dba_sys_privs WHERE grantee = 'MYUSER' AND privilege LIKE '%ANY%'; - 开发阶段建议用
SET ROLE ALL在 SQL*Plus 中临时激活角色，验证对象访问是否通，但这对存储过程无效
Default Role 控制权限的实际可见性
角色不是授了就“一直在线”。用户登录后，只有被设为 DEFAULT 的角色才自动启用；非默认角色需手动 SET ROLE role_name 才能生效。很多权限问题其实只是角色没激活，而非没授予。
- 查看当前用户的默认角色：
SELECT granted_role, default_role FROM dba_role_privs WHERE grantee = 'MYUSER'; - 把角色设为默认：
ALTER USER myuser DEFAULT ROLE ALL;或精确指定：ALTER USER myuser DEFAULT ROLE r_app_read, r_app_write; - 禁用某角色默认行为：
ALTER USER myuser DEFAULT ROLE NONE;，适合需要按需切换权限的运维账号
避免角色嵌套导致的循环授权失败
Oracle 明确禁止角色 A 授予 B、B 又授予 A 这类闭环。一旦触发 ORA-01934，整个授权链会中断，且不会回滚已执行的部分，容易留下不一致状态。
- 建模阶段就画清角色依赖图，禁止双向引用；例如
r_hr_manager可包含r_hr_staff，但后者绝不可反向包含前者 - 检查现有循环：
SELECT * FROM role_role_privs CONNECT BY PRIOR granted_role = grantee START WITH grantee IN (SELECT role FROM dba_roles); - 清理冗余授权时，优先用
REVOKE r_x FROM r_y而非删角色，避免影响其他用户
真正难的不是建角色，而是让角色在各种上下文（连接会话、存储过程、动态SQL、DBMS_SCHEDULER 任务）里稳定起效。尤其当涉及 DBMS_LOB、数据泵或跨 schema 查询时，权限链上任意一环缺了直接授予的权限，就会静默失败——这时候看日志比猜配置更管用。
