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 —— 这往往是因为没按依赖链顺序编译。
-
utlrp.sql默认串行执行，适合大多数生产环境；如果无效对象超过 500 个且系统资源充足，可改用UTL_RECOMP.RECOMP_PARALLEL(4)加速（需提前确认job_queue_processes >= 4） - 脚本路径中的
?代表$ORACLE_HOME，不用硬编码绝对路径；Windows 下路径分隔符是反斜杠，但 SQL*Plus 里仍用正斜杠即可 - 执行期间禁止任何 DDL 操作（比如建表、改列），否则可能卡住或报
ORA-00054: resource busy
ALTER ... COMPILE 只适用于单个对象或已知范围
当你明确知道哪个过程、函数或包体失效，或者只想修某个 schema 下的几个对象时，ALTER 语句更轻量、可控。
使用场景：PL/SQL Developer 界面里点“编译”按钮背后实际就是这条语句；CI/CD 流水线中修复特定变更引入的失效对象。
- 包必须分开编译：
ALTER PACKAGE pkg_name COMPILE PACKAGE编译规范，ALTER PACKAGE pkg_name COMPILE BODY编译包体；只写COMPILE默认两者都试，但若规范无效，包体一定编译失败 - 视图和触发器也支持：
ALTER VIEW scott.emp_view COMPILE、ALTER TRIGGER hr.trg_log COMPILE - 编译后立刻查错误：
SHOW ERRORS（在 SQL*Plus 中）或SELECT * FROM USER_ERRORS WHERE NAME = 'XXX'
用 UTL_RECOMP 控制编译范围和并发度
Oracle 10g 及以后版本提供了 UTL_RECOMP 包，比 utlrp.sql 更灵活，尤其适合按 schema 隔离编译或资源受限环境。
性能 / 兼容性影响：并行线程数设太高（如 > CPU 核心数 × 2）反而拖慢整体速度，因为大量 I/O 竞争会压垮磁盘子系统。
- 只重编译
SCOTT用户下的失效对象：EXEC UTL_RECOMP.RECOMP_PARALLEL(NULL, 'SCOTT') - 强制串行、避免资源争抢：
EXEC UTL_RECOMP.RECOMP_SERIAL('HR') -
schema参数区分大小写，且必须与DBA_OBJECTS.OWNER值完全一致（例如'APP_USER'不能写成'app_user'）
别忽略权限和前置状态检查
很多编译失败不是语法问题，而是底层依赖缺失或权限不足。特别是升级后首次运行 utlrp.sql，常卡在 STANDARD 或 DBMS_STANDARD 包上。
容易踩的坑：以为自己有 ALTER ANY PROCEDURE 就能编译所有对象，其实编译 DBA_* 视图或 SYS 下对象必须用 SYSDBA 连接，普通 DBA 角色也不够。
- 先确认关键系统包有效：
SELECT OBJECT_NAME, STATUS FROM DBA_OBJECTS WHERE OWNER = 'SYS' AND OBJECT_NAME IN ('STANDARD', 'DBMS_STANDARD') AND STATUS != 'VALID' - 查锁定情况：
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 - 编译大量对象时，
DBA_OBJECTS的STATUS字段更新有延迟，建议编译完等 30 秒再查，或用SELECT COUNT(*) FROM DBA_OBJECTS WHERE STATUS = 'INVALID'二次验证
真正麻烦的不是编译动作本身，而是编译失败后错误堆栈里嵌套的依赖链 —— 比如一个函数失效，根源可能是它引用的某个类型定义被删了，而这个类型又依赖另一个包。这时候得顺着 DBA_DEPENDENCIES 一层层查，而不是反复重试 utlrp.sql。
