oracle范围分区物化视图无法自动对齐基表数据生命周期，必须人工干预日志结构、分区键暴露及交换后重建三环节，否则将出现新分区数据不进mv、归档分区残留、fast刷新退化等问题。
Oracle范围分区物化视图本身不会自动对齐基表的数据生命周期——必须靠人工干预+配套机制协同，否则极易出现「新分区数据不进MV」「归档分区在MV里残留」「FAST刷新静默退化」三类问题。
物化视图日志必须显式包含分区键字段
这是最常被忽略的前提。即使基表按 sale_date 范围分区，物化视图日志若没把该列纳入变更捕获，FAST刷新就无法识别新增分区的增量行。
- 错误写法：
CREATE MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY;——sale_date不是主键，日志里没有它，后续插入新月份数据不会触发增量同步 - 正确写法：
CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE(sale_date, order_id) INCLUDING NEW VALUES;—— 显式声明分区键和业务主键，确保日志表MLOG$_SALES中存在SALE_DATE列 - 验证方式：
SELECT * FROM USER_MVIEW_LOGS WHERE MASTER = 'SALES';查LOG_TABLE名，再查对应日志表结构确认含SALE_DATE
间隔分区（INTERVAL）下物化视图无法自动感知新分区
Oracle 自动建的新分区（如每月一个）不会自动注册到物化视图的刷新上下文中。物化视图仍按旧分区边界扫描，导致新分区数据被跳过或全量刷错范围。
- 现象：
INSERT INTO sales VALUES (DATE '2026-10-01', ...)后执行DBMS_MVIEW.REFRESH('MV_SALES')，但新数据未进 MV - 根本原因：物化视图定义时未绑定分区键列，优化器无法推导新分区是否属于当前查询谓词覆盖范围
- 解法：物化视图 SELECT 必须包含分区键列（如
SELECT sale_date, ... FROM sales），且 WHERE 条件直接引用该列（不能用TRUNC(sale_date)或函数包裹） - 补充动作：每次新增分区后，建议手动执行一次
DBMS_MVIEW.REFRESH_DEPENDENT扫描依赖关系，避免元数据滞后
分区交换（EXCHANGE PARTITION）后物化视图日志失效
这是数据生命周期管理中最危险的一环。交换操作让原分区物理段脱离基表，但物化视图日志仍指向旧段地址，导致该分区后续所有变更完全丢失。
- 典型误操作：执行
ALTER TABLE sales EXCHANGE PARTITION p_202609 WITH TABLE sales_arch_202609后立刻刷新 MV → 刚交换进来的历史数据“消失” - 必须动作：交换完成后立即重建日志 ——
DROP MATERIALIZED VIEW LOG ON sales;+ 完全一致参数的CREATE语句 - 注意：
ALTER MATERIALIZED VIEW LOG ADD ...不支持分区表场景，只能重建，且重建期间禁止对该表做 DML - 自动化建议：把日志重建逻辑封装进分区维护脚本，与
EXCHANGE操作绑定为原子步骤
真正能“对齐生命周期”的不是物化视图本身，而是你对日志结构、分区键暴露、交换后重建这三件事的控制粒度。漏掉任何一环，数据就可能在某个时间点开始漂移。
