物化视图快速刷新卡在MLOG$扫描阶段，主因是日志全量扫描+排序去重引发性能瓶颈；需建复合索引、更新统计信息、定期清理日志；按分区刷新需依赖ROWID/SEQUENCE日志与SNAPTIME$$时间戳间接控制；ATOMIC_REFRESH=FALSE可提速但有清空风险；定位阻塞需查V$SESSION_WAIT、SQL文本及SNAPTIME$$精度问题。
物化视图对分区表执行快速刷新时，为什么总卡在 MLOG$ 扫描阶段？
因为 oracle 快速刷新依赖物化视图日志（mlog$），而大规模分区表更新后，日志条目可能达百万级，dbms_mview.refresh 默认会全量扫描日志基表并排序去重——这一步在无合适索引或统计信息过期时极易演变为全表扫描+磁盘排序，响应时间飙升。
实操建议：
- 确认日志表
user_mview_logs中对应日志是否已建复合索引：CREATE INDEX idx_mlog_seq ON <log_table_name> (snaptime$$, sequence$$) TABLESPACE <fast_io_ts>;</fast_io_ts></log_table_name> - 执行
EXEC DBMS_STATS.GATHER_TABLE_STATS(user, '<log_table_name>');</log_table_name>更新统计信息，避免优化器误选嵌套循环 - 若日志中存在大量已消费但未清理的记录，手动触发清理：
EXEC DBMS_MVIEW.PURGE_LOG('<master_table>', 1);</master_table>（数字为保留天数）
如何把一次全量刷新拆成按分区粒度的增量刷新？
Oracle 原生不支持「按指定分区刷新」，但可通过 DBMS_MVIEW.REFRESH 的 list 参数 + 分区级物化视图日志过滤实现逻辑拆分。
前提条件：
- 主表必须是范围/列表/组合分区，且物化视图日志启用
ROWID和SEQUENCE（建日志时加WITH ROWID, SEQUENCE） - 物化视图定义中不能含聚合、连接或
ROWNUM等阻止分区感知的结构
操作步骤：
- 查出待刷新的分区名：
SELECT partition_name FROM user_tab_partitions WHERE table_name = '<master_table>' AND high_value LIKE '%2024-06%';</master_table> - 构造分区级谓词，用于限制日志扫描范围：
WHERE mview_log_rowid IN (SELECT ROWID FROM <master_table> PARTITION (<part_name>))</part_name></master_table> - 调用刷新时传入分区键值（需与日志中
SNAPTIME$$对齐）：DBMS_MVIEW.REFRESH(list => '<mv_name>', method => 'F', rollback_seg => NULL, refresh_after_errors => FALSE, atomic_refresh => FALSE);</mv_name>—— 注意：这不是直接传分区名，而是靠预置的SNAPTIME$$时间戳区间间接控制
ATOMIC_REFRESH=FALSE 在分区刷新中到底要不要开？
要开，但仅限于大分区刷新场景。它让刷新跳过临时表创建和原子性事务包装，直接 truncate + insert append，减少 UNDO 和 REDO 压力。
风险点很具体：
- 刷新失败时，物化视图处于空表状态，下游查询会报
ORA-01403: no data found或返回空结果，而非旧数据 - 若物化视图被其他会话正在查询，
TRUNCATE可能引发ORA-00054: resource busy - 分区表刷新中，若只刷部分分区，
ATOMIC_REFRESH=FALSE仍会清空整张 MV 表——所以它只适用于「整表刷新但按分区批次提交」的模式，而非真正意义上的分区局部刷新
更稳妥的做法是：用 ATOMIC_REFRESH=TRUE + PARALLEL 提升速度，同时在业务低峰期执行，并确保应用层有降级兜底（如缓存 fallback）。
刷新任务卡住时，怎么快速定位是物化视图本身的问题还是底层分区 DML 导致的阻塞？
先看 V$SESSION_WAIT 和 V$LOCK，重点过滤等待事件为 enq: TX - row lock contention 或 DFS lock handle 的会话。
关键诊断命令：
- 查刷新会话正在等哪个对象：
SELECT blocking_session, event, sql_id FROM v$session WHERE sid = <refresh_sid>;</refresh_sid> - 查该会话当前 SQL 是否在扫
MLOG$：SELECT sql_text FROM v$sql WHERE sql_id = '<sql_id>';</sql_id>（常见特征是含FROM <log_table> WHERE snaptime$$ ）</log_table> - 查主表分区是否有长时间未提交的 DML：
SELECT s.sid, s.sql_id, p.spid, s.event FROM v$session s JOIN v$process p ON s.paddr = p.addr WHERE s.sql_id IN (SELECT sql_id FROM v$sql WHERE sql_text LIKE '%<master_table>%') AND s.status = 'ACTIVE';</master_table>
最容易被忽略的是：物化视图日志的 SNAPTIME$$ 字段默认类型为 DATE，精度仅到秒。当主表在一秒内发生多次 DML，日志记录可能因时间戳相同而被快速刷新逻辑重复处理或漏处理——这种隐式竞争在高并发分区写入场景下会放大延迟，必要时可考虑将日志表 SNAPTIME$$ 改为 TIMESTAMP(6) 并重建日志（需停业务）。
