应优先查询 USER_SYS_PRIVS 获取当前用户实际生效的系统权限，包括直接授予和角色继承的权限；若需验证会话中已激活的权限，则用 SESSION_PRIVS，它更轻量且实时反映 SET ROLE 后的状态。
直接查 USER_SYS_PRIVS 就够了，别碰 DBA_SYS_PRIVS
普通开发账号没权限访问 dba_sys_privs，一执行就报 ora-00942: table or view does not exist。而 user_sys_privs 是每个登录用户都能查的视图，返回当前会话「实际生效」的系统权限——包括直接授予的，也包括通过角色继承来的（比如你被授了 resource 角色，create table 就会出现在结果里）。
注意：USER_SYS_PRIVS 的 ADMIN_OPTION 列在 Oracle 11g 中恒为 NO，不可信；COMMON 列在单机库中始终是 NO，这两列基本可以忽略。真正有用的只有 PRIVILEGE 字段。
执行这条语句即可：
SELECT PRIVILEGE FROM USER_SYS_PRIVS;
SESSION_PRIVS 更轻量，适合验证“此刻到底能干啥”
如果你刚执行过 SET ROLE 切换角色，或怀疑某些权限因角色未激活而没生效，SESSION_PRIVS 比 USER_SYS_PRIVS 更可靠——它只返回当前会话已激活、可立即使用的系统权限，不包含被 REVOKE 后未重连的残留项，查询也更快。
它结构更干净：只有 PRIVILEGE 一列，没有 ADMIN_OPTION 或 COMMON 干扰。
执行：
SELECT * FROM SESSION_PRIVS;
常见现象：如果刚用 SET ROLE resource; 激活了 RESOURCE 角色，SESSION_PRIVS 立刻多出 CREATE SEQUENCE 等权限，而 USER_SYS_PRIVS 不变。
查不到 CREATE SESSION？正常，它不显式授权
CREATE SESSION 是连接数据库时隐式授予的权限，不会出现在 USER_SYS_PRIVS 或 SESSION_PRIVS 中。哪怕你只被授予了 CONNECT 角色，也能连库，但查这两个视图都看不到 CREATE SESSION。
所以：查不到 ≠ 没权限。只要能成功 conn user/pass，说明该权限已生效。
其他类似隐式权限还有 ALTER SESSION 等，都不上系统权限视图。
想搞清某权限从哪来？得组合查三张视图
USER_SYS_PRIVS 只告诉你“有啥”，不告诉你“怎么来的”。如果看到一个权限但不确定来源（比如 UNLIMITED TABLESPACE 是直授的，还是某个角色带的），必须补查：
- 先看当前有哪些角色：
SELECT GRANTED_ROLE FROM USER_ROLE_PRIVS; - 再对每个角色查其含有的系统权限：
SELECT PRIVILEGE FROM ROLE_SYS_PRIVS WHERE ROLE = 'RESOURCE'; - 如果发现是直授的（不在任何角色里），那就只能去问 DBA 或翻授权记录了
典型组合如 CONNECT + RESOURCE，加起来共约 15 项系统权限，但 USER_SYS_PRIVS 不会标注哪条来自哪个角色——这点最容易被忽略，导致权限溯源卡住。
