Oracle在PL/SQL中默认忽略角色权限，属设计行为而非bug；需查SESSION_PRIVS确认明文授予的系统权限是否真实存在，若缺失则须直授（如GRANT CREATE TABLE TO user），而非依赖角色。
PL/SQL里角色权限为啥直接“消失”了
Oracle在PL/SQL执行时默认忽略角色权限，这不是bug，是设计行为。哪怕SESSION_ROLES里显示你有DBA角色，只要没显式授予系统权限（如CREATE TABLE），存储过程一运行就报ORA-01031或ORA-20000。
怎么确认当前会话真有权限
别信dba_role_privs，要看实时生效的权限快照：
- 查
SESSION_PRIVS：它只列明文授予的系统权限，不包含角色带来的权限 - 查
SESSION_ROLES：确认角色是否已激活（比如JDBC连接后默认为空） - 如果
SESSION_PRIVS里没有CREATE TABLE，但SESSION_ROLES里有DBA，说明权限靠角色给的——那在PL/SQL里就不可用
AUTHID CURRENT_USER能绕过这限制吗
可以，但不是万能解药：
- 加
AUTHID CURRENT_USER后，过程以调用者身份运行，角色权限重新生效 - 前提是调用者已启用对应角色（比如执行过
SET ROLE ALL或连接时自动激活） - 动态SQL（如
EXECUTE IMMEDIATE）仍受限于调用者权限上下文，不能跨schema访问未授权对象 - 依赖的底层对象（如
hr.employees）仍需对调用者显式授SELECT，否则报ORA-00942或ORA-01031
真正该优先检查的三件事
遇到PL/SQL权限失败，先做这三步，比反复授角色快得多：
- 在出错会话里立刻跑
SELECT * FROM SESSION_PRIVS;，看关键权限是否存在 - 用
SELECT referenced_owner, referenced_name FROM all_dependencies WHERE name = 'YOUR_PROC' AND owner = 'OWNER_NAME';顺藤摸瓜，查过程里所有外部引用对象 - 对每个依赖对象（表、视图、函数、包），确认是否已对目标用户直授对应权限（
GRANT SELECT ON hr.emp TO user;），而不是只授角色
最容易被跳过的其实是依赖链中间环节——比如包所有者有SELECT权，但没带WITH GRANT OPTION，导致无法让下游用户通过包间接访问。这种断点不会出现在编译期检查里，只在运行时报错。
