查看Oracle中特定角色被授予哪些用户

在 Oracle 数据库权限管理中，DBA_ROLE_PRIVS 视图是排查角色授权问题的核心工具。不过，很多开发者初次接触时都会遇到一些常见问题：查不到数据、报错或者搞不清字段含义。下面就来逐一拆解那些容易被忽略的细节，帮助您更顺畅地使用该视图。

查 DBA_ROLE_PRIVS 时角色名必须大写

直接执行 select * from dba_role_privs where granted_role = 'connect' 会返回空结果，原因很简单：Oracle 内部默认以大写形式存储角色名，写成小写自然匹配不上。正确写法是用 'CONNECT'（同理，'RESOURCE'、'DBA' 也是一样）。那什么时候可以用小写呢？只有当建角色时显式用了双引号，比如 create role "my_role"，查询时就要保持小写加单引号：where granted_role = 'my_role'。这个大小写问题容易忽略，很多人第一反应是去查表，结果折腾半天才发现是字母写法不对。

必须用有权限的账号执行，普通用户会报 ORA-00942

DBA_ROLE_PRIVS 是数据字典视图，普通用户默认没有访问权限。如果执行时出现 ORA-00942: table or view does not exist，别被误导——表其实存在，只是权限不够。解决方法是换一个具备 SELECT_CATALOG_ROLE 或 DBA 角色的账号（比如 SYSTEM、SYS）来连接。假如手里只有普通账号，也不是没办法：可以退一步查 USER_ROLE_PRIVS（只看自己被授予了哪些角色），或者查 SESSION_ROLES（只看当前会话已激活的角色）。记住，权限不足不等于查不了，只是能看到的范围有限。

GRANTEE 字段可能不是用户，而是角色或 PUBLIC

结果中 GRANTEE 列的值不一定都是用户名，这点容易被忽略：

• 它可能是另一个角色名（比如 'APP_ADMIN'），这就意味着角色存在嵌套授权，需要递归查询 DBA_ROLE_PRIVS 才能追踪到最终用户。
• 它也可能是 'PUBLIC'，代表所有用户自动获得该角色——这种授权风险较高，务必单独识别并评估。
• 只有当 ADMIN_OPTION = 'YES' 时，该 GRANTEE 才有权限把这个角色转授给其他人。
• DEFAULT_ROLE = 'YES' 表示用户登录后自动启用该角色；如果为 'NO'，即使角色已被授予，也需要手动执行 SET ROLE 才能实际使用权限。

这几个字段搭配起来，才能完整了解角色的可传播性、默认激活状态和实际生效范围。

刚授完角色却查不到？先确认事务和角色状态

执行 GRANT CONNECT TO scott 后，立刻查询 DBA_ROLE_PRIVS 却没结果，常见原因有三个：

• 授权语句是在 PL/SQL 块中执行的，但没有 COMMIT，数据字典不会刷新，授权并没有真正落盘。
• 当前会话未启用对应角色。比如用 SYSTEM 授权，但当前连接身份不是 SYSTEM 且没有启用其 DBA 角色，自然看不到新增记录。
• 目标用户 scott 的 DEFAULT_ROLE 是 'NO'，虽然角色已经授予，但尚未激活。这时连 SESSION_ROLES 里都看不到。

真正容易被忽略的是：权限生效不等于授权完成。角色是否可用，取决于 DEFAULT_ROLE 和当前会话状态，不是查到记录就等于能用。下次遇到查不到的情况，先别急着怀疑自己写错了 SQL，按上面三步排查一下，多半能定位问题。