Oracle物化视图不支持按分区设置不同刷新周期
开门见山，先说一个明确的结论：在Oracle的原生架构里，你找不到“为物化视图的不同分区配置独立刷新频率”这个功能。这意味着，你无法实现诸如让mv_tab的partition p1每天刷新一次，而partition p2却每小时刷新一次的想法。这种精细到分区粒度的刷新调度，在Oracle物化视图的设计中并不存在。
其根本原因在于，物化视图本质上是一个逻辑对象。它的刷新操作是针对整个视图结果集进行的。底层的基表分区只是一种数据存储和组织方式，物化视图本身并不感知，也无法控制到这一层的独立刷新调度。
实际可行的替代方案：用多个物化视图 + 分区裁剪模拟
那么，如果业务上确实存在“冷热数据分区需要不同更新频率”的需求（比如，最近7天的数据需要高频更新，而历史分区只需每月同步一次），该怎么办？一个切实可行的替代方案是：创建多个物化视图，每个视图通过查询谓词绑定到特定的数据范围，再配合分区裁剪技术和独立的调度任务。
- 创建一个“热”数据物化视图
mv_hot，其定义为SELECT * FROM t WHERE dt >= TRUNC(SYSDATE) - 7。然后，通过DBMS_MVIEW.REFRESH或调度器，将其设置为每小时刷新一次。 - 再创建一个“冷”数据物化视图
mv_cold，定义为SELECT * FROM t WHERE dt < TRUNC(SYSDATE) - 7。通过DBMS_SCHEDULER安排它在每月1日凌晨执行一次完整的刷新DBMS_MVIEW.REFRESH('mv_cold', 'C')。 - 这里有个关键前提：确保基表
t在dt列上进行了分区，并且上述物化视图的查询条件能够有效触发分区裁剪。务必查看EXPLAIN PLAN，确认执行计划中间出现了partition start/end，而非全表扫描。 - 这两个物化视图可以共享基表
t上的同一份物化视图日志。但需要注意：在ROWID基础刷新模式下，mv_hot和mv_cold都必须声明为BUILD IMMEDIATE，并且启用FAST刷新支持。
为什么不能靠 DBMS_SCHEDULER 给单个 MV “分时段刷不同分区”？
有些朋友可能会想，能否通过更精细的调度脚本来实现呢？比如，写一个PL/SQL过程，尝试执行ALTER MATERIALIZED VIEW mv_name MODIFY PARTITION p1 REFRESH FAST。遗憾的是，这条路走不通——Oracle会直接报错ORA-00922: missing or invalid option，因为物化视图的DDL语法根本不支持MODIFY PARTITION子句。
另一个常见的误区是试图利用DBMS_MVIEW.REFRESH过程的list参数来传入分区名，例如list => 'P1,P2'。需要明确的是，这个参数接收的是物化视图名称的列表，而不是分区名。如果你真的传入了分区名，将会收到ORA-12003: materialized view "SCHEMA"."P1" does not exist这样的错误。
说到底，真正决定物化视图“刷新哪些数据”的，只有两个核心因素：一是物化视图定义中的WHERE条件；二是基表是否创建了物化视图日志，并满足快速刷新所需的各种约束（如主键、ROWID等）。物理分区的布局，并不直接参与刷新逻辑的控制。
关键检查点：避免刷新失效或全量重刷
采用拆分多个物化视图的方案虽然灵活，但细节上若处理不当，很容易导致性能问题甚至刷新失败。以下几个检查点至关重要：
- 确保分区裁剪稳定生效：仔细检查每个物化视图的
SELECT语句，确保查询谓词能稳定命中目标分区。要避免在分区键上使用函数（如TO_CHAR(dt, 'YYYYMMDD')），否则分区裁剪会失效，导致每次刷新都扫描全表。 - 物化视图日志必须唯一：所有基于同一基表的物化视图，必须共享同一份物化视图日志。如果为每个MV分别创建日志，基表的DML变更会被重复捕获，可能引发
ORA-12048等错误。 - 注意快速刷新的子集条件：当使用
FAST刷新时，如果存在多个MV，Oracle要求它们的查询文本彼此之间存在“子查询关系”。一个稳妥的实践是，让mv_hot和mv_cold的查询谓词使用互斥且无缝衔接的范围（例如dt >= X和dt < X），避免范围出现空隙或重叠。 - 确认刷新模式：在部署调度前，务必查询
USER_MVIEWS视图中的REFRESH_MODE和REFRESH_METHOD字段，确保它们不是COMPLETE。一旦被设置为完全刷新，无论你的调度多么精细，每次执行都将是代价高昂的全量重建。
最后提醒一点：千万不要以为基表加了分区，物化视图的刷新就会自动优化。物化视图的刷新路径完全由其查询定义和物化视图日志的结构决定，与底层的物理分区布局没有直接关系。因此，亲手验证执行计划，并查看DBA_MVIEW_ANALYSIS视图中关于FAST_REFRESHABLE的状态，是必不可少的步骤。
