Oracle中DBMS_UTILITY.compile_schema和UTL_RECOMP无法编译失效视图，因其仅处理PL/SQL对象；需显式执行ALTER VIEW ... COMPILE语句批量重编译，并验证ALL_ERRORS为空且STATUS为VALID。
Oracle里失效的SQL视图不能用 DBMS_UTILITY.compile_schema 或 UTL_RECOMP 一键编译——它们根本不处理视图，执行后状态照旧无效。
为什么 DBMS_UTILITY.compile_schema 对视图没反应
这个过程只识别 PL/SQL 类型对象：PROCEDURE、FUNCTION、PACKAGE、TRIGGER、TYPE。视图是纯 SQL 对象，不在其扫描范围内。即使加了 compile_all => TRUE，行为也不变。常见误判是执行完该命令，再查 USER_OBJECTS WHERE STATUS = 'INVALID' 还有视图，就以为命令失败了——其实它压根就没尝试编译视图。
批量编译失效视图的可靠做法
必须显式生成并执行 ALTER VIEW ... COMPILE 语句。动态拼接比 PL/SQL 循环更安全，避免一个失败就中断全部：
- 先查出所有失效视图（注意 owner 大小写和特殊字符）：
SELECT 'ALTER VIEW "' || OWNER || '"."' || OBJECT_NAME || '" COMPILE;' FROM DBA_OBJECTS WHERE STATUS = 'INVALID' AND OBJECT_TYPE = 'VIEW' AND OWNER IN ('SCOTT', 'HR'); - 把结果保存为
recompile_views.sql，在 SQL*Plus 中运行：@recompile_views.sql - 双引号包裹
OWNER和OBJECT_NAME是必须的——否则遇到大写或含下划线的名称会报ORA-00942 - 别在业务高峰期跑，DDL 锁冲突可能导致部分语句卡住或报
ORA-00054
编译失败时该查什么
ALTER VIEW xxx COMPILE 报错，说明视图定义本身已不可修复，不是“编译问题”，而是依赖断裂：
- 查基表是否存在：
SELECT * FROM ALL_TABLES WHERE OWNER = 'XXX' AND TABLE_NAME = 'YYY' - 查依赖列是否还在：
SELECT COLUMN_NAME FROM ALL_TAB_COLUMNS WHERE TABLE_NAME = 'BASE_TABLE' AND COLUMN_NAME = 'COL_A' - 查具体错误：
SELECT LINE, TEXT FROM ALL_ERRORS WHERE NAME = 'YOUR_VIEW' AND OWNER = 'SCHEMA_NAME' ORDER BY SEQUENCE - 如果
ALL_ERRORS为空，但状态仍是INVALID，大概率是权限缺失——确认当前用户对基表有SELECT权限，且没有同义词覆盖干扰
别指望自动重验或重启能救活视图
有人发现重启数据库后部分视图变 valid 了，那只是极简单场景下的缓存刷新副作用，不可靠。依赖对象（比如函数）被重新编译后触发的隐式重验也只在特定条件下发生，且不保证成功。真正要确保所有视图就位，唯一路径就是显式执行 ALTER VIEW ... COMPILE，并验证 ALL_ERRORS 为空、STATUS 变为 VALID。这步绕不开，也没捷径。
