ora-01031 根本原因是权限校验时机与上下文不匹配：authid definer 模式下编译时校验定义者显式权限（角色无效），而 authid current_user 将校验推迟至运行时并支持调用者已启用的角色权限，但需确保 session_roles 非空且上下文允许角色继承。
ORA-01031 在存储过程中报出，基本不是账号密码问题，而是权限模型和执行上下文不匹配——尤其集中在 EXECUTE IMMEDIATE 执行 DDL 或跨 schema 访问对象时。
为什么加 AUTHID CURRENT_USER 就能过编译？
Oracle 存储过程默认是 AUTHID DEFINER：编译时就检查**定义者（即过程属主）** 是否拥有底层对象权限，角色权限（如 DBA、SELECT_CATALOG_ROLE）完全不生效。哪怕定义者能手动执行 CREATE TABLE，只要没被显式授予 CREATE ANY TABLE，编译直接失败。
加上 AUTHID CURRENT_USER 后，权限校验推迟到运行时，并允许使用**调用者当前激活的角色权限**——但注意：它不会自动帮你启用角色。
- 调用者必须已通过
SET ROLE ALL或SET ROLE role_name激活对应角色 - 检查是否生效：
SELECT * FROM SESSION_ROLES必须返回非空结果 - 若从 JDBC / Python 连接调用，需确认连接字符串未禁用角色（如未设
disableOob=true）
GRANT CREATE ANY TABLE 等系统权限要直接授给用户
角色里的系统权限（比如 DBA 角色包含 CREATE ANY TABLE）在 AUTHID DEFINER 模式下无效；即使改成 CURRENT_USER，某些场景（如 DBMS_SCHEDULER JOB）仍可能因会话上下文丢失角色而失效。
最稳的方式是绕过角色，显式授权：
GRANT CREATE ANY TABLE TO your_user;GRANT DROP ANY TABLE TO your_user;-
GRANT SELECT ANY DICTIONARY TO your_user;（如果查DBA_*视图） -
GRANT EXECUTE ON SYS.DBMS_MVIEW TO your_user;（如果调用DBMS_MVIEW.REFRESH）
注意：ANY 类权限粒度粗，生产环境应尽量用更细的替代方案（如 CREATE TABLE + 表空间配额），但调试阶段它最直给。
动态 SQL 访问其他用户的表或视图，光有角色不够
例如过程里写 EXECUTE IMMEDIATE 'SELECT * FROM hr.employees';，即使调用者有 SELECT_CATALOG_ROLE，仍可能报 ORA-01031——因为该角色不包含对 hr.employees 的具体对象权限。
必须由 hr 用户（或具备 GRANT ANY OBJECT PRIVILEGE 的管理员）显式授权：
GRANT SELECT ON hr.employees TO your_user;- 如果是同义词或视图，权限要落在基表上，而非同义词名本身
- 若基表在另一 schema 且含函数/序列引用，这些依赖对象也得一并授权
最容易被忽略的坑：权限检查链断在第三环
很多人只查了 DBA_ROLE_PRIVS 和 DBA_SYS_PRIVS，就以为“权限给了”。但 Oracle 实际生效权限取决于三步叠加：
- 角色是否在当前会话中
ENABLED（SELECT * FROM SESSION_ROLES） - 启用的角色是否真包含所需权限（
ROLE_SYS_PRIVS查角色自带权限） - 运行时上下文是否支持角色继承（如 JOB、外部程序、proxy user 场景常默认禁用角色）
尤其是应用服务器连接 Oracle 时，默认不会启用角色——你本地 SQL*Plus 测通了，上线就挂，大概率卡在这儿。
