编译就报ORA-01031，大概率是AUTHID DEFINER模式在编译阶段校验定义者权限，要求过程属主被显式授予涉及对象的权限，角色权限无效；改用AUTHID CURRENT_USER需确保SESSION_ROLES非空且角色已激活并含所需权限。
编译就报 ORA-01031，大概率是 AUTHID DEFINER 在校验定义者权限
Oracle 存储过程默认用 AUTHID DEFINER，它在**编译阶段**就检查过程属主（即创建者）是否拥有 SQL 里涉及的所有对象权限。不是“你运行时有没有”，而是“写这个过程的人能不能过编译”。哪怕你在 SQL*Plus 里能执行 SELECT * FROM hr.employees，只要定义者没被显式授予 GRANT SELECT ON hr.employees TO proc_owner，编译直接失败。
常见误判点：
- 定义者有
DBA角色？没用。角色权限在DEFINER模式下完全不生效 - 定义者能手动跑那条 SQL？不等于能在过程里执行。交互式 SQL 走会话权限链，过程走静态校验
- 用同义词或视图包一层？不行。校验仍穿透到基表，权限要求不变
改用 AUTHID CURRENT_USER 后还是报错，先查 SESSION_ROLES 是否为空
AUTHID CURRENT_USER 把权限校验推迟到运行时，并允许使用调用者当前激活的角色权限——但它不会自动帮你启用角色。如果 SELECT * FROM SESSION_ROLES 返回空集，那再好的角色也没用。
必须确认三件事：
- 调用者用户确实被授予了对应角色（如
GRANT RESOURCE TO app_user） - 该角色已设为默认角色（
ALTER USER app_user DEFAULT ROLE ALL），或在会话中显式启用（SET ROLE resource） - 角色内真含所需权限：比如要建表，
RESOURCE可以；但要建 database link，就得额外加CREATE DATABASE LINK
EXECUTE IMMEDIATE 动态 SQL 报 ORA-01031，缺的是系统权限而非对象权限
像 EXECUTE IMMEDIATE 'CREATE TABLE t1(id NUMBER)' 这类语句，失败通常不是因为没访问某张表的权限，而是缺对应 DDL 的系统权限。例如：
- 建表 → 需要
CREATE TABLE（本 schema）或CREATE ANY TABLE（跨 schema） - 建索引 → 需要
CREATE ANY INDEX，不是CREATE INDEX - 删用户 → 需要
DROP ANY USER，不是ALTER USER
注意：CREATE ANY TABLE 是高危权限，仅限运维账号；应用账号应限定在本 schema 内操作，并确保已配 UNLIMITED TABLESPACE 或明确配额。
RMAN 或外部连接场景下，ORA-01031 和角色无关，只认密码文件
RMAN 连接目标库时报 ORA-01031，根本不是角色没授够，而是认证路径断了。它只读 $ORACLE_HOME/dbs/orapw$ORACLE_SID 文件，且只认里面预置的用户（通常是 SYS），不查数据字典里的角色。
关键检查点：
- 文件是否存在、命名是否严格匹配（
orapworcl≠orapwORCL≠PWDorcl.ora） -
SQLNET.AUTHENTICATION_SERVICES不能设为(NONE)，否则 RMAN 连不上；应删掉该行或设为(ALL) - 备库或辅助实例上，密码文件必须手动拷贝过去，且属主为
oracle:oinstall、权限为-rw-r-----
最易忽略的是：JDBC/cx_Oracle 连接后默认不启用任何角色，必须显式执行 SET ROLE ALL 或 SET ROLE role_name，否则哪怕 DBA 角色已授，也会在第一个 DDL 就卡住。
