查当前会话实际生效的系统权限应查询SESSION_PRIVS视图，它仅返回已激活的直接权限（不含未启用角色所含权限）；USER_SYS_PRIVS显示被直接授予的权限（含ADMIN OPTION），DBA_SYS_PRIVS需DBA权限且只记录显式授权；ROLE_SYS_PRIVS和USER_ROLE_PRIVS用于追溯角色继承的权限。
查当前用户有哪些系统权限
直接查 session_privs 视图，它只返回当前会话已激活的系统权限（不含角色间接授予的，除非该角色已被启用）。
常见错误是以为查了 DBA_SYS_PRIVS 就能知道“自己有没有”，但那是 DBA 视图，普通用户没权限访问；而 USER_SYS_PRIVS 查的是被直接授予的权限（含带 ADMIN OPTION 的），但不反映是否实际生效。
-
SELECT * FROM SESSION_PRIVS;—— 最贴近运行时真实权限 - 如果结果为空，不代表没授过权，可能是角色未启用或权限被回收
- 注意：
ALTER SESSION SET CURRENT_SCHEMA不影响SESSION_PRIVS输出
查某用户被直接授予的系统权限（含ADMIN OPTION）
用 DBA_SYS_PRIVS（需 DBA 权限）或 USER_SYS_PRIVS（仅查自己）。
关键区别在于：这两个视图只记录“显式授予”动作，不体现角色继承链。比如用户 A 有角色 R，R 有 CREATE TABLE，但 USER_SYS_PRIVS 里不会出现这条记录。
SELECT grantee, privilege, admin_option FROM DBA_SYS_PRIVS WHERE grantee = 'SCOTT';-
admin_option = 'YES'表示该用户可再转授此权限（不是所有权限都支持） - 普通用户执行
SELECT * FROM USER_SYS_PRIVS;只能看到自己被直接授予的权限，不含角色带来的
查角色包含哪些系统权限（用于追查隐式权限来源）
系统权限可能藏在角色里，必须连查 ROLE_SYS_PRIVS 和用户的角色授予关系（DBA_ROLE_PRIVS 或 USER_ROLE_PRIVS）才能串起来。
容易漏掉的一点：角色本身可能被授予其他角色（嵌套），但 ROLE_SYS_PRIVS 只展一层，不递归。真要完整分析得写递归查询或用 DBMS_METADATA.GET_GRANTED_DDL 辅助。
SELECT role, privilege FROM ROLE_SYS_PRIVS WHERE role IN ('CONNECT', 'RESOURCE');-
SELECT granted_role FROM USER_ROLE_PRIVS;先确认自己有哪些角色 - 注意：
DEFAULT ROLE设置会影响哪些角色在登录后自动启用，进而影响SESSION_PRIVS结果
为什么刚授的权限查不到？常见权限延迟场景
权限变更不是实时同步到所有会话的。最典型的是：用户已连接，你随后用 GRANT 授予新权限，但该用户旧会话里 SESSION_PRIVS 仍看不到——必须重新登录，或执行 SET ROLE ALL（如果涉及角色）。
- 对当前会话立即生效的操作只有：
SET ROLE、ALTER SESSION SET CURRENT_SCHEMA -
GRANT/REVOKE后，已有会话需重连或手动启用角色才更新SESSION_PRIVS - 如果用了 Oracle Wallet 或连接池，更要注意连接复用导致权限“滞后”
真正难排查的，往往是角色嵌套 + 默认角色开关 + 会话缓存三者叠加。别只盯着一个视图，得把 SESSION_PRIVS、USER_ROLE_PRIVS、ROLE_SYS_PRIVS 三者对照着看，否则很容易误判权限是否存在。
