物化视图变INVALID是因基表结构变更导致依赖解析失败，非刷新失败所致；需用DBA_MVIEWS查全量状态，修复前须验证列、约束、精度等是否匹配，COMPILE仅重解析不修复依赖断裂。
基表结构变更后物化视图变 INVALID，不是刷新失败导致的，而是 Oracle 编译器在依赖检查阶段直接拒绝加载其定义——因为物化视图元数据里引用的列、约束或类型已不存在或不匹配。
物化视图变成 INVALID 的真实触发点
Oracle 不会在 DDL 执行时主动标记物化视图为 INVALID，而是在下一次访问（如查询、刷新、编译）时做依赖解析，发现不一致就置为 INVALID。常见触发场景包括：
- 基表执行了
ALTER TABLE ... DROP COLUMN，而该列出现在物化视图SELECT列表或WHERE条件中 - 基表主键被删（
DROP PRIMARY KEY），但物化视图定义依赖PRIMARY KEY刷新模式 - 基表改了字段精度（如
NUMBER(10,2) → NUMBER(12,4)），而物化视图对应列仍按旧精度建模 - 基表上用了同义词或私有同义词指向的对象被删，且物化视图定义里显式写了该同义词名
为什么 ALTER MATERIALIZED VIEW ... COMPILE 有时不生效？
COMPILE 命令只是尝试重新解析物化视图定义，并不修复底层依赖断裂。它会失败并报 ORA-04063，原因往往是：
- 当前用户对基表缺失
SELECT权限（即使之前有，权限可能被REVOKE） - 基表被重命名或删除，而物化视图定义里仍硬编码原名
- 物化视图定义中用了自定义函数或类型，但该函数/类型已被
DROP或ALTER TYPE ... INVALIDATE - 基表是 IOT 表，但物化视图日志建在了错误的 overflow 段上，
COMPILE无法绕过物理结构校验
查 INVALID 状态不能只看 USER_MVIEWS
USER_MVIEWS 只返回当前用户拥有的物化视图，漏掉跨 schema 依赖；真正要定位全部失效对象，必须用：
SELECT owner, mview_name, staleness, status
FROM DBA_MVIEWS
WHERE status = 'INVALID'
AND owner IN ('SCOTT', 'HR', 'YOUR_SCHEMA');
注意：status = 'INVALID' 和 staleness = 'UNUSABLE' 是两回事——前者是编译态失败，后者是刷新能力失效，二者可同时存在但需分开处理。
修复前必须确认依赖是否真的可恢复
别急着 CREATE OR REPLACE，先验证基表现状是否还能支撑原物化视图语义：
- 用
SELECT column_name, data_type, data_precision FROM ALL_TAB_COLUMNS WHERE table_name = 'BASE_TABLE' AND owner = 'BASE_OWNER'对比物化视图定义里的列清单 - 查
ALL_CONSTRAINTS确认主键/唯一索引是否还在，且状态为ENABLED - 如果基表加了
NOT NULL列但没进物化视图日志，REFRESH FAST即使编译成功也会在运行时报ORA-12054 - 涉及分区表时，
EXPLAIN_MVIEW输出里若PCT显示DISABLED，说明分区变更未注册到物化视图元数据，此时COMPILE无意义
真正难处理的是那些“能编译通过但刷新结果错位”的情况——比如基表某列从 VARCHAR2(10) 扩到 VARCHAR2(50)，物化视图列仍是旧长度，插入超长值会被截断，这种问题不会报错，只会静默丢数据。
