oracle存储过程需重新编译的根本原因是timestamp和signature两种依赖有效性校验机制：默认timestamp模型通过比对last_ddl_time判断是否失效；signature模型则仅校验接口签名一致性，需显式启用且兼容性要求高。
oracle 存储过程需要重新编译，根本原因不是“代码变了才要重编”，而是数据库依赖的两种对象有效性校验机制在起作用：timestamp 模型和 signature 模型。这两种模型决定了 oracle 何时认为一个已编译的对象（如 procedure、function、package）已经“过期”，必须强制重新编译才能执行。
TIMESTAMP 模型：依赖对象修改时间戳不匹配就失效
这是 Oracle 默认启用的依赖检查方式。当存储过程 A 引用了表 B 或函数 C，Oracle 会在编译 A 时记录 B 和 C 当前的 LAST_DDL_TIME（即上次 DDL 修改时间）。后续每次调用 A 前，Oracle 都会比对：如果 B 或 C 任意一个的 LAST_DDL_TIME 比 A 编译时记录的时间更新，A 就被标记为 INVALID。
常见触发场景包括：
- 对被引用的表执行
ALTER TABLE ... ADD COLUMN、DROP INDEX、CREATE INDEX - 重建一个视图（
CREATE OR REPLACE VIEW） - 修改一个被依赖的
FUNCTION或PACKAGE - 哪怕只是给表加了个注释（
COMMENT ON TABLE），也会更新LAST_DDL_TIME
此时查 USER_OBJECTS 会看到该过程的 STATUS 是 INVALID，首次调用时自动触发隐式重编译；若失败（比如权限不足或语法错），就会报 ORA-04068: existing state of packages has been discarded 或 ORA-04063 类错误。
SIGNATURE 模型：只校验接口签名，更宽松但需显式启用
SIGNATURE 模型不看时间戳，只检查被依赖对象的“签名”是否变化——即函数/过程的参数个数、类型、返回类型、包规范中公开的变量/常量声明等是否一致。只要签名没变，即使内部实现改了、统计信息更新了、甚至加了新索引，也不会导致调用方失效。
启用方式是创建或替换对象时加上 EDITIONABLE + SIGNATURE 相关设置，但更常用的是在 CREATE PACKAGE 或 CREATE PROCEDURE 语句末尾加 EDITIONABLE 并配合 ALTER SESSION SET REUSE SETTINGS = TRUE（仅影响当前会话），不过生产环境极少手动切模型。真正决定用哪个模型的是初始化参数 REMOTE_DEPENDENCIES_MODE：
-
REMOTE_DEPENDENCIES_MODE = TIMESTAMP（默认）→ 走时间戳比对 -
REMOTE_DEPENDENCIES_MODE = SIGNATURE→ 走签名比对（需所有依赖对象都支持，且通常要求 Oracle 11gR2+）
注意：SIGNATURE 模型下，如果被引用的包体（BODY）被修改但包头（SPEC）没动，调用方不会失效；但若包头里某个函数的参数类型变了，哪怕只改了一个 NUMBER 为 INTEGER，签名就不同，调用方仍会变 INVALID。
为什么 ALTER PROCEDURE ... COMPILE 不总能成功？
执行 ALTER PROCEDURE my_proc COMPILE 看似简单，但失败往往不是命令本身的问题，而是底层依赖未就绪：
- 被引用的表、视图、同义词不存在，或当前用户无
SELECT/EXECUTE权限 - 依赖的另一个存储过程或包当前状态是
INVALID，且无法连带编译过去 - 过程里用了动态 SQL（
EXECUTE IMMEDIATE）引用了尚未创建的对象，编译器无法静态解析 - PL/SQL 代码里有未声明的变量、拼错的字段名，或类型不匹配（如把
VARCHAR2(10)赋值给NUMBER）
查错优先看 USER_ERRORS 视图：SELECT * FROM USER_ERRORS WHERE NAME = 'MY_PROC' AND TYPE = 'PROCEDURE';。里面每条记录对应一个编译错误位置和描述，比 SQL*Plus 的报错更准、更全。
真正容易被忽略的是：TIMESTAMP 模型下，一次 DDL 可能连锁导致十几个过程变 INVALID，而你只盯着报错的那个过程修；其实应该先查 ALL_DEPENDENCIES 确认它依赖谁，再顺藤摸瓜。SIGNATURE 模型虽稳定，但切换成本高、兼容性边界模糊，多数团队宁可接受定期批量重编译，也不轻易改全局模式。
