Oracle 12c不支持直接按分区刷新物化视图，所谓“分区增量刷新”实为FAST刷新时依托ROWID、SEQUENCE$$和SNAPTIME$$三要素，结合PCT机制与显式分区键参与，实现日志范围裁剪；否则仍全扫MLOG$表。
Oracle 12c 不支持直接按分区刷新物化视图（即没有 REFRESH FOR PARTITION 语法），所谓“分区增量刷新”本质是让 FAST 刷新逻辑只处理与目标分区相关的日志条目，这依赖于日志结构、时间戳水位和分区键的显式参与，三者缺一不可。
物化视图日志必须含 ROWID + SEQUENCE + SNAPTIME$$
仅靠 PRIMARY KEY 日志无法支撑分区粒度过滤。FAST 刷新时 Oracle 需要通过 ROWID 定位变更行在源表中的物理位置，再结合分区键值反查所属分区；SEQUENCE$$ 字段用于去重和排序，避免同一事务内多条日志乱序；而 SNAPTIME$$ 是唯一能被 DBMS_MVIEW.REFRESH 识别的水位标记字段——它不是时间戳本身，而是 MV 自己维护的“已消费到哪一刻”的指针。
常见错误现象：CREATE MATERIALIZED VIEW LOG ON t WITH PRIMARY KEY; 看似合法，但后续刷新仍全扫 MLOG$_t，因为缺失 ROWID 导致无法做分区范围裁剪。
- 建日志必须显式写
WITH ROWID, SEQUENCE，不能省略 -
INCLUDING NEW VALUES必须加上，否则 UPDATE 场景下旧值丢失，OLD_NEW$$ = 'O'记录缺失，FAST 会静默退化为 COMPLETE - 确认基表分区键列（如
sale_date）在日志中被显式包含：建日志时需加INCLUDING (sale_date)
物化视图定义必须满足 PCT 三硬性前提
PCT（Partition Change Tracking）是 Oracle 唯一允许“局部感知”的机制，但它不是开关，而是一套强约束条件。不满足任意一条，MV 就无法利用分区信息缩小日志扫描范围，FAST 刷新仍会全量读 MLOG$_t。
典型不满足场景：SELECT product_id, SUM(amount) FROM sales GROUP BY product_id —— 查询里没出现分区键 sale_date，即使表按该列 RANGE 分区，PCT 也完全失效。
- 基表必须是单列 RANGE 或 LIST 分区（不能是 HASH、COMPOSITE）
- MV 查询的
SELECT列表和GROUP BY子句中，必须显式包含且仅包含该分区键列 - 创建 MV 时必须指定
ENABLE QUERY REWRITE和PCT（即CREATE MATERIALIZED VIEW ... PCT ENABLE QUERY REWRITE AS ...）
刷新时无法指定分区，只能靠 SNAPTIME$$ + ROWID 联合过滤
你不能执行 DBMS_MVIEW.REFRESH('MV_SALES', 'F', '', FALSE, TRUE, 0, 0, FALSE, 'SALES_P202609'); —— 这种语法在 Oracle 12c 中非法。所谓“针对某分区刷新”，实际是靠两次人工干预完成：
第一次：手动把该分区对应的数据块 ROWID 范围提取出来（例如用 SELECT DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) FROM sales PARTITION (SALES_P202609) WHERE ROWNUM = 1 推算边界）；
第二次：在刷新前，临时更新 MLOG$_sales 中匹配该 ROWID 范围且 SNAPTIME$$ = TO_DATE('4000-01-01', 'YYYY-MM-DD') 的记录，将其 SNAPTIME$$ 设为一个新时间点（如 SYSDATE - 1/24），再调用 DBMS_MVIEW.REFRESH(..., 'F')。这样刷新过程只会处理这批被“提前标记”的日志。
- 此操作必须在单用户或维护窗口执行，否则并发 DML 可能写入新日志并覆盖你的标记
- 刷新后务必检查
SELECT COUNT(*) FROM MLOG$_sales WHERE SNAPTIME$$ > (SELECT LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_SALES')是否非零，否则说明日志未被真正消费 - 若刷新失败，
SNAPTIME$$不会自动回滚，必须人工重置为TO_DATE('4000-01-01', 'YYYY-MM-DD')，否则下次刷新跳过全部日志
性能瓶颈往往卡在 MLOG$ 全表扫描而非分区逻辑
即使你严格满足了 PCT 所有前提，只要 MLOG$_sales 表缺乏合适索引，FAST 刷新仍会因全表扫描 + 排序去重而卡住。Oracle 不会自动为日志表建索引，也不识别分区键在日志中的语义。
验证方法：执行刷新时查 V$SESSION_WAIT，若等待事件是 db file scattered read 且 SQL 文本含 MLOG$_sales，基本可判定是日志扫描问题。
- 必须手动在
MLOG$_sales上建复合索引：CREATE INDEX idx_mlog_sales_ts_rid ON MLOG$_sales (SNAPTIME$$, M_ROW$$) TABLESPACE users; - 如果使用
ROWID日志，M_ROW$$是 VARCHAR2(255)，索引效率低于原生 ROWID，但仍是必要折中 - 定期清理过期日志：
DELETE FROM MLOG$_sales WHERE SNAPTIME$$ ，并及时 <code>ANALYZE TABLE MLOG$_sales COMPUTE STATISTICS;
最易被忽略的一点：SNAPTIME$$ 的精度是 DATE 类型（秒级），如果你的业务在一秒内发生大量 DML，这些变更在日志里会共享同一个 SNAPTIME$$ 值。这意味着哪怕你只想要某个分区的增量，只要它和其它分区的变更落在同一秒，就会被一并拉进本次刷新——这是 Oracle 时间戳机制固有的粒度限制，无法绕过。
