物化视图在分区表上FAST刷新易退化为COMPLETE，主因是未启用PCT、日志缺失SEQUENCE/ROWID、聚合与分区键映射不稳、分区交换后未调用PARTITION_CHANGING，以及GROUP BY字段未全包含在日志SEQUENCE中。
分区表 + 物化视图组合用得好，能扛住千万级事实表的聚合查询；但配错一个参数，fast refresh直接退化成complete，刷新耗时从秒级变成小时级。
为什么物化视图在分区表上容易刷新失败
常见现象是执行 DBMS_MVIEW.REFRESH 时报错：ORA-12008: error in materialized view refresh path 或隐式回退到完全刷新，却没报错——只看日志才发现用了 COMPLETE 而非预期的 FAST。
根本原因往往不在物化视图定义本身，而在底层分区表与物化视图日志的协同机制：
- 源表必须启用
PCT (Partition Change Tracking)：即建物化视图日志时要显式加INCLUDING NEW VALUES和WITH ROWID, SEQUENCE，且源表需为RANGE或LIST分区（HASH分区不支持 PCT） - 物化视图定义中不能出现跨分区的聚合边界模糊操作，比如
GROUP BY TRUNC(trans_time, 'MM')—— 若某月数据横跨两个分区，PCT 无法准确定位变更范围 - 分区交换（
EXCHANGE PARTITION）后未调用DBMS_MVIEW.PARTITION_CHANGING，会导致后续 FAST 刷新跳过该分区变更记录
如何让 FAST REFRESH 真正生效（含关键 DDL 示例）
不是加了物化视图日志就自动支持增量刷新。必须满足“查询可重写 + 日志完备 + 分区可追踪”三重条件：
- 源表建日志时务必带
PCT支持：CREATE MATERIALIZED VIEW LOG ON sales_partitioned WITH ROWID, SEQUENCE (sale_id, amount, sale_date), INCLUDING NEW VALUES PCT;
- 物化视图创建语句中显式声明
ENABLE QUERY REWRITE和USING NO INDEX（避免索引干扰 PCT 路径判断） - 聚合字段必须与分区键存在确定映射，例如按
sale_date范围分区，则物化视图中应使用TRUNC(sale_date, 'DD')而非TO_CHAR(sale_date, 'YYYY-MM')—— 后者 Oracle 无法保证分区剪枝稳定性 - 刷新时强制指定模式：
DBMS_MVIEW.REFRESH('mv_sales_daily', 'F')中的'F'表示 FAST，避免依赖FORCE的自动降级逻辑
并行刷新与分区裁剪的实操平衡点
开并行不等于快。对分区物化视图，PARALLEL 参数作用对象是「每个分区内的刷新任务」，而非跨分区；盲目设高并发反而引发日志争用和 PGA 溢出。
- 推荐先查当前物化视图分区数：
SELECT COUNT(*) FROM dba_tab_partitions WHERE table_name = 'MV_SALES_DAILY' - 并行度设为分区数的 1–1.5 倍较稳妥，例如 12 个分区，用
DEGREE => 16即可，再高收益递减 - 禁用自动并行（
ALTER SESSION DISABLE PARALLEL DML），改用显式DBMS_MVIEW.REFRESH的parallelism参数控制，避免被其他会话的并行设置干扰 - 若物化视图本身也做了范围分区（如按
stat_date），刷新时加atomic_refresh => FALSE可跳过全表锁，但要求目标分区为空或已 truncate
最容易被忽略的三个一致性陷阱
性能优化常以牺牲部分一致性为代价，但有些坑一旦踩中，连 ON COMMIT 都救不回来：
- 基表发生
ALTER TABLE ... DROP PARTITION后，未同步执行DBMS_MVIEW.REFRESH_DEPENDENT，会导致物化视图元数据残留已删除分区的引用，后续刷新静默失败 - 物化视图日志里
SEQUENCE列未包含所有 GROUP BY 字段（如漏了channel），UPDATE 操作可能被误判为 INSERT+DELETE，引发聚合结果翻倍 - 使用
ON DEMAND刷新时，依赖调度任务（DBMS_SCHEDULER），但未在 job 中显式设置current_schema，导致权限上下文丢失，刷新中途报ORA-01031: insufficient privileges
真正卡住性能的，往往不是 SQL 写得不够炫，而是分区边界、日志字段、刷新上下文这三处细节没对齐。
