Oracle 19c不支持直接按分区刷新物化视图，所谓“单分区刷新”实为通过ROWID范围与SNAPTIME$$精准控制日志消费窗口，仅处理目标分区变更，需满足日志含ROWID+SEQUENCE、关键列全包含、MV无聚合/子查询等严苛前提。
Oracle 19c 不支持直接“按分区刷新物化视图”
物化视图本身没有分区概念（即使基表是分区表），DBMS_MVIEW.REFRESH 也不接受 PARTITION 参数。所谓“单分区刷新”，本质是**绕过默认全量日志扫描逻辑，用谓词限制增量变更范围**，只处理与某分区相关的日志条目。这需要基表、日志、MV 定义三者严格配合，否则会退化为 COMPLETE 刷新或报错。
前提条件：日志必须含 ROWID + SEQUENCE 且覆盖关键列
不满足以下任一条件，FAST 刷新会静默失败，无法实现分区级控制：
- 建日志时明确指定
WITH ROWID, SEQUENCE（不能只靠PRIMARY KEY） -
SEQUENCE()中必须包含所有 JOIN 列、WHERE 过滤列和分区键列（例如SEQUENCE(deptno, loc, snaptime$$)） - 基表分区键字段必须出现在物化视图 SELECT 列中，且日志中该字段被
INCLUDING NEW VALUES覆盖 - 物化视图定义中不能含子查询、外连接、聚合、
DISTINCT或分析函数
实操步骤：用 SNAPTIME$$ + 分区 ROWID 范围过滤日志
核心思路是让刷新过程只读取“该分区产生的变更日志”，而非全表扫描 MLOG$_xxx：
- 先查出目标分区的
ROWID范围：SELECT MIN(ROWID), MAX(ROWID) FROM <master_table> PARTITION (<part_name>)</part_name></master_table> - 确认日志中最新消费时间：
SELECT SNAPTIME$$ FROM USER_SNAPSHOT_LOGS WHERE LOG_TABLE = '<mlog_name>'</mlog_name> - 手动更新日志消费位点（关键！）：
UPDATE <mlog_table> SET SNAPTIME$$ = SYSDATE WHERE ROWID BETWEEN '<min_rid>' AND '<max_rid>' AND SNAPTIME$$ = <old_snaptime>;</old_snaptime></max_rid></min_rid></mlog_table>（需 COMMIT） - 调用刷新：
DBMS_MVIEW.REFRESH(list => '<mv_owner>.<mv_name>', method => 'F', atomic_refresh => FALSE);</mv_name></mv_owner>
注意：atomic_refresh => FALSE 是必须的——它让刷新跳过事务包装，允许对日志做 DML 操作；否则 UPDATE MLOG$ 会被阻塞。
容易卡住的两个典型现象及应对
执行后发现刷新长时间不动，大概率卡在以下环节：
-
TABLE ACCESS BY INDEX ROWID持续耗时 → 检查MLOG$_xxx是否有复合索引：CREATE INDEX idx_mlog_snap_seq ON <mlog_table> (snaptime$$, sequence$$)</mlog_table>，并收集统计信息 -
V$ALL_SQL_PLAN_MONITOR显示output_rows增长极慢 → 实际已退化为 COMPLETE 刷新，立刻查DBMS_MVIEW.EXPLAIN_MVIEW确认fastrefreshable是否为FALSE，重点看子查询或外连接是否混入
真正的“单分区刷新”不是原子操作，而是依赖你精准控制日志消费窗口。一旦 SNAPTIME$$ 更新出错或分区 ROWID 范围不准，后续所有刷新都会偏离预期。
