Oracle存储过程默认AUTHID DEFINER模式下忽略角色权限，需改用AUTHID CURRENT_USER并确保调用者会话启用对应角色，且对象名、权限类型、默认表空间等均需匹配。
GRANT给角色的权限在存储过程中为啥不生效
因为 oracle 默认在 authid definer 模式下编译存储过程时，**完全忽略角色权限**——哪怕你给用户授了 dba 角色，只要没显式 grant select on hr.employees to myuser，编译阶段就会报 ora-00942 或 ora-01031。
这不是授权漏了，是 Oracle 的权限模型设计如此：PL/SQL 单元运行时默认只认“直接授予用户”的对象权限和系统权限，角色带来的权限（包括 SELECT_CATALOG_ROLE、RESOURCE）在定义者权限模式下被主动屏蔽。
- 角色权限只在 SQL*Plus / JDBC 直连会话中生效，进了
CREATE OR REPLACE PROCEDURE就自动失效 -
GRANT DBA TO user本身没问题，但 DBA 是角色，它所含的权限无法穿透到存储过程内部 - 即使
SELECT * FROM SESSION_ROLES显示角色已启用，过程里查同义词或动态 SQL 仍会失败
怎么让角色权限在过程里真正起作用
必须显式声明 AUTHID CURRENT_USER，把权限校验从“编译时定义者”推迟到“运行时调用者”，并确保调用者当前会话的角色已激活。
关键不是改过程，而是改调用上下文：
- 过程体开头加
AUTHID CURRENT_USER，例如：CREATE OR REPLACE PROCEDURE p AUTHID CURRENT_USER IS BEGIN ... END; - 调用前执行
SET ROLE ALL或SET ROLE myrole IDENTIFIED BY pwd，让SESSION_ROLES非空 - 确认调用者确实拥有目标操作所需权限——比如过程里建表，调用者角色必须含
CREATE TABLE，不能只靠DBA角色间接包含 - 若用 JDBC 调用，需在连接后显式执行
SET ROLE，不能依赖连接字符串自动启用
ORA-00990 错误：混用系统权限和对象权限的 GRANT
当你写 GRANT CREATE TABLE, SELECT ON hr.employees TO myrole，Oracle 直接报 ORA-00990，不是权限不够，是语法非法——系统权限（如 CREATE TABLE）和对象权限（如 SELECT ON hr.employees）**不能放在同一条 GRANT 语句里**。
必须拆开：
GRANT CREATE TABLE TO myroleGRANT SELECT ON hr.employees TO myrole- 反过来，多个角色 + 一个系统权限可以合写：
GRANT myrole, CONNECT TO scott
这个限制常被忽略，尤其在脚本批量授权时，一报错就以为是权限没给全，其实只是语句格式错了。
最隐蔽的坑：调用者有权限，但过程仍失败
即便用了 AUTHID CURRENT_USER、角色也 SET ROLE 启用了、SESSION_ROLES 查出来也有，过程还是报 ORA-00942，大概率是这三点之一：
- 过程里查的是
scott.emp，但调用者只被授了SELECT ON hr.employees—— 对象名必须完全匹配 - 过程用
EXECUTE IMMEDIATE 'CREATE SYNONYM s FOR hr.employees'，但调用者角色没含CREATE SYNONYM权限（DBA角色默认不含） - 调用者用户没配默认表空间：
ALTER USER scott DEFAULT TABLESPACE users，导致CREATE TABLE因无默认空间而静默失败
权限问题从来不是单点故障，而是权限链上任意一环断掉都会失败。别只盯着 GRANT 语句，得一路查到 SESSION_ROLES 和实际执行对象的命名一致性。
