DBA_SYS_PRIVS查不全用户全部系统权限，因其仅记录直接授予的权限，不包含通过角色继承的权限；需联合DBA_ROLE_PRIVS和ROLE_SYS_PRIVS展开角色链，并与直接权限去重合并。
查指定用户的所有系统权限（含角色继承）
直接查 DBA_SYS_PRIVS 只能拿到该用户被「显式授予」的系统权限，漏掉通过角色（如 RESOURCE、CONNECT）间接获得的权限。真正完整的权限列表必须把角色链展开。
- 需要 DBA 权限才能执行；普通用户只能查自己（用
USER_SYS_PRIVS+ 角色展开逻辑） - 核心思路是：先查该用户被授了哪些角色 → 再查每个角色带哪些系统权限 → 和直接授予的权限去重合并
- 注意
UNLIMITED TABLESPACE这类权限不能通过角色授予，只可能直接授予，所以必须包含DBA_SYS_PRIVS的直接部分
示例 SQL（查用户 SCOTT 的全部系统权限）：
SELECT DISTINCT privilege FROM ( -- 直接授予的系统权限 SELECT privilege FROM dba_sys_privs WHERE grantee = 'SCOTT' UNION ALL -- 角色继承的系统权限（递归展开角色嵌套需额外处理；此写法仅支持单层角色） SELECT rp.privilege FROM dba_role_privs drp JOIN role_sys_privs rp ON drp.granted_role = rp.role WHERE drp.grantee = 'SCOTT' ) ORDER BY privilege;
为什么 DBA_SYS_PRIVS 查不全？
因为 Oracle 的权限模型里，角色是“权限容器”，而 DBA_SYS_PRIVS 只记录 GRANTEE 是具体用户名或角色名的直接授权记录，不反映“角色 A → 角色 B → 系统权限”的传递链。比如：
-
SCOTT被授予角色MY_DEVELOPER_ROLE -
MY_DEVELOPER_ROLE又被授予了CREATE PROCEDURE - 这条
CREATE PROCEDURE不会出现在DBA_SYS_PRIVS中grantee = 'SCOTT'的行里
所以只靠 DBA_SYS_PRIVS WHERE grantee = 'SCOTT' 会漏掉至少一半常用权限，尤其是开发类用户基本都靠角色授权。
查当前用户全部系统权限（无需 DBA 权限）
普通用户登录后，可以用 USER_SYS_PRIVS 查直接权限，再结合 USER_ROLE_PRIVS 和 ROLE_SYS_PRIVS 拼出完整视图：
-
SELECT privilege FROM user_sys_privs：当前用户直授系统权限 -
SELECT granted_role FROM user_role_privs：当前用户拥有的角色 -
SELECT privilege FROM role_sys_privs WHERE role IN (…)：这些角色各自带的系统权限 - 注意：
ROLE_SYS_PRIVS对所有用户可见，不需要特殊权限
常见错误：把 user_tab_privs 或 dba_tab_privs 当成系统权限来源 —— 它们只管对象权限（如 SELECT ON HR.EMPLOYEES），和 CREATE TABLE 这类系统权限完全无关。
容易忽略的权限细节
有些系统权限行为特殊，查出来也不代表能直接用：
-
SELECT ANY DICTIONARY：允许查数据字典，但默认不包含V$动态性能视图，得额外授权SELECT_CATALOG_ROLE或显式赋权 -
UNLIMITED TABLESPACE：只在DBA_SYS_PRIVS中出现，不会出现在任何角色的ROLE_SYS_PRIVS里 -
ADMIN OPTION字段决定能否转授，但DBA_SYS_PRIVS里为'NO'时，不代表权限本身无效，只是不能继续授权给别人
实际排查权限问题时，别只盯着“有没有”，更要核对“能不能用”——比如连不上数据库，优先确认 CREATE SESSION 是否真的生效，而不是只看到它出现在查询结果里。
