Oracle查询用户系统权限方法

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 手动追溯——这一点最容易阻碍排查进度。