先查出存储过程中引用的无效对象，需递归查询ALL_DEPENDENCIES定位依赖链，再结合ALL_OBJECTS筛选STATUS='INVALID'且非系统用户的对象；再按类型生成对应修复语句，区分PROCEDURE/FUNCTION/PACKAGE BODY等可编译对象与VIEW/TABLE等需重建对象，并排除SYS等系统用户及测试对象，最后注意ORA-04068包状态问题。
怎么查出存储过程中引用的无效对象？
oracle 存储过程编译通过不代表运行时安全——它可能依赖已删除的表、视图或函数，这些对象在 all_dependencies 里仍被记录，但实际状态是 invalid。直接查 user_objects 只能看到过程自身是否失效，漏掉深层依赖。
正确做法是递归扫描依赖链：先定位目标过程，再用 ALL_DEPENDENCIES 查它的直接依赖，再查这些依赖的依赖，直到叶子节点。关键过滤条件是 STATUS = 'INVALID' 且 OWNER 不是系统用户（排除 SYS/SYSTEM）。
- 别只查
STATUS = 'INVALID'在USER_OBJECTS，那只是过程本身编译失败，不是引用问题 - 注意
ALL_DEPENDENCIES中的REFERENCED_OWNER和REFERENCED_NAME才是被引用对象，不是OWNER/NAME - 用
CONNECT BY递归时加NOCYCLE，防止同名同类型对象循环引用导致死循环
如何生成修复语句而不是手动一个个重编译？
查出无效对象后，不能硬写 ALTER ... COMPILE ——表和视图没有这个语法，函数/过程/包体才支持。得按对象类型分发指令：
-
PROCEDURE/FUNCTION/PACKAGE→ALTER PROCEDURE xxx COMPILE -
PACKAGE BODY→ALTER PACKAGE xxx COMPILE BODY -
VIEW/TABLE（如果因基表变更导致失效）→ 需重建或刷新物化视图，不能COMPILE -
SYNONYM→ 先查REFERENCED_OWNER是否存在，再执行CREATE OR REPLACE SYNONYM
建议用 SELECT 拼接 SQL：
SELECT 'ALTER ' || OBJECT_TYPE || ' ' || OWNER || '.' || OBJECT_NAME ||
CASE WHEN OBJECT_TYPE = 'PACKAGE BODY' THEN ' COMPILE BODY;'
WHEN OBJECT_TYPE IN ('PROCEDURE','FUNCTION','PACKAGE') THEN ' COMPILE;'
ELSE ';' END AS ddl
FROM ALL_OBJECTS
WHERE STATUS = 'INVALID'
AND OBJECT_TYPE IN ('PROCEDURE','FUNCTION','PACKAGE','PACKAGE BODY','VIEW');
为什么自动修复后过程还是报 ORA-04068？
这是最常踩的坑：过程编译成功，但调用时抛 ORA-04068: existing state of packages has been discarded。根本原因是包变量（PACKAGE STATE）在重编译后被清空，而会话里还缓存着旧状态。
- 单纯
ALTER PACKAGE xxx COMPILE不重置包状态，但ALTER PACKAGE xxx COMPILE BODY会强制丢弃状态 - 如果过程依赖的包有全局变量，必须让应用重启会话，或显式执行
EXEC DBMS_SESSION.RESET_PACKAGE; - 批量修复脚本里别漏掉
DBMS_UTILITY.COMPILE_SCHEMA的compile_all => FALSE参数——设为TRUE会连带编译所有依赖，放大状态丢失风险
能不能跳过某些对象避免误伤？
生产环境严禁无差别重编译。比如 DBA_ 视图、GV$ 动态性能视图、或是别人维护的第三方包，它们的 INVALID 状态可能是故意留的（如等待上游部署完成）。
- 加白名单过滤：用
AND OWNER NOT IN ('SYS','SYSTEM','OUTLN','DBSNMP') - 排除测试对象：加
AND OBJECT_NAME NOT LIKE 'TMP\_%' ESCAPE '\' - 跳过近期被标记为“暂不处理”的对象：建一张
INVALID_OBJ_EXCLUDE表，字段含OWNER,OBJECT_NAME,REASON，修复脚本里 LEFT JOIN 排除
真正麻烦的从来不是找出无效对象，而是确认它为什么无效——是上游表删了？同义词指向错了？还是权限被 revoke？自动脚本只能修“能修的”，剩下的得靠人看 SHOW ERRORS 输出和依赖路径。
