USER_SYS_PRIVS 用于查询当前用户的系统权限，DBA_SYS_PRIVS 可查询其他用户的权限但需要 DBA 权限；SESSION_PRIVS 显示当前会话的实时权限；若要查询角色权限，需递归查询 DBA_ROLE_PRIVS 和 ROLE_SYS_PRIVS。

user_sys_privs 可用于查询当前用户自身的系统权限，而 dba_sys_privs 则用于查询其他用户的权限——但前提是您必须拥有 DBA 权限。普通账号执行此语句会直接报错 ora-00942: table or view does not exist，因此不要盲目尝试。请先确认自己是否具备查询他人权限的资格。

查询当前登录用户的全部系统权限（推荐使用USER_SYS_PRIVS）

这是最顺手、最不容易出错的起点，不需要额外权限，结果里已经包含了直授和角色继承来的、已经生效的权限：

• 直接执行 SELECT PRIVILEGE FROM USER_SYS_PRIVS; 即可，其他字段参考价值有限。例如，ADMIN_OPTION 在 Oracle 11g 中恒为 NO，基本不可信赖；COMMON 在单机数据库中始终为 NO，完全可以忽略。
• 查询不到 CREATE SESSION？这完全正常——该权限是在连接时隐式授予的，不会出现在任何系统权限视图中。只要您能连接到数据库，它就默认存在。
• 有一个需要注意的陷阱：如果刚刚执行过 SET ROLE resource;，USER_SYS_PRIVS 不会立即更新。它反映的是授权快照，而非当前会话的实时状态。

查询指定用户被直接授予的系统权限（必须使用DBA_SYS_PRIVS）

想查询某个用户（比如 SCOTT）到底被 GRANT 过哪些权限，就得走 DBA_SYS_PRIVS。前提条件是你得是 DBA 或者拥有 SELECT_CATALOG_ROLE：

• SELECT privilege, admin_option FROM DBA_SYS_PRIVS WHERE grantee = 'SCOTT'; ——注意用户名必须大写，使用小写 'scott' 将查询不到结果。
• 如果查询不到 CREATE TABLE？很可能该权限来自 RESOURCE 角色，而 DBA_SYS_PRIVS 只记录直接授予的权限，不会展开角色内容。
• 看到 ADMIN_OPTION = 'YES' 表示该用户可以使用 WITH ADMIN OPTION 继续转授权限给其他用户，但这并不代表当前会话已经激活了该权限。

补全角色带来的系统权限（联合查询DBA_ROLE_PRIVS和ROLE_SYS_PRIVS）

只靠 DBA_SYS_PRIVS 会漏掉七成以上的权限——因为 Oracle 主要靠角色来分发权限：

• 首先查询用户拥有哪些角色：SELECT granted_role FROM DBA_ROLE_PRIVS WHERE grantee = 'SCOTT';
• 然后针对每个角色查询其授予的系统权限：SELECT privilege FROM ROLE_SYS_PRIVS WHERE role = 'RESOURCE';
• ROLE_SYS_PRIVS 本身不递归：如果 APP_ADMIN 角色又包含了 SELECT_CATALOG_ROLE，后者的权限不会自动出现在结果中，需要手动再查询一层。
• 在生产环境进行权限审计时，必须递归展开整个角色链；日常排查或开发环境中，查询到两到三层通常就足够了。

验证当前会话实际可用的权限（使用SESSION_PRIVS）

当你怀疑权限没生效、角色没启用、或者刚切换过角色，SESSION_PRIVS 是唯一能告诉你“此刻真正能干什么”的视图：

• SELECT * FROM SESSION_PRIVS; ——结构最为简单，只有 PRIVILEGE 一列，没有干扰字段。
• 执行 SET ROLE ALL; 后它会立即刷新，而 USER_SYS_PRIVS 不会发生变化。
• 它不包含对象权限，也不关心权限来源（直接授予还是角色），只回答一个问题：“我现在执行 CREATE TABLE，究竟会不会报错？”
• 普通用户也能查询，并且比跨多个视图关联查询要快得多。

实际上，最困难的部分并非查询权限列表，而是弄清楚某条权限究竟来源于何处。USER_SYS_PRIVS 和 SESSION_PRIVS 都不会告诉你权限来源，必须借助 USER_ROLE_PRIVS 和 ROLE_SYS_PRIVS 手动追溯——这一点最容易阻碍排查进度。