查角色被授予的用户应使用dba_role_privs视图并指定granted_role大写值，注意大小写敏感、权限不足、未提交事务及双引号角色等常见问题；嵌套授权需递归查询，权限实效还需结合default_role和admin_option判断。
查角色被授给了哪些用户：用 dba_role_privs 过滤 granted_role
直接执行 select * from dba_role_privs where granted_role = 'connect' 就能列出所有被授予 connect 角色的用户（或其它角色）。注意角色名必须大写，'connect' 查不到结果——oracle 默认以大写存储角色名，除非建角色时用了双引号强制小写。
常见错误现象包括：返回空结果但你知道确实授过了；或者查出一堆重复记录。前者大概率是大小写/引号不匹配，后者常因未加 WHERE 条件导致全表扫描（DBA_ROLE_PRIVS 在大型库中可能有上万行）。
-
GRANTEE字段值可能是用户名（如'SCOTT'）、角色名（如'APP_ADMIN'），也可能是'PUBLIC'——需单独警惕，它代表所有用户自动获得该角色 -
ADMIN_OPTION = 'YES'表示该用户可把此角色再授予别人，不是“自己能用”，而是“能当权限分发者” -
DEFAULT_ROLE = 'YES'表示登录后自动启用，否则需手动SET ROLE才生效，权限才实际可用
为什么查不到刚授权的用户？先盯住三件事
执行完 GRANT CONNECT TO scott; 立即查 DBA_ROLE_PRIVS 却没出现，不是语句错，而是事务或权限链没到位：
- 没
COMMIT：如果在 PL/SQL 块里执行的GRANT，忘了提交，数据字典视图不会刷新 - 当前用户无权查
DBA_ROLE_PRIVS：普通用户执行会报ORA-00942，不是“表不存在”，而是权限遮蔽行为；应确认已拥有SELECT_CATALOG_ROLE或DBA角色且已启用 - 角色名带双引号：如
CREATE ROLE "my_role"，查询时必须写成WHERE GRANTED_ROLE = 'my_role'（保留小写+单引号），不能大写也不能去引号
DBA_ROLE_PRIVS 和 USER_ROLE_PRIVS 别混用
DBA_ROLE_PRIVS 是全局视角，能看到整个库的角色分配关系，但需要高权限；USER_ROLE_PRIVS 是当前用户视角，只返回“我自己被授予了哪些角色”，无需特殊权限，任何用户都能跑 SELECT * FROM USER_ROLE_PRIVS。
如果你只是想确认自己有没有某个角色，别硬上 DBA_ROLE_PRIVS——既可能没权限，又容易看花眼。而查别人（比如审计账号 HR 是否被授了 DBA 角色），就必须用 DBA_ROLE_PRIVS，且确保你当前连接具备对应权限。
-
USER_ROLE_PRIVS不显示ADMIN_OPTION和DEFAULT_ROLE字段，这两个关键控制项只有DBA_ROLE_PRIVS提供 - 即使你有
SELECT_CATALOG_ROLE，也得确认它处于启用状态：SELECT * FROM SESSION_ROLES能看到当前激活的角色列表，比单纯查授权记录更贴近真实权限状态
嵌套授权下，单查 DBA_ROLE_PRIVS 不够用
角色可以互相授予，比如 APP_ADMIN 被授给了 CONNECT，而 CONNECT 又被授给了 SCOTT。这时只查 DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'APP_ADMIN'，只会看到直接接收者，看不到 SCOTT——因为中间隔了一层。
要理清这种链路，得递归查：先找出谁拿了 APP_ADMIN，再查这些人又被授了哪些角色，一层层往下追。Oracle 没有内置函数做这事，必须手动写多层 JOIN 或用 WITH RECURSIVE（12c+ 支持）。
- 生产环境审计时，漏掉嵌套层级等于低估权限范围；特别是
ADMIN_OPTION = 'YES'的中间角色，可能已悄悄扩散权限 -
DBA_ROLE_PRIVS本身不包含权限内容，它只管“谁给了谁”。真要看APP_ADMIN实际能干啥，还得接查ROLE_SYS_PRIVS和DBA_TAB_PRIVS WHERE GRANTEE = 'APP_ADMIN'
真正麻烦的从来不是“怎么查”，而是查完发现一条授权路径里夹着 DEFAULT_ROLE = 'NO'、ADMIN_OPTION = 'YES' 和双引号小写角色——这些细节不逐个核对，结果就不可信。
