单个物化视图无法实现分区差异化调度，因其刷新作用于整个结果集且不感知分区边界；必须通过多个mv按谓词拆分并配独立调度任务实现。
oracle物化视图无法按分区自动维护，必须靠多个mv + 独立调度模拟分区级刷新节奏。 你不能对单个物化视图的某个分区设为每小时刷、另一个设为每月刷——ddl 不支持 modify partition ... refresh，dbms_mview.refresh 的 list 参数也只认 mv 名，不认分区名。
为什么单个 MV 无法实现分区差异化调度
物化视图是逻辑快照，刷新操作作用于整个结果集，与底层基表是否分区无关。Oracle 在执行 DBMS_MVIEW.REFRESH 时，会根据 MV 定义的查询 + 物化视图日志（MLOG$）计算变更集，不感知分区边界。常见错误包括：
- 误写
ALTER MATERIALIZED VIEW mv_name MODIFY PARTITION p1 REFRESH FAST→ 直接报ORA-00922: missing or invalid option - 传
list => 'P1,P2'给DBMS_MVIEW.REFRESH→ 报ORA-12003: materialized view "SCHEMA"."P1" does not exist - 在 MV 查询中对分区键用函数包裹，如
WHERE TO_CHAR(dt, 'YYYYMM') = '202604'→ 分区裁剪失效，每次刷新都扫全表
用多个 MV 拆分 + DBMS_SCHEDULER 实现分区级节奏
真实可行的方案是：按业务热度或时间范围，拆出多个物化视图，各自绑定谓词，再配独立调度任务。例如：
-
mv_hot：定义为SELECT * FROM sales WHERE dt >= TRUNC(SYSDATE) - 7，建在sales(dt)范围分区表上 -
mv_cold：定义为SELECT * FROM sales WHERE dt - 两个 MV 共享同一张物化视图日志：
CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE (dt) INCLUDING NEW VALUES; - 调度 hot：每小时调一次
DBMS_MVIEW.REFRESH('mv_hot', 'F') - 调度 cold：每月 1 日凌晨调
DBMS_MVIEW.REFRESH('mv_cold', 'C')（冷数据校验用全量更稳妥）
关键检查点：EXPLAIN PLAN 确认每个 MV 查询的 partition start 和 partition stop 是具体分区号，不是 KEY(INLIST) 或 ALL。
调度任务配置要注意原子性与日志清理
用 DBMS_SCHEDULER 创建作业时，容易忽略三个实际影响：
-
ATOMIC_REFRESH => FALSE可显著提速大分区刷新（跳过 truncate+insert 的事务包装），但若刷新中途失败，mv_hot可能变空——仅建议在有监控和重试机制时启用 - 物化视图日志（
MLOG$）必须定期清理，否则快速刷新卡在排序去重阶段：执行DBMS_MVIEW.PURGE_LOG('sales', 1)保留最近 1 天日志 - 所有 MV 必须共用一份日志；若分别为
mv_hot和mv_cold单独建日志，DML 变更会被重复捕获，引发ORA-12048
最易被忽略的是谓词写法与分区裁剪的耦合关系：哪怕只是多套一层 NVL(dt, SYSDATE)，优化器就可能放弃裁剪。上线前务必用 EXPLAIN PLAN FOR SELECT * FROM mv_hot 看实际访问分区范围，而不是只信“看起来写了 WHERE dt > …”。
