角色权限在存储过程中默认不生效，因Oracle默认AUTHID DEFINER模式强制编译时仅校验定义者显式权限，完全忽略角色权限；改用AUTHID CURRENT_USER可启用调用者激活的角色权限，但需确保SESSION_ROLES非空且角色含所需权限。
角色权限在存储过程中默认不生效
Oracle 在存储过程（包括 procedure、function、package）中默认禁用角色权限，这是硬性安全机制，不是 bug 或配置遗漏。哪怕用户已启用某个含 SELECT 权限的角色，在 AUTHID DEFINER（默认模式）下编译或执行时，该角色权限完全不可见 —— 系统只认直接授予用户的对象权限或系统权限。
为什么 AUTHID DEFINER 模式下角色无效
定义者权限模式要求所有依赖对象（如表、视图、序列）的访问权限必须在编译时就“静态可验证”。角色是运行时动态激活的集合，无法满足这一确定性检查要求。所以即使 DBA 角色包含 CREATE ANY TABLE，只要没显式执行 GRANT CREATE ANY TABLE TO user_name，存储过程里用 EXECUTE IMMEDIATE 'CREATE TABLE ...' 就必然报 ORA-01031。
- 编译阶段会扫描过程体中所有 SQL 引用的对象，逐个校验定义者是否拥有显式权限
- 角色权限不会被纳入这个校验链，哪怕
SESSION_ROLES显示角色已启用 - 这种设计防止权限绕过：不能靠“先 SET ROLE 再调过程”来临时提权
AUTHID CURRENT_USER 能让角色生效吗
可以，但仅限运行时，且有严格前提：
- 必须在创建时显式声明
AUTHID CURRENT_USER，例如：CREATE OR REPLACE PROCEDURE p1 AUTHID CURRENT_USER AS ... - 调用者会话中该角色必须已启用（
SELECT * FROM SESSION_ROLES中状态为ENABLED） - 角色内所含权限必须覆盖过程内部所有操作（比如角色含
SELECT权限，但过程里还有INSERT，就会在第 2 行失败） - 跨 schema 访问仍需确保角色权限作用于目标对象，例如角色含
SELECT ON hr.employees，而非泛泛的SELECT_CATALOG_ROLE
最常被忽略的验证点
很多人查了 DBA_ROLE_PRIVS 看到角色已授，就以为万事大吉。真正要确认的是运行时上下文：
-
SELECT * FROM SESSION_ROLES—— 看角色是否ENABLED，不是GRANTED -
SELECT * FROM SESSION_PRIVS—— 这里列出的才是当前会话**实际可用**的系统权限（不含角色间接带来的） - 如果是 JDBC / cx_Oracle 连接，默认不启用任何角色，得在连接后显式执行
SET ROLE ALL或指定角色
动态 SQL（EXECUTE IMMEDIATE）尤其危险：它不继承定义者权限链，也不自动带调用者角色，除非明确用了 AUTHID CURRENT_USER 且角色已启用。
