编译时报权限不足，根本原因是AUTHID DEFINER模式强制编译时校验定义者显式权限，角色权限无效；改用AUTHID CURRENT_USER可推迟至运行时校验调用者激活的角色权限，但需确保SESSION_ROLES非空且角色含所需权限。
编译时报权限不足，基本不是权限没给，而是权限模型用错了。 Oracle 默认用 AUTHID DEFINER，它会让编译器在创建过程时就检查定义者（owner）是否拥有底层对象权限——哪怕你只是写个 SELECT * FROM other_user.t，只要 owner 没被显式授予 SELECT ON other_user.t，编译就直接失败，报 ORA-00942 或 ORA-01031。
为什么 AUTHID DEFINER 会导致编译失败
DEFINER 模式下，角色权限（比如 DBA、RESOURCE）完全不生效，连 CREATE TABLE 这种系统权限都必须直接授给 owner 用户。常见现象：
- 用户有
DBA角色，但CREATE OR REPLACE PROCEDURE p AS BEGIN EXECUTE IMMEDIATE 'CREATE TABLE t1(id INT)'; END;编译不过 - 过程里查
hr.employees，owner 用户没被GRANT SELECT ON hr.employees TO owner，编译就报ORA-00942 - 即使 owner 是 DBA，只要没显式授权，编译阶段就卡死——不等运行
AUTHID CURRENT_USER 怎么绕过编译检查
AUTHID CURRENT_USER 把权限校验推迟到运行时，并且允许使用调用者当前会话激活的角色权限。关键点：
- 编译时只检查语法和对象名是否存在，不校验底层表/操作权限
- 运行时才去查调用者的
SESSION_ROLES，只要该角色含CREATE TABLE或SELECT ANY TABLE，就能过 - 必须确保调用者已激活对应角色：
SELECT * FROM SESSION_ROLES;返回非空才行 - 示例：
CREATE OR REPLACE PROCEDURE p_create AUTHID CURRENT_USER IS BEGIN EXECUTE IMMEDIATE 'CREATE TABLE tmp(x INT)'; END;
哪些权限在 CURRENT_USER 模式下依然不行
不是所有权限都能靠 AUTHID CURRENT_USER 解决。容易忽略的硬限制：
- 调用者只有
SELECT ON hr.employees，但过程里查的是scott.emp→ 权限不匹配，仍报ORA-00942 - 调用者角色里没包含所需权限：比如角色只有
CREATE TABLE，但过程要建 synonym → 缺CREATE SYNONYM - 动态 SQL 中的 DDL 涉及跨 schema 对象，而调用者没被授
CREATE ANY TABLE或对应对象权限 - 默认表空间未配：
ALTER USER username DEFAULT TABLESPACE users;否则CREATE TABLE可能因无默认空间报错
最常卡住的地方，是以为加了 AUTHID CURRENT_USER 就万事大吉，却忘了调用者角色没激活、或角色本身缺权限、或目标对象根本不在其访问范围内。
