DBMS_UTILITY.compile_schema不编译视图，因其仅处理PROCEDURE、FUNCTION、PACKAGE、TRIGGER和TYPE等PL/SQL对象；视图属SQL对象，需用ALTER VIEW ... COMPILE显式编译。
DBMS_UTILITY.compile_schema 不编译视图，这是它最常被忽略的限制。
DBMS_UTILITY.compile_schema 为什么编译不了视图
这个过程只处理 PL/SQL 类型对象：PROCEDURE、FUNCTION、PACKAGE、TRIGGER 和 TYPE。视图（VIEW）属于 SQL 对象，不在其作用范围内，调用后不会报错，但也不会生成任何编译动作。
常见错误现象是执行 EXEC DBMS_UTILITY.compile_schema(schema => 'SCOTT') 后，SELECT * FROM USER_OBJECTS WHERE STATUS = 'INVALID' 仍显示有失效视图，误以为命令没生效。
- 官方文档明确说明该过程不覆盖
VIEW、SYNONYM、INDEX等非 PL/SQL 对象 - 即使设置
compile_all => TRUE，行为也不变 - 依赖关系变化（如基表字段改名）导致的视图失效，必须显式
ALTER VIEW ... COMPILE
批量编译失效视图的可行方法
必须绕过 DBMS_UTILITY，改用能覆盖 VIEW 的机制。最稳妥的是动态生成 ALTER VIEW 语句并执行：
SELECT 'ALTER VIEW "' || OWNER || '"."' || OBJECT_NAME || '" COMPILE;'
FROM DBA_OBJECTS
WHERE STATUS = 'INVALID'
AND OBJECT_TYPE = 'VIEW'
AND OWNER IN ('SCOTT', 'HR'); -- 按需限定 schema
把结果保存为脚本（如 recompile_views.sql），再在 SQL*Plus 中运行：@recompile_views.sql。
- 注意双引号包裹 owner 和 object_name，防止大小写或特殊字符出错
- 避免在高并发 DDL 期间执行，否则可能因锁等待失败
- 执行后务必检查
SHOW ERRORS或查询USER_ERRORS，视图编译失败通常因基表不可见或权限缺失
UTL_RECOMP 能不能编译视图
不能。UTL_RECOMP.RECOMP_SERIAL 和 UTL_RECOMP.RECOMP_PARALLEL 同样只处理 PL/SQL 对象，和 DBMS_UTILITY.compile_schema 覆盖范围一致。它们底层调用的也是同一套编译逻辑，不扩展到视图。
如果你看到某个环境里视图“顺带”变 valid 了，大概率是因为：
- 视图所依赖的包/函数被重新编译后，触发了隐式重验（但不可靠）
- 手动或脚本单独执行过
ALTER VIEW - 数据库重启后自动刷新了部分缓存（仅限极简单视图，且不保证）
真正要确保所有失效视图就位，唯一可靠路径就是显式生成并执行 ALTER VIEW ... COMPILE。别指望任何“一键全量”包自动兜底——Oracle 对视图的编译控制始终是显式、分离、不自动级联的。
