SESSION_ROLES仅显示当前会话已激活的角色，不体现角色继承或层级关系；Oracle角色为扁平化授予，无父子结构，继承关系需通过DBA_ROLE_PRIVS递归查询。
直接结论：session_roles 只显示当前已激活的角色，不反映角色继承关系；set role 用于手动切换激活角色，但无法查询“层次结构”——oracle 本身不维护角色的树状层级，只支持扁平化授予。
为什么 SESSION_ROLES 查不到角色嵌套或继承链
Oracle 角色之间没有父子层级概念，所谓“角色 A 包含角色 B”在数据字典中并不存在显式记录。角色只是权限容器，SESSION_ROLES 只返回当前会话中 已启用 的角色名（即通过 SET ROLE 显式激活、或默认自动激活的那些），不体现任何包含关系。
常见错误现象：
执行 SELECT * FROM SESSION_ROLES; 后只看到几个角色名，却找不到“这个角色是从哪个角色继承来的”线索——因为根本不存在这种字段或视图。
-
SESSION_ROLES是会话级视图，依赖当前SET ROLE状态，重启连接或未执行SET ROLE可能为空 - 即使角色 A 被授予了角色 B，
SESSION_ROLES里也只会列出 A 和 B（如果都激活），不会标注“A → B” - 真正体现“授予关系”的是
DBA_ROLE_PRIVS，但它只存GRANTEE（被授者）和GRANTED_ROLE（被授角色），不区分是否激活
SET ROLE 的实际作用与限制
SET ROLE 不是查询命令，而是控制会话权限边界的语句。它决定哪些已授予你的角色会在当前会话中生效，从而影响 SESSION_ROLES 的输出内容。
使用场景：
当一个用户被授予多个角色，但某些角色含高危权限（如 DBA），生产环境常要求默认不激活，仅在必要时用 SET ROLE 临时启用。
- 激活单个角色：
SET ROLE role_name; - 激活多个角色：
SET ROLE role1, role2; - 禁用所有角色（退回最小权限）：
SET ROLE NONE; - 若角色带密码，必须写：
SET ROLE role_name IDENTIFIED BY pwd;
注意：SET ROLE 不改变授予事实，只改变当前会话视角；且对 DEFAULT ROLE 无效（默认角色在连接时自动激活，除非显式 ALTER USER ... DEFAULT ROLE NONE）。
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
想查“谁给了谁什么角色”，该看 DBA_ROLE_PRIVS 而非 SESSION_ROLES
要还原角色分配路径（比如排查某权限从哪来），必须查授予源头，而不是当前会话状态。
例如查用户 APP_USER 被哪些角色覆盖：
SELECT GRANTED_ROLE, ADMIN_OPTION, DEFAULT_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'APP_USER';
再进一步查这些角色本身又被谁授予（递归起点）：
SELECT GRANTEE, GRANTED_ROLE
FROM DBA_ROLE_PRIVS
WHERE GRANTED_ROLE IN ('APP_DEVELOPER', 'READ_ONLY_ROLE');
-
ADMIN_OPTION = 'YES'表示该用户可继续把此角色授予他人，这是权限扩散的关键点 -
DEFAULT_ROLE = 'YES'表示连接时自动激活，否则需SET ROLE手动启用 - Oracle 不支持跨角色的“继承权限合并分析”，比如角色 A 有 SELECT，角色 B 有 INSERT，不能靠视图直接看出“用户最终有 SELECT+INSERT”——得靠
SESSION_PRIVS或实际执行验证
真正容易被忽略的是：角色权限生效依赖两层开关——授予（DBA_ROLE_PRIVS 记录） + 激活（SESSION_ROLES 反映）。只查一边，永远拼不全权限图谱。
