AUTHID DEFINER下角色权限不生效，因存储过程仅使用定义者显式权限，不继承角色权限；跨schema对象调用需对完整对象名显式授权，同义词和JOB调度均不改变此规则。
AUTHID DEFINER 下角色权限不生效
Oracle 存储过程默认以 AUTHID DEFINER 方式运行，这意味着它用定义者（即创建者）的身份执行，但**只使用定义者显式拥有的权限，不继承任何通过角色授予的权限**。哪怕用户被授予了 DBA 角色，只要过程里访问的表、视图或其它用户的存储过程没被显式授权，编译或运行时就会报 PLS-00201 或 ORA-00942。
常见错误现象：
- 用户能连库、能查自己表、有
DBA角色，但一编译含跨 schema 引用的存储过程就失败 - 手动
EXEC hr.get_emp_info成功，但放进 JOB 或另一个存储过程里调就报错 - 用同义词调用，仍提示找不到对象——因为权限检查落在原对象上，而角色没生效
根本原因不是“没权限”，而是权限路径断了：角色 → 用户 → 存储过程（DEFINER 模式）这条链在过程内部被截断。
GRANT EXECUTE 必须指向完整 schema 对象名
给存储过程授执行权，不能省略 schema。Oracle 不做隐式解析，GRANT EXECUTE ON get_employee_info TO scott 会直接报 ORA-00942，因为数据库根本找不到不带 owner 的对象。
正确做法：
GRANT EXECUTE ON hr.get_employee_info TO scott;- 如果过程名建时用了双引号且含大小写（如
"Get_Employee_Info"），授权也必须严格匹配：GRANT EXECUTE ON hr."Get_Employee_Info" TO scott; - 包内过程不能单独授权：
GRANT EXECUTE ON hr.emp_pkg.get_dept_info TO scott是语法错误；必须授整个包：GRANT EXECUTE ON hr.emp_pkg TO scott;
注意：授权语句本身不校验对象是否存在——哪怕 hr.get_employee_info 根本不存在，GRANT 也能成功；但后续调用必报错。
同义词调用不改变权限检查逻辑
用户建了同义词 CREATE SYNONYM my_proc FOR hr.proc_a，调用 EXEC my_proc 时，Oracle 先解析出真实对象是 hr.proc_a，再检查当前用户对 hr.proc_a 是否有 EXECUTE 权限。
所以：
- 必须对原对象授权：
GRANT EXECUTE ON hr.proc_a TO scott; - 给同义词所在 schema（比如
hr）授EXECUTE权限无效，因为同义词本身没有独立的EXECUTE权限类型 - 即使同义词在当前用户 schema 下，权限检查仍回溯到原对象 owner 和对象名
DBMS_SCHEDULER 或 DBMS_JOB 调用时权限上下文更严格
JOB 或 Scheduler 任务是在独立后台会话中运行的，它不会继承你的当前会话环境，也不会激活角色。哪怕你手动 EXEC 成功，JOB 仍可能失败。
关键点：
- 确保存储过程中所有引用的对象（表、序列、函数、其它 schema 的过程）都已向该 JOB 所属用户显式授权
- 避免依赖
AUTHID CURRENT_USER，除非你明确需要动态切换 schema；多数调度场景下AUTHID DEFINER（默认）更可控，但也意味着权限必须提前配齐 - 如果过程里调用了
DBMS_OUTPUT.PUT_LINE，JOB 中需显式加DBMS_OUTPUT.ENABLE，否则日志全丢，错误无声无息
最容易被忽略的是：权限配置看似完整，但漏掉了过程内部某条 SQL 所依赖的底层表权限——比如过程里查 hr.employees，除了 EXECUTE 权，还得 GRANT SELECT ON hr.employees TO scott;。
