如何查询当前会话权限_SESSION_PRIVS与SESSION_ROLES视图

SESSION_PRIVS显示当前会话实际生效的系统权限（含角色继承），SESSION_ROLES显示当前已启用的角色；二者均反映运行时真实状态，而非静态授予关系。查当前用户能干啥：直接看 SESSION_PRIVS这个视图返回的是你此刻实际拥有的所有系统权限——不是“被授予过”，而是“现在生效”的权限集合，包括直接授给用户的、以及通过角色（哪怕嵌套多层）间接继承来的。它不区分来源，只反映真实能力。执行 SELECT * FROM SESSION_PRIVS; 就行，结果只有 PRIVILEGE 一列，比如 CREATE TABLE、SELECT ANY DICTIONARY注意：它不显示对象权限（如对某张表的 UPDATE），只管系统级动作常见误判点：有人查 USER_SYS_PRIVS 发现没看到 CREATE SESSION，就以为没登录权限——其实它可能来自 CONNECT 角色，而 SESSION_PRIVS 里一定有查当前激活了哪些角色：SESSION_ROLES 是唯一答案SESSION_ROLES 显示的是当前会话中“已启用”的角色。Oracle 允许用户被授予多个角色，但默认只激活 DEFAULT 角色；非默认角色需显式 SET ROLE 才生效。这个视图只告诉你“此刻起作用的角色”。执行 SELECT * FROM SESSION_ROLES;，结果只有 ROLE 列如果某角色在 USER_ROLE_PRIVS 里存在但不在 SESSION_ROLES 中，说明它没被激活（可能是非默认角色，或被 SET ROLE NONE 关闭了）别用 DBA_ROLE_PRIVS 或 USER_ROLE_PRIVS 替代——它们只表示“授予关系”，不反映运行时状态为什么 SESSION_PRIVS 和 USER_SYS_PRIVS 结果不同？根本区别在于“是否包含角色继承”。USER_SYS_PRIVS 只列出**直接授予该用户**的系统权限（不含任何角色带来的）；而 SESSION_PRIVS 是最终叠加效果，是运行时真实权限集。例如：用户 U1 被直接授了 CREATE SESSION，又被授了角色 RESOURCE（含 CREATE TABLE）→ USER_SYS_PRIVS 只有前者，SESSION_PRIVS 同时包含两者性能影响几乎为零，但逻辑混淆很常见：DBA 查权限时若只看 USER_SYS_PRIVS，会严重低估用户实际能力想追溯某权限来源？得组合查：SESSION_PRIVS 找权限 → ROLE_SYS_PRIVS 看哪个角色带它 → USER_ROLE_PRIVS 确认用户是否拥有该角色连带常踩的坑：权限查全了，但存储过程还是报错？因为 SESSION_PRIVS 和 SESSION_ROLES 只反映**调用者会话**的权限，而存储过程默认以定义者（DEFINER）身份执行——它的权限取决于**过程所有者**的权限，不是你的。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。