session_roles 返回空的三个主因：非目标用户连接、default_role='no'未设默认角色、中间件复用旧连接；它反映实时启用角色，而user_role_privs仅显示静态授权记录。

直接查 session_roles 就行，但结果为空不等于没角色

执行 select * from session_roles 是唯一能拿到当前会话**实际启用角色**的途径。它不看授权记录，只反映此刻权限生效状态。但常见现象是：明明刚执行了 grant connect to app_user，再查却返回空行——这不是语句错了，而是角色还没“活”起来。

为什么 SESSION_ROLES 返回空？三个最常踩的坑

• 你不是以目标用户连接的：比如用 SYS AS SYSDBA 登录后查，看到的是 SYS 的会话角色，不是 app_user 的。必须退出，重新用目标用户账号连接
• DEFAULT_ROLE = 'NO'：即使角色已授予，若未设为默认，Oracle 不会在登录时自动启用。查 USER_ROLE_PRIVS 看 DEFAULT_ROLE 字段，是 'NO' 就得手动执行 SET ROLE role_name
• 中间件复用旧连接：Tomcat 或 WebLogic 连接池可能还在用授予权限前的老会话，SESSION_ROLES 不会自动刷新。重启连接池或强制新建连接才能生效

SESSION_ROLES 和 USER_ROLE_PRIVS 别混用

这两个视图回答的问题完全不同：

• USER_ROLE_PRIVS 回答：“谁给我授了哪些角色？”——是静态授权快照，含 DEFAULT_ROLE 和 ADMIN_OPTION
• SESSION_ROLES 回答：“我现在能用哪些角色？”——是动态运行时状态，包含默认启用的、SET ROLE 手动激活的、以及通过已激活角色继承来的所有角色
• 如果某角色在 USER_ROLE_PRIVS 里有，但 SESSION_ROLES 里没有，基本可断定它没被激活

嵌套角色继承时，SESSION_ROLES 是唯一可信依据

假设你只被授予了角色 A，而 A 被授予了 B，B 又被授予了 C，那么：

Agent Git Oracle

高级仓库分析与重构指南。基于AI推理识别技术债务与架构反模式。

下载

• DBA_ROLE_PRIVS 里只有一条：grantee=你的用户名，granted_role='A'
• SESSION_ROLES 却可能同时列出 A、B、C——只要 A 已激活，且其继承链完整
• 想验证某条权限（如 CREATE TABLE）是否真可用，必须先查 SESSION_PRIVS，再结合 SESSION_ROLES 追溯来源，不能靠拼 DBA_ROLE_PRIVS + ROLE_SYS_PRIVS 推理

真正麻烦的从来不是“怎么查”，而是查完发现角色 A 授予了 B，B 又被 C 继承，C 还带 WITH ADMIN OPTION……这种嵌套关系下，SESSION_ROLES 是唯一反映真实运行态的视图，其他全是快照。