本质是oracle原生不支持refresh for partition语法，所谓“局部刷新”需依赖rowid+sequence日志与snaptime$$时间戳联合过滤，且必须满足pct三硬性前提：单列range/list分区键、mv定义中select和group by均显式包含该键、建mv时启用pct和query rewrite。
快速刷新卡在 MLOG$ 扫描，本质是没做分区感知
Oracle 原生不支持 REFRESH ... FOR PARTITION 语法，所谓“局部刷新”其实是让快速刷新逻辑只处理与某分区相关的日志条目。这要求物化视图日志（MLOG$_YOUR_TABLE）必须含 ROWID 和 SEQUENCE，且刷新时能通过 SNAPTIME$$ 时间戳 + 分区 ROWID 范围联合过滤日志。否则 DBMS_MVIEW.REFRESH 就会默认全扫日志表，百万级条目直接触发磁盘排序。
必须满足的三个硬性前提条件
缺一不可，否则 Oracle 会静默降级为 COMPLETE 刷新：
- 基表是 RANGE/LIST/INTERVAL 分区，且分区键为单列（如
sale_date） - 物化视图定义中
SELECT和GROUP BY都显式包含该分区键（不能用别名、不能隐式转换） - 建物化视图时加
ENABLE QUERY REWRITE和PCT属性（不是可选项）
验证是否真生效：运行 DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')，查 mv_capabilities_table 中 REFRESH_FAST 的 possible 是否为 Y，且 msgtxt 不含 "partition change tracking not supported"。
手动控制扫描范围：靠 ROWID + SNAPTIME$$ 间接实现
即使开了 PCT，大分区批量更新后日志仍可能堆积。这时需主动缩小日志扫描面：
- 先查目标分区名：
SELECT partition_name FROM user_tab_partitions WHERE table_name = 'SALES' AND high_value LIKE '%2026-08%' - 构造谓词限制日志扫描：
WHERE mview_log_rowid IN (SELECT ROWID FROM SALES PARTITION (P202608)) - 关键点：
SNAPTIME$$必须对齐——如果上次刷新时间戳是2026-08-25 14:30:00，新刷就得从这个时间之后取日志，否则漏数据
注意：这不是传分区名给 DBMS_MVIEW.REFRESH，而是靠你在日志表上加 WHERE 条件（需配合自定义刷新过程或改写日志查询逻辑）。
ATOMIC_REFRESH=FALSE 是提速关键，但风险极具体
对大分区执行快速刷新时，设 atomic_refresh => FALSE 可跳过临时表和事务包装，直接 TRUNCATE + INSERT /*+ APPEND */，减少 UNDO 和 REDO 压力。但它不是“更安全的增量”，而是“更快的破坏性覆盖”：
- 刷新成功：数据更新，性能提升明显
- 刷新失败：物化视图变空表，下游查询立刻报
ORA-01403: no data found - 不能用于 ON COMMIT 刷新场景（违反原子性语义）
真正容易被忽略的是：PCT 生效的前提是基表启用了 ROW MOVEMENT（尤其当你要做 EXCHANGE PARTITION 时），而很多 DBA 会漏掉这步，导致后续分区操作失败却找不到原因。
