必须显式在物化视图日志中包含分区键字段，否则FAST刷新将静默退化为COMPLETE；远程查询需避免动态谓词，分区交换后须重建日志，刷新应避开分区维护窗口。
不能直接在分区表上建 FAST 刷新的物化视图，除非满足严格的日志与结构约束——这是最常被忽略的前提。
物化视图日志必须显式包含分区键字段
Oracle 对分区表做 FAST 刷新时，MATERIALIZED VIEW LOG 不仅要带 WITH PRIMARY KEY 或 WITH ROWID，还必须确保分区键列出现在日志中（即使它不是主键）。否则 REFRESH FAST 会静默退化为 COMPLETE，且不报错。
- 错误写法：
CREATE MATERIALIZED VIEW LOG ON sales PARTITION BY RANGE (sale_date) WITH PRIMARY KEY;—— 如果sale_date不是主键，该语句虽能执行，但日志不记录分区键变更，增量无效 - 正确写法：
CREATE MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY, ROWID, SEQUENCE(sale_date, cust_id) INCLUDING NEW VALUES;—— 显式把分区键sale_date和关键业务字段加入SEQUENCE - 验证方式：查
USER_MVIEW_LOGS的LOG_TABLE，再查对应MLOG$_SALES是否含SALE_DATE列
远程查询必须避免跨分区谓词失效
物化视图定义里的 SELECT 语句若含动态分区裁剪条件（如 WHERE sale_date >= TRUNC(SYSDATE) - 7），会导致每次刷新时基表扫描范围变化，破坏 FAST 刷新所需的“确定性增量边界”。
- 现象：第一次刷新成功，后续刷新报
ORA-12052: cannot fast refresh materialized view - 根本原因：
DBMS_MVIEW.EXPLAIN_MVIEW检测到查询谓词无法稳定映射到物化视图日志中的变更行 - 解法：移除所有依赖运行时函数的 WHERE 条件；如需按时间过滤，改用物化视图日志本身的时间戳字段（如
M_ROW$$或自定义LAST_MODIFIED）做后过滤
分区交换后必须手动重建物化视图日志
对源表执行 EXCHANGE PARTITION 后，原分区数据进入新段，但物化视图日志仍指向旧段的变更记录。此时日志不再捕获该分区的新变更，增量同步中断。
- 典型误操作：交换完立即刷新物化视图，结果只刷了其他分区，刚交换进来的分区数据“消失”
- 必须动作：交换后，在源库立刻执行
DROP MATERIALIZED VIEW LOG ON sales+CREATE MATERIALIZED VIEW LOG ...（参数保持完全一致） - 注意：
ALTER MATERIALIZED VIEW LOG ... ADD不支持分区表场景，只能重建
刷新策略要避开高并发分区维护窗口
分区表常在凌晨执行 ADD PARTITION、SPLIT PARTITION 等 DDL，而物化视图刷新若恰好在此期间运行，可能因锁争用失败或读取到不一致元数据，导致 ORA-12008 或部分刷新丢失。
- 推荐做法：将物化视图刷新 JOB 的执行时间错开分区维护窗口至少 15 分钟
- 更稳妥方式：改用
ON DEMAND+ 外部调度器（如 Oracle Scheduler 或 OS cron），并在刷新前加检查：SELECT COUNT(*) FROM USER_TAB_PARTITIONS WHERE TABLE_NAME = 'SALES' AND HIGH_VALUE LIKE '%SYSDATE%'，确认无进行中的自动分区操作 - 不要依赖
ON COMMIT：分布式环境下，跨 DBLINK 的ON COMMIT刷新会触发ORA-12054，强制禁用
分区表上的物化视图增量同步，真正难的不是语法，而是日志字段与分区行为的对齐——哪怕漏掉一个 SEQUENCE 列，或一次未重建的日志，都会让“增量”变成“全量”，且问题往往延迟数小时才暴露。
