如何重新编译Oracle PL/SQL中的所有无效对象

utlrp.sql是最稳妥的全局编译方式，由Oracle最新维护，自动按依赖顺序编译所有失效PL/SQL对象，需以SYSDBA身份执行且禁止并发DDL操作。

直接执行 utlrp.sql 是最稳妥的全局编译方式

只要数据库能连上、有 SYSDBA 权限，@?/rdbms/admin/utlrp.sql 就是最推荐的第一步。它由 Oracle 最新维护，自动处理依赖顺序，不会因先编译子对象再编译父对象而失败。

常见错误现象：手动拼 ALTER 语句批量执行时，遇到 ORA-04043: object does not exist 或 ORA-04068: existing state of packages has been discarded —— 这往往是因为没按依赖链顺序编译。

1. utlrp.sql 默认串行执行，适合大多数生产环境；如果无效对象超过 500 个且系统资源充足，可改用 UTL_RECOMP.RECOMP_PARALLEL(4) 加速（需提前确认 job_queue_processes >= 4）
2. 脚本路径中的 ? 代表 $ORACLE_HOME，不用硬编码绝对路径；Windows 下路径分隔符是反斜杠，但 SQL*Plus 里仍用正斜杠即可
3. 执行期间禁止任何 DDL 操作（比如建表、改列），否则可能卡住或报 ORA-00054: resource busy

ALTER ... COMPILE 只适用于单个对象或已知范围

当你明确知道哪个过程、函数或包体失效，或者只想修某个 schema 下的几个对象时，ALTER 语句更轻量、可控。

使用场景：PL/SQL Developer 界面里点“编译”按钮背后实际就是这条语句；CI/CD 流水线中修复特定变更引入的失效对象。

1. 包必须分开编译：ALTER PACKAGE pkg_name COMPILE PACKAGE 编译规范，ALTER PACKAGE pkg_name COMPILE BODY 编译包体；只写 COMPILE 默认两者都试，但若规范无效，包体一定编译失败
2. 视图和触发器也支持：ALTER VIEW scott.emp_view COMPILE、ALTER TRIGGER hr.trg_log COMPILE
3. 编译后立刻查错误：SHOW ERRORS（在 SQL*Plus 中）或 SELECT * FROM USER_ERRORS WHERE NAME = 'XXX'

用 UTL_RECOMP 控制编译范围和并发度

Oracle 10g 及以后版本提供了 UTL_RECOMP 包，比 utlrp.sql 更灵活，尤其适合按 schema 隔离编译或资源受限环境。

性能 / 兼容性影响：并行线程数设太高（如 > CPU 核心数 × 2）反而拖慢整体速度，因为大量 I/O 竞争会压垮磁盘子系统。

1. 只重编译 SCOTT 用户下的失效对象：EXEC UTL_RECOMP.RECOMP_PARALLEL(NULL, 'SCOTT')
2. 强制串行、避免资源争抢：EXEC UTL_RECOMP.RECOMP_SERIAL('HR')
3. schema 参数区分大小写，且必须与 DBA_OBJECTS.OWNER 值完全一致（例如 'APP_USER' 不能写成 'app_user'）

别忽略权限和前置状态检查

很多编译失败不是语法问题，而是底层依赖缺失或权限不足。特别是升级后首次运行 utlrp.sql，常卡在 STANDARD 或 DBMS_STANDARD 包上。

容易踩的坑：以为自己有 ALTER ANY PROCEDURE 就能编译所有对象，其实编译 DBA_* 视图或 SYS 下对象必须用 SYSDBA 连接，普通 DBA 角色也不够。

1. 先确认关键系统包有效：SELECT OBJECT_NAME, STATUS FROM DBA_OBJECTS WHERE OWNER = 'SYS' AND OBJECT_NAME IN ('STANDARD', 'DBMS_STANDARD') AND STATUS != 'VALID'
2. 查锁定情况：SELECT SID, SERIAL#, OSUSER, PROGRAM FROM V$SESSION WHERE SID IN (SELECT SESSION_ID FROM DBA_DML_LOCKS WHERE NAME = 'YOUR_INVALID_PKG')，避免 ORA-04021: timeout occurred while waiting for a lock
3. 编译大量对象时，DBA_OBJECTS 的 STATUS 字段更新有延迟，建议编译完等 30 秒再查，或用 SELECT COUNT(*) FROM DBA_OBJECTS WHERE STATUS = 'INVALID' 二次验证

真正麻烦的不是编译动作本身，而是编译失败后错误堆栈里嵌套的依赖链 —— 比如一个函数失效，根源可能是它引用的某个类型定义被删了，而这个类型又依赖另一个包。这时候得顺着 DBA_DEPENDENCIES 一层层查，而不是反复重试 utlrp.sql。