查DBA_ROLE_PRIVS时角色名必须大写，小写如'connect'查不到结果，正确应为'CONNECT'；需用SYSTEM/SYS等高权限账号执行，普通用户会报ORA-00942；GRANTEE可能是用户、角色或PUBLIC，ADMIN_OPTION和DEFAULT_ROLE字段分别控制转授权与自动启用。
查 DBA_ROLE_PRIVS 时角色名必须大写
直接执行 select * from dba_role_privs where granted_role = 'connect' 会返回空——因为 oracle 内部默认以大写存储角色名，'connect' 不匹配任何记录。正确写法是用 '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 块中执行的
GRANT，但没COMMIT，数据字典不会刷新 - 当前会话未启用对应角色（比如你用
SYSTEM授了权，但当前连接身份不是SYSTEM且没启用其DBA角色） - 目标用户
scott的DEFAULT_ROLE是'NO'，虽已授角色，但尚未激活，SESSION_ROLES里也看不到
DEFAULT_ROLE 和当前会话状态，不是查到记录就等于能用。 
