authid definer 容易导致权限失败，因其要求定义者必须被显式授予目标对象的 object privilege 或 system privilege，角色权限无效；ora-00942 或 ora-01031 错误即由此引发。
直接给结论：用 authid definer 不能解决“权限不足”，反而常是问题根源——它会让过程以定义者身份执行，但定义者若没被显式授予对应权限（尤其是对象权限），照样报 ora-01031 或 ora-00942。
为什么 AUTHID DEFINER 容易导致权限失败
默认就是 AUTHID DEFINER，但它不自动继承角色权限，也不跨 schema 生效。比如 userA 创建了过程，过程里要查 userB.emp，哪怕 userA 有 SELECT ANY TABLE 角色，只要没被 GRANT SELECT ON userB.emp TO userA，运行就崩。
- 错误现象：
ORA-00942: table or view does not exist（查不到表）或ORA-01031: insufficient privileges（没操作权） - 根本原因：定义者（owner）缺少对目标对象的显式
object privilege，或没被授予必要的system privilege（如CREATE TABLE） - 角色权限（
CONNECT、RESOURCE、自定义 role）在DEFINER模式下完全无效 - 即使定义者是
DBA角色成员，也必须显式GRANT才能在过程里用
显式授权给定义者才是正解
如果坚持用 AUTHID DEFINER（比如封装核心逻辑、避免调用者越权），就必须把所有依赖权限直接授给过程属主用户。
- 查其他用户的表：
GRANT SELECT ON other_user.table_name TO owner_user; - 创建表/序列等：
GRANT CREATE TABLE, CREATE SEQUENCE TO owner_user; - 删/改其他用户的对象：
GRANT DROP ANY TABLE, UPDATE ANY TABLE TO owner_user;（慎用，“ANY”类权限应严格限制） - 注意：这些
GRANT必须由对象属主（如other_user）执行，或由具备GRANT ANY OBJECT PRIVILEGE的 DBA 执行
AUTHID CURRENT_USER 不是万能解药
改成 AUTHID CURRENT_USER 确实能让过程使用调用者的角色权限，但前提是调用者当前会话已启用该角色，且角色里真包含所需权限。
- 检查是否启用：
SELECT * FROM SESSION_ROLES;—— 如果列表为空，说明角色没激活 - 激活角色：
SET ROLE role_name;（需提前ALTER USER ... DEFAULT ROLE或显式SET） - 角色里权限必须匹配：比如想建表，
RESOURCE角色含CREATE TABLE，但不含CREATE DATABASE LINK - 跨 schema 操作仍受限：调用者有
SELECT ANY TABLE可行；但只有SELECT ON hr.employees就只能查 hr 下这张表
最容易被忽略的三个点
很多问题卡在这儿，不是权限没给，而是没给对地方：
- 默认表空间没配：
ALTER USER username DEFAULT TABLESPACE users;+QUOTA UNLIMITED ON users;，否则CREATE TABLE直接失败 - 密码文件权限错（
AS SYSDBA报ORA-01031）：orapw$ORACLE_SID文件需属主oracle、权限640 - PDB 场景下权限未单独授予：
ALTER SESSION SET CONTAINER = pdb_name;后，必须在该 PDB 内重新GRANT
