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）身份执行——它的权限取决于**过程所有者**的权限，不是你的。
- 如果你执行一个
A.PKG_PROC报ORA-01031: insufficient privileges，先确认A用户是否有对应权限，而不是查你自己的SESSION_PRIVS - 要让过程按调用者权限跑，必须显式声明
AUTHID CURRENT_USER - 触发器同理：即使你有
UPDATE权限，触发器内部访问其他表时，用的是表所有者的权限上下文，不是你的
权限不是静态快照，而是由会话状态、角色激活、定义者/调用者模式共同决定的动态集合。漏掉其中任一环，查出来的结果就只是半截真相。
