物化视图失效不能靠“编译”修复，因Oracle不支持ALTER MATERIALIZED VIEW ... COMPILE语法；真实状态需查DBA_MVIEWS中STALENESS字段：STALE表示数据过期、UNUSABLE表示日志或结构损坏、FRESH仅说明数据最新；修复须按场景刷新并校准日志，如UNUSABLE时重建MVIEW LOG，TRUNCATE分区后强制COMPLETE+FALSE刷新。
物化视图失效不能靠“编译”修复，必须先查清是否真失效、为何失效——ALTER MATERIALIZED VIEW ... COMPILE 是无效操作，Oracle 不支持该语法。
查物化视图真实状态：别只看 STATUS
物化视图在 DBA_OBJECTS 中的 STATUS = 'INVALID' 很少见，它通常显示 VALID 却已无法刷新或查询重写失效。真正关键的是 STALENESS 和 STALENESS 字段：
-
STALENESS = 'STALE'：基表变更后未刷新，数据过期但结构完好 -
STALENESS = 'UNUSABLE'：日志损坏、分区 TRUNCATE、NOT NULL 列未同步等导致 FAST 刷新链断裂 -
STALENESS = 'FRESH'：当前数据最新，但不保证查询重写可用（还需检查QUERY_REWRITE_ENABLED）
执行：
SELECT mview_name, refresh_mode, refresh_method, staleness, last_refresh_date, compile_state FROM dba_mviews WHERE owner = 'YOUR_SCHEMA';
为什么 ALTER MATERIALIZED VIEW ... COMPILE 会报错
因为 Oracle 根本不提供这个语法——ALTER MATERIALIZED VIEW 支持的子句只有 RENAME TO、COMPILE 仅适用于普通视图，对物化视图执行会直接报 ORA-02000: missing WITH keyword 或 ORA-00905: missing keyword。
常见误操作：
- 把普通视图编译脚本套用到物化视图上（如生成
ALTER MATERIALIZED VIEW mv_name COMPILE） - 在 PL/SQL Developer 点击“编译无效对象”按钮，它内部按
OBJECT_TYPE分发命令，遇到MATERIALIZED VIEW类型直接跳过或静默失败 - 依赖
DBMS_UTILITY.compile_schema，它完全忽略物化视图类型
真正有效的“修复”路径是刷新 + 日志校准
物化视图不是代码对象，它的“有效性”取决于数据一致性与日志完整性。所谓“修复”，其实是分场景触发正确刷新并补全依赖：
- 若
STALENESS = 'STALE'：直接跑DBMS_MVIEW.REFRESH('MV_NAME', 'F')（FAST）或'C'（COMPLETE） - 若
STALENESS = 'UNUSABLE'：先查USER_MVIEW_LOGS是否覆盖所有基表新增列；缺失则必须重建日志，不能ALTER - 若刚对基表执行了
TRUNCATE PARTITION：放弃 FAST，改用DBMS_MVIEW.REFRESH('MV_NAME', 'C', atomic_refresh => FALSE)，否则卡死在REFRESHING状态 - 若刷新报
ORA-12008：这不是错误本身，立刻开10046 trace，从 trace 文件里找第一个紧随刷新语句的ORA-错误（比如ORA-01652或ORA-00001）
容易被忽略的权限与依赖陷阱
即使刷新命令能提交，也可能因隐性依赖失败而静默退化：
- 物化视图定义中用了
SELECT *，基表新增列后，刷新成功但结果集不包含新列——STALENESS仍为FRESH，但业务查询漏数据 - 基表加了
NOT NULL列但没重建物化视图日志，FAST刷新永远失败，且STALENESS可能长期卡在STALE而非UNUSABLE -
DBA_MVIEWS.COMPILE_STATE = 'ERROR'表示上次刷新抛出未捕获异常，此时必须查V$SESSION_LONGOPS定位卡点，而非重试
最危险的错觉是：看到 STATUS = 'VALID' 就认为没问题。物化视图的有效性不在编译态，而在数据态和日志链完整度——这点和普通视图有本质区别。
