编译报ORA-01031，根本原因是AUTHID DEFINER模式下Oracle在编译时校验定义者显式权限，角色权限无效；须对定义者显式授权或改用AUTHID CURRENT_USER并确保调用者角色已启用。
ORA-01031 在存储过程编译阶段报出，基本可以断定是权限校验失败——不是运行时缺权限，而是 Oracle 在编译时就卡住了。根本原因在于：默认 AUTHID DEFINER 模式下，Oracle 会检查定义者（即存储过程属主）是否拥有代码中所有对象的显式权限，角色权限（比如 DBA）完全不生效。
编译就报 ORA-01031，先确认是不是 AUTHID DEFINER 在作怪
Oracle 存储过程默认使用定义者权限（AUTHID DEFINER），它会在 编译时 就检查定义者用户是否具备代码里涉及的所有对象权限（如 SELECT、INSERT、CREATE TABLE 等）。哪怕你用的是 EXECUTE IMMEDIATE，只要语句里写了表名或系统对象，编译器照样要查权限。
- 如果过程里有
SELECT * FROM hr.employees，而定义者没被显式执行过GRANT SELECT ON hr.employees TO owner_user，编译直接失败 - 即使定义者有
DBA角色，也无效——角色权限在DEFINER模式下不参与编译期校验 -
CREATE SYNONYM、CREATE TABLE、ALTER SESSION等系统级操作，同样需要对应系统权限（如CREATE ANY TABLE），且必须直接授予用户，不能靠角色
动态 SQL（EXECUTE IMMEDIATE）报 ORA-01031 的典型场景
这类错误最常出现在含 EXECUTE IMMEDIATE 的过程里，尤其是创建/删改对象（表、索引、同义词等）或跨 schema 查询时：
-
EXECUTE IMMEDIATE 'CREATE TABLE t1 (id NUMBER)'→ 需要CREATE TABLE或CREATE ANY TABLE权限，且必须直接授予定义者 -
EXECUTE IMMEDIATE 'SELECT COUNT(*) FROM other_schema.tab'→ 定义者必须有SELECTonother_schema.tab，不能只靠角色 - 常见误判：你在 SQL*Plus 里能跑通这条 SQL，不代表过程能编译通过——因为会话里的角色权限对编译无效
解决路径只有两条：
- 给定义者用户显式授权（
GRANT CREATE ANY TABLE TO owner_user） - 或改用调用者权限：
AUTHID CURRENT_USER，把权限检查推迟到运行时（但注意：job 调用时仍可能失效）
为什么 SET ROLE 或 GRANT DBA 经常不管用
-
GRANT DBA TO user不带WITH ADMIN OPTION，无法转授；更重要的是，DBA 是角色，不是权限集合，在 PL/SQL 编译期不被识别 -
SET ROLE ALL只影响当前会话的运行时上下文，对编译过程零作用 - 外部认证（
IDENTIFIED EXTERNALLY）或 proxy 连接下，某些系统权限（如CREATE SESSION）可能压根没激活，需额外SET ROLE - 最隐蔽的坑：开发在 SQL*Plus 里测试没问题，但应用用 JDBC 连接时未指定
currentSchema或未启用角色，导致权限上下文不一致
验证真实权限是否生效，别只查 DBA_ROLE_PRIVS，要看：
-
SELECT * FROM SESSION_PRIVS（当前会话实际可用的系统权限） -
SELECT * FROM SESSION_ROLES（哪些角色已启用） -
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE = 'OWNER_USER'（显式授予的对象权限）
AUTHID CURRENT_USER 不是万能解药
加 AUTHID CURRENT_USER 能绕过编译期检查，把权限判断交给调用者，但有硬性前提：
- 调用者 session 中，所需角色必须已启用（
SESSION_ROLES里得有） - 调用者必须有对应对象权限或系统权限（不能仅靠角色间接获得，除非启用了
INHERIT PRIVILEGES，且 12c+ 才支持） - 如果过程被 job 调用（如
DBMS_SCHEDULER），job 默认以定义者身份运行，CURRENT_USER会退化为定义者权限模型，依然报ORA-01031
所以，简单加一行 AUTHID CURRENT_USER 后看似编译成功，上线后在定时任务里崩掉，非常常见。
真正稳定的方案，还是回到源头：对定义者用户做最小粒度的显式授权，比如：
GRANT SELECT ON hr.employees TO proc_ownerGRANT CREATE TABLE TO proc_ownerGRANT EXECUTE ON dbms_output TO proc_owner
编译报错时，盯住过程里第一处访问外部对象的语句，顺藤摸瓜补授权，比改模式更可控。
