ORA-00942或ORA-01031报错主因是AUTHID DEFINER模式下编译时校验定义者权限，而非运行时；需显式授权且角色权限无效，改用AUTHID CURRENT_USER须确保SESSION_ROLES非空、角色已激活并含所需权限。
编译就报 ORA-00942 或 ORA-01031，大概率是 AUTHID DEFINER 模式在作祟
oracle 存储过程默认用 authid definer，它会在编译阶段就检查定义者（即过程属主）是否拥有底层对象权限——不是“运行时有没有”，而是“写的时候能不能过”。哪怕你只是写了 select * from hr.employees，只要定义者没被显式执行过 grant select on hr.employees to owner_user，编译直接失败。
常见误判点：
- 定义者有
DBA角色？没用。角色权限在DEFINER模式下完全不生效 - 定义者能手动执行那条 SQL？不等于能在过程里执行。交互式 SQL 走的是会话权限链，过程走的是静态权限校验
- 用
SYNONYM或VIEW包一层？不行。校验仍穿透到基表，权限要求不变
改用 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
动态 SQL 中若涉及跨 schema 对象（如 EXECUTE IMMEDIATE 'INSERT INTO scott.emp ...'），调用者还得有 INSERT ON scott.emp 或 INSERT ANY TABLE，光有 RESOURCE 不够。
显式授权给定义者时，注意对象权限和系统权限的边界
坚持用 AUTHID DEFINER（比如封装核心 DDL、避免调用者越权）没问题，但必须把所有依赖权限直接授给过程属主，且由正确的人执行授权。
关键操作清单：
- 查其他用户的表：
GRANT SELECT ON other_user.table_name TO owner_user（必须由other_user或 DBA 执行） - 建/删/改任意对象：
GRANT CREATE ANY TABLE, DROP ANY TABLE TO owner_user（慎用，“ANY”类权限应严格限制） - 执行 DDL（如
CREATE TABLE）：GRANT CREATE TABLE TO owner_user，不能靠RESOURCE角色替代 - 缺默认表空间也会导致 CREATE 失败：
ALTER USER owner_user DEFAULT TABLESPACE users
最容易被忽略的三个硬性前提
很多问题卡住，不是权限没给，而是没给对地方、没配对环境：
-
SESSION_ROLES为空 → 角色没激活，AUTHID CURRENT_USER形同虚设 - 调用者只有
SELECT ON hr.employees，但过程里查的是scott.emp→ 权限不匹配，照样ORA-00942 - 定义者用户没配默认表空间，
CREATE TABLE语句即使权限全，也会因无法分配段而失败
别急着加 DBA 角色或开 ANY 权限，先确认这三项是否成立——它们比“授什么权”更常成为实际拦路虎。
