迁移后大量对象状态为INVALID，因Oracle采用懒编译机制；应优先使用UTL_RECOMP并行重编译，它自动处理依赖顺序和跨schema编译，而DBMS_UTILITY.COMPILE_SCHEMA仅限单schema且不处理跨用户依赖；残留INVALID需排查硬编码表空间、权限缺失或动态SQL错误。
迁移后 SELECT * FROM DBA_OBJECTS WHERE STATUS = 'INVALID' 查出大量对象
表空间迁移本身不触发对象重新编译，Oracle 只在对象首次被调用时按需编译（lazy compilation）。所以迁移后对象状态仍维持迁移前的 INVALID，尤其常见于依赖了原表空间中表/索引的视图、包、函数、触发器。不是报错才出问题，而是第一次执行时才暴露——比如应用连上就卡住、查询视图返回 ORA-04068: existing state of packages has been discarded 或直接 ORA-06508: PL/SQL: could not find program unit being called。
用 UTL_RECOMP 并行重编译比手动 ALTER ... COMPILE 更可靠
手动逐个编译容易漏、顺序错（比如先编包体再编包头会失败），而 UTL_RECOMP 自动处理依赖顺序和并发粒度。注意它默认只重编当前用户下的对象，跨 schema 需指定参数：
-
EXEC UTL_RECOMP.RECOMP_SERIAL();—— 串行，适合小库或调试 -
EXEC UTL_RECOMP.RECOMP_PARALLEL(4);—— 并行 4 进程，生产环境推荐 -
EXEC UTL_RECOMP.RECOMP_PARALLEL(4, 'SCOTT');—— 只重编SCOTT用户下对象
执行前确认 DBA_REGISTRY 中组件状态正常，否则 UTL_RECOMP 可能跳过部分对象；若遇到 ORA-20001: Invalid object(s) found，说明有硬编码依赖已删除的对象，得人工排查。
DBMS_UTILITY.COMPILE_SCHEMA 编译整个 schema 但不处理跨用户依赖
适用于迁移后只关心单个业务用户的场景，比如把 APP_USER 的表挪到新表空间，顺手清掉它的无效对象：
EXEC DBMS_UTILITY.COMPILE_SCHEMA(schema => 'APP_USER', compile_all => FALSE);
compile_all => FALSE 表示只编译当前 INVALID 对象（快），TRUE 会强制重编所有（慢，且可能引入新问题）。它不会去编译 APP_USER 视图里引用的 HR.EMPLOYEES 的依赖链，这点和 UTL_RECOMP 不同——后者能穿透 schema 边界找依赖。
编译后仍有 INVALID 对象？重点查三类情况
不是所有 INVALID 都能靠重编译解决，迁移后残留的通常卡在这几处：
- 对象里硬编码了旧表空间名，比如
CREATE TABLE t1 (...) TABLESPACE users_old;—— 迁移后 DDL 没更新，编译时找不到物理段 - 同义词指向已 drop 的对象，或指向其他用户但权限未重授（
GRANT SELECT ON hr.employees TO app_user;忘了） - PL/SQL 中用了动态 SQL 查询不存在的列，或调用了已被重命名的函数，编译器静态检查不过
查具体原因用：SELECT OBJECT_NAME, OBJECT_TYPE, STATUS, TIMESTAMP, LAST_DDL_TIME FROM DBA_OBJECTS WHERE OWNER = 'APP_USER' AND STATUS = 'INVALID'; 结合 SHOW ERRORS 或查 ALL_ERRORS 视图看错误明细。别指望一次全清，有些得改代码再重建。
