EXPLAIN_MVIEW 是 Oracle 唯一公开暴露内部校验逻辑的接口，通过查询 mv_capabilities_table 中 REFRESH_FAST 对应的 possible='N' 及 msgtxt 字段可精准定位 FAST 刷新失败根因，再结合 mview_exceptions 的 recommendation 获取修复动作。
直接查 DBMS_MVIEW.EXPLAIN_MVIEW 输出的 MSGTXT 字段
别猜、别试、别重建成 complete 再看——explain_mview 是 oracle 唯一公开暴露内部校验逻辑的接口。它不报错，但会把每条限制用人话写进 msgtxt。执行后立刻查这张表：
- 先建解释表：
CREATE TABLE mv_capabilities_table (...)（结构见官方文档，字段不能少） - 运行：
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('YOUR_MV_NAME'); - 查关键行：
SELECT capability_name, possible, msgtxt FROM mv_capabilities_table WHERE statement_id = 'QSMQT_EXPLAIN_MVIEW' AND possible = 'N';
常见 MSGTXT 直接告诉你根因：比如 “materialized view log does not exist on table SALES” 或 “outer join with OR in WHERE clause”。这些比翻文档快十倍。
REFRESH_FAST 对应的 POSSIBLE 为 'N' 就是判决书
EXPLAIN_MVIEW 输出里有几十项 CAPABILITY_NAME，但真正决定能不能 FAST 刷新的，只有 CAPABILITY_NAME = 'REFRESH_FAST' 这一行。只要它的 possible 是 'N'，就说明 Oracle 已经在创建/刷新前明确拒绝了快速路径——不是参数没配对，是硬性条件不满足。
- 如果
POSSIBLE = 'Y'，但实际刷新还是走 COMPLETE，说明日志数据异常或时间戳错位，得查MLOG$_xxx和SNAPTIME$$ - 如果
POSSIBLE = 'N'，重点盯MSGNO：2005（缺日志）、2012（漏 ROWID）、2025（聚合不合规）、2031（外连接含 OR）——每个编号对应一类不可绕过的限制
验证物化视图日志是否“真可用”，不是“存在就行”
日志表 MLOG$_xxx 存在 ≠ 可用于 FAST 刷新。Oracle 检查的是结构完整性，而不是文件是否存在。
- 查
DBA_MVIEW_LOGS中对应基表的SEQUENCE和PRIMARY_KEY是否为'YES'；若只有ROWIDS = 'YES'，但基表做过SHRINK或MOVE，FAST 会静默退化为 COMPLETE - 确认日志是否启用
INCLUDING NEW VALUES：没这个子句，分区交换或批量插入可能完全不写日志 - 检查基表主键是否失效：
SELECT constraint_name, status FROM dba_constraints WHERE table_name = 'XXX' AND constraint_type = 'P';若status != 'ENABLED'，日志里的PRIMARY_KEY字段就形同虚设
别忽略 MVIEW_EXCEPTIONS 表里的 RECOMMENDATION
EXPLAIN_MVIEW 默认不把建议写进 mv_capabilities_table，得额外查 MVIEW_EXCEPTIONS 才能看到 Oracle 的修复提示。
- 执行：
SELECT recommendation FROM mview_exceptions WHERE mvname = 'YOUR_MV_NAME'; - 典型输出如：
"join not supported"、"expression not allowed in select list"、"missing COUNT(*) for aggregate" - 这个字段比
MSGTXT更聚焦动作项——它不是描述问题，是在告诉你“删掉这个 JOIN”或“加上这个 COUNT(*)”
真正卡住人的，往往不是不知道哪里错了，而是不知道 Oracle 认为“修复到什么程度才算过关”。RECOMMENDATION 就是那个临界点。
