物化视图日志未生效会导致DBMS_MVIEW.REFRESH完全跳过FAST路径，直接退化为COMPLETE或报ORA-12052；需通过DBA_MVIEW_LOGS确认rowids/primary_key为Y、filter_columns匹配、OBJECT_ID一致、日志表VALID，并用EXPLAIN_MVIEW查MSGTXT定位真实原因。
物化视图日志没生效，DBMS_MVIEW.REFRESH 就根本不会走快速路径——它连尝试都不会，直接退化成 COMPLETE 或报 ORA-12052。这不是“慢”，而是“压根不按你写的逻辑走”。
查日志表是否存在且结构匹配
日志表（如 MLOG$_ORDER_HEADER）存在 ≠ 可用。Oracle 要求它必须包含刷新所需的变更元数据，否则快速刷新能力直接被禁用。
- 运行
SELECT log_owner, master, log_table, rowids, primary_key, filter_columns FROM DBA_MVIEW_LOGS WHERE master = 'ORDER_HEADER'，确认rowids = 'Y'或primary_key = 'Y'；若两者都是N，FAST刷新不可能成功 - 检查
filter_columns是否为Y：如果物化视图查询里用了WHERE status IN ('A','B')这类过滤条件，而日志没启用INCLUDING NEW VALUES，增量记录就会漏掉 - 基表执行过
ALTER TABLE ... DROP COLUMN后，日志不会自动同步删列，必须重建：DROP MATERIALIZED VIEW LOG ON ORDER_HEADER; CREATE MATERIALIZED VIEW LOG ON ORDER_HEADER WITH ROWID, SEQUENCE (order_id, cust_id, status) INCLUDING NEW VALUES;
验证日志是否真在捕获变更
日志建了、结构对，但可能长期没写入任何数据——说明它根本没被触发，或已被 Oracle 忽略。
- 查日志表行数：
SELECT COUNT(*) FROM MLOG$_ORDER_HEADER。如果基表最近有大量INSERT/UPDATE/DELETE，但该值仍为 0，说明日志未启用或 DML 未提交（尤其注意ON COMMIT类型 MV 要求事务真正提交） - 对比对象 ID：
SELECT object_id FROM dba_objects WHERE object_name = 'ORDER_HEADER'和SELECT master_object_id FROM dba_mview_logs WHERE log_table = 'MLOG$_ORDER_HEADER'必须完全一致；不一致即表示日志与基表“失联”，Oracle 不会使用它 -
SELECT status FROM dba_objects WHERE object_name = 'MLOG$_ORDER_HEADER'返回INVALID？立刻重建日志，不要尝试ALTER
用 EXPLAIN_MVIEW 看 Oracle 的真实判断
EXPLAIN_MVIEW 不是辅助工具，它是唯一能告诉你“Oracle 为什么拒绝 FAST”的权威出口。它输出的 MSGTXT 比错误码更准，比猜测更可靠。
- 先执行
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_ORDERS_SUMMARY')，再查SELECT * FROM MV_CAPABILITIES_TABLE WHERE statement_id = 'QSMQT_EXPLAIN_MVIEW' - 重点过滤
CAPABILITY_NAME = 'REFRESH_FAST'，看POSSIBLE是'Y'还是'N'；若为'N'，往下找MSGNO和MSGTXT - 常见
MSGNO含义：2005= 日志不存在或未启用；2012= 查询中用了某张基表的ROWID，但该表日志没开WITH ROWID；2031= 外连接 +WHERE里有OR，语法不合规 - 别跳过这步直接改 SQL——同一段语句，在 19c 上
EXPLAIN_MVIEW显示POSSIBLE='Y'，跨 DBLink 到 10g 源库时仍会失败，因为协议不兼容。只有MSGTXT会提示 “remote database version too low”
检查刷新时是否误用了 COMPLETE 模式
很多人以为 STALENESS = 'STALE' 就代表需要 FAST 刷新，其实不然。如果调用 DBMS_MVIEW.REFRESH 时没指定 method => 'F'，默认可能走 FORCE，而 FORCE 在日志失效时静默降级为 COMPLETE，既不报错也不警告。
- 查最近一次刷新记录：
SELECT mview_name, last_refresh_date, refresh_method FROM DBA_MVIEWS WHERE mview_name = 'MV_ORDERS_SUMMARY'；如果refresh_method是COMPLETE，说明日志没起作用，或调用参数错了 - 手动刷新务必显式指定：
EXEC DBMS_MVIEW.REFRESH('MV_ORDERS_SUMMARY', method => 'F')；用'F'字符串比用'FAST'更稳妥，避免版本差异 - 定时任务（
DBMS_SCHEDULER）中，封装过程若没透传method参数，就等于没配——默认行为不可靠
最常被忽略的一点：日志表本身不是“开关”，而是“契约”。它要求基表结构、DML 模式、甚至事务提交方式都严格对齐。哪怕只有一列没包含在日志定义里，或一个 ON COMMIT 物化视图的事务没真正提交，整个快速刷新链就断了——而 Oracle 从不主动告诉你断在哪一行。
