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 或有 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 会漏掉 70% 以上的权限，因为 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不变 - 它不包含对象权限，也不管权限来源（直授 or 角色），只回答一个问题：“我现在敲
CREATE TABLE，会不会报错？” - 普通用户也能查，且比跨多视图关联快得多
真正难的不是查出权限列表，而是搞清某条权限到底从哪来——USER_SYS_PRIVS 和 SESSION_PRIVS 都不告诉你来源，必须靠 USER_ROLE_PRIVS 和 ROLE_SYS_PRIVS 手动溯源，这点最容易卡住排查节奏。
