oracle存储过程中角色权限默认不生效，因默认采用authid definer模式，pl/sql运行时完全忽略角色授予的权限，即使dba角色已分配且session_roles中显示启用，也仅显式授予用户的系统或对象权限有效。
Oracle存储过程中角色权限默认不生效
因为 Oracle 默认采用 AUTHID DEFINER（定义者权限）模式，此时 PL/SQL 运行时**完全忽略通过角色授予的任何权限**——哪怕 DBA_ROLE_PRIVS 显示你有 DBA 角色，SESSION_ROLES 里也列出了该角色，只要没显式启用或不在运行上下文中激活，就对存储过程无效。
为什么直接执行 SQL 没问题，进存储过程就报 ORA-00942 或 ORA-01031
直接在 SQL*Plus 或 JDBC 中执行 CREATE TABLE 或 SELECT FROM other_schema.table 时，会话处于“交互式上下文”，角色若已启用（比如登录后自动激活了 CONNECT、RESOURCE），权限就可用；但一进存储过程，Oracle 就切换到“定义者安全模型”，只认显式授予用户的系统权限（如 CREATE TABLE）或对象权限（如 SELECT ON hr.employees），角色带来的权限被主动屏蔽。
- 典型现象：用户
fym有DBA角色，能直接SELECT * FROM hyj.students，但存储过程中EXECUTE IMMEDIATE 'SELECT * FROM hyj.students'报ORA-00942 - 根本原因不是“没权限”，而是“权限存在但不可见”——
SESSION_PRIVS里查不到SELECT ANY TABLE，SESSION_ROLES虽有DBA却未被 PL/SQL 引擎采纳 - 即使你在连接后手动执行过
SET ROLE ALL，对后续编译/调用的存储过程也无影响，因为权限检查发生在编译期（DEFINER 模式）或运行期（INVOKER 模式），而非连接初始化阶段
怎么让存储过程用上角色权限
两种路径，选其一即可，但逻辑完全不同：
- 改用调用者权限：
CREATE OR REPLACE PROCEDURE p AUTHID CURRENT_USER IS ...。此时权限检查推迟到运行时，且以调用者身份进行，SESSION_ROLES和SESSION_PRIVS的实时状态生效。但前提是调用者自己已启用对应角色（比如 JDBC 连接后必须先SET ROLE ALL） - 不改存储过程，直接授予权限：
GRANT CREATE ANY TABLE TO your_user或GRANT SELECT ON hyj.students TO your_user。这是最稳妥的做法，绕过角色机制，权限写死在用户上，DEFINER 模式下天然可用 - 注意：如果用
AUTHID CURRENT_USER+ 动态 SQL 访问跨 schema 表，仍需确保调用者拥有对应对象权限（不能仅靠角色），否则运行时报错
最容易被忽略的配套条件
光解决“能不能建表”或“能不能查表”还不够，下面这些常被跳过，却直接导致失败：
-
CREATE SESSION缺失：OS 认证用户（sqlplus / as sysdba）或某些 JDBC 驱动可能不自动激活基础连接权限，需确认SESSION_PRIVS包含此项 - 表空间配额未设：
CREATE TABLE成功的前提是用户在目标表空间有配额，UNLIMITED TABLESPACE或ALTER USER ... QUOTA 10M ON users必须到位 - JDBC/cx_Oracle 不自动
SET ROLE：应用连上来默认SESSION_ROLES为空，必须在建立连接后立即执行SET ROLE ALL（或指定角色名），且驱动要支持（ojdbc8+ 通常 OK，老版本需验证） - 密码保护的角色：若
DBA角色设置了密码，SET ROLE ALL会失败，必须写成SET ROLE DBA IDENTIFIED BY "xxx"
真正卡住人的，从来不是“没给权限”，而是“给了，但没出现在 SESSION_PRIVS 里”——每次遇到 ORA-01031 或 ORA-00942，第一件事永远是登录目标会话，跑两行：SELECT * FROM SESSION_PRIVS 和 SELECT * FROM SESSION_ROLES。其他所有操作，都该在这之后展开。
