Oracle未改动的函数与存储过程意外失效需重编译原因排查

首先明确结论：异常业务数据入库不会导致已经编译成功的函数、存储过程变为未编译失效状态。PL/SQL对象的失效标记是存放在数据字典里的元数据状态，仅和对象依赖关系变化、元数据一致性异常有关，和对象运行时处理的具体业务数据没有直接关联，数据异常只会导致对象运行时报错，不会改变它的编译状态。

结合运维场景的常见诱因按概率从高到低排序如下：

• 共同依赖对象发生DDL变更
  这是90%以上同类故障的根因：这15个失效对象肯定共同依赖了某一个/某一组下层对象（比如公共表、视图、自定义类型、全局同义词、工具类存储过程/函数、甚至Oracle内置包），只要这些下层对象被执行了DDL操作（哪怕操作人完全没碰这15个失效对象本身），Oracle会自动把所有依赖该下层对象的上层PL/SQL对象标记为INVALID。
  这类无感知的DDL非常常见：比如运维给公共表加字段、改字段类型、重建表，定期维护作业重建索引时触发表元数据更新，公共工具包被重新编译，用户权限被回收/调整，同义词指向的源对象被替换，很多时候执行操作的人根本意识不到会连带影响上层依赖的业务对象。
• 数据库补丁、实例重启触发的批量失效
  如果故障发生前打过Oracle PSU/RU补丁、做过实例重启、核心参数调整，当补丁涉及数据字典、内置PL/SQL包变更时，所有依赖相关内置对象的自定义PL/SQL都会被标记为失效。部分Oracle版本（尤其是11g早期版、12cR1）存在bug，补丁更新后不会自动触发依赖对象重编译，就会出现批量失效的情况。
• 自动统计信息收集作业bug
  Oracle默认开启的自动统计信息收集作业在上述低版本中存在已知bug：当对依赖表收集统计信息时如果遇到锁冲突、元数据版本迭代错误，会错误把关联的PL/SQL对象标记为失效，这类故障发生前往往会伴随短暂的系统卡顿，和描述的故障时序完全吻合。
• 数据导入/跨环境同步的连带影响
  如果故障前做过数据泵导入（impdp）、全库恢复、跨库对象同步操作，哪怕没有显式覆盖这15个业务对象，只要导入/同步操作更新了它们依赖的公共对象、覆盖了同义词定义、调整了对象权限，一样会连带导致上层对象失效。
• 元数据一致性异常
  如果故障前数据库出现过异常宕机、存储IO闪断、归档恢复异常，可能导致数据字典中记录的PL/SQL对象元数据校验值不匹配，Oracle也会将这类对象标记为失效，这类场景下手动重编译即可恢复，只要不反复出现就不需要额外处理。

• 查故障时间点前后的DDL操作记录，执行以下SQL即可定位时间窗口内的所有DDL动作：

SELECT OWNER, ACTION_NAME, OBJECT_NAME, TIMESTAMP 
FROM DBA_AUDIT_TRAIL 
WHERE ACTION_NAME IN ('ALTER','CREATE','DROP','REVOKE','GRANT','REPLACE') 
AND TIMESTAMP BETWEEN 故障发生时间 - 1/24 AND 故障发生时间 + 10/1440;

• 梳理15个失效对象的共同依赖项，执行SQL匹配公共依赖对象后，核对该对象的最后DDL时间是否和故障时间吻合：

SELECT REFERENCED_OWNER, REFERENCED_NAME, REFERENCED_TYPE
FROM DBA_DEPENDENCIES 
WHERE NAME IN ('失效对象名1','失效对象名2','失效对象名3') -- 填入所有15个失效对象名
GROUP BY REFERENCED_OWNER, REFERENCED_NAME, REFERENCED_TYPE
HAVING COUNT(1) = 15; -- 筛选所有对象共同依赖的目标

• 核对自动统计信息作业、补丁更新、数据导入等运维操作的执行时间，确认是否和故障时间重合。

内容的提问来源于stack exchange，提问作者Zar Tel