Oracle中DBMS_UTILITY.compile_schema和UTL_RECOMP不编译视图，因其仅处理PL/SQL对象（PROCEDURE、FUNCTION等），视图属SQL对象故被忽略；查失效视图应优先用DBA_OBJECTS或ALL_OBJECTS限定OWNER并验证执行能力；批量编译须生成带双引号的ALTER VIEW ... COMPILE语句脚本执行，失败后需检查基表、列、权限及ALL_ERRORS。
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' 还有视图，就以为命令失败了——其实它根本没尝试编译视图。
如何查出真正失效的视图
别只信 USER_OBJECTS，它只返回当前用户拥有的对象，且 STATUS = 'INVALID' 不可靠：有些视图依赖表已被删，状态却仍是 VALID，一查就报 ORA-00942。
- 有 DBA 权限时，必须用
DBA_OBJECTS并显式限定OWNER：
SELECT owner, object_name
FROM DBA_OBJECTS
WHERE object_type = 'VIEW'
AND status = 'INVALID'
AND owner IN ('HR', 'SCOTT');- 没 DBA 权限时，改用
ALL_OBJECTS，但必须加AND owner = 'XXX'精确限定，否则可能权限不足或返回空 - 更稳妥的做法是顺手验证运行能力：执行
SELECT COUNT(*) FROM your_view_name WHERE ROWNUM = 1，看是否真能走通
批量编译视图的正确写法
不要写 PL/SQL 循环调用 EXECUTE IMMEDIATE 'ALTER VIEW ... COMPILE' ——中间一条失败，后续全跳过，还难定位哪条挂了。
推荐动态生成独立语句脚本，每条单独提交：
SELECT 'ALTER VIEW "' || owner || '"."' || object_name || '" COMPILE;'
FROM DBA_OBJECTS
WHERE object_type = 'VIEW'
AND status = 'INVALID'
AND owner IN ('HR');- 双引号包裹
OWNER和OBJECT_NAME是必须的——否则遇到大写或含下划线的名称会报ORA-00942 - 把结果保存为
recompile_views.sql，在 SQL*Plus 中运行：@recompile_views.sql - 别在业务高峰期跑，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权限，且没有同义词覆盖干扰
重启数据库或等隐式重验触发，只在极简单场景下偶然生效，不可靠。真正要确保所有视图就位，唯一路径就是显式执行 ALTER VIEW ... COMPILE，并验证 ALL_ERRORS 为空、STATUS 变为 VALID。这步绕不开，也没捷径。
