物化视图日志（MLOG$_）会因高频DML和未及时消费而持续膨胀，引发全表append写入、无索引扫描、ITL争用及归档激增，拖慢Checkpoint导致脏块堆积、log file sync上升和ORA-01555风险。
刷新频率过高会直接加剧物化视图日志（mlog$_）的写入压力，并干扰checkpoint机制的稳定推进，最终表现为io等待飙升、归档暴增、甚至实例恢复变慢。
物化视图日志写入如何放大IO压力
每次源表发生INSERT/UPDATE/DELETE，Oracle都必须在对应的MLOG$_xxx表中插入一条变更记录——前提是该表建了物化视图日志且启用了INCLUDING NEW VALUES。高频刷新本身不写日志，但高频DML+未及时消费日志，会让MLOG$_持续膨胀：
- 日志表无主键、无索引，
INSERT走全表append，大量单块写（db file sequential read） - 刷新任务频繁扫描
MLOG$_做MIN(snaptime$$)定位，触发大量逻辑读和buffer busy waits - 若日志表所在表空间使用ASSM，高并发插入易引发
enq: TX - allocate ITL entry争用 - 归档日志量同步激增：每条日志记录都生成redo，
MLOG$_每增长1GB，归档通常增加0.8~1.2GB
为什么Checkpoint会受拖累
Checkpoint的核心目标是推动DBWn将脏块刷盘，并更新控制文件中的on-disk RBA。而物化视图日志表本身也是“用户数据”，它的频繁修改会产生大量脏块。当MLOG$_写入速率超过DBWn的刷盘能力时：
- Checkpoint queue尾部不断前移，CKPT进程每3秒在控制文件中记录的
low RBA滞后于实际变更点 - DBWn忙于刷
MLOG$_脏块，延迟处理其他对象（如业务表、索引）的脏块，导致整体dirty buffer堆积 -
log file sync等待上升：事务提交需等待redo落盘，而CKPT滞后会间接拉长redo buffer flush周期 - 极端情况下触发
ORA-01555：查询需要回滚到过去SCN，但对应undo块已被覆盖，因DBWn未及时刷出旧版本数据块
如何确认是物化视图日志拖慢Checkpoint
别只盯着v$sysstat里background checkpoints completed计数。真问题藏在时间差里：
- 查
v$database的CHECKPOINT_CHANGE#和LAST_CHANGE#，若差值长期＞10万SCN，说明Checkpoint追不上 - 运行
SELECT * FROM v$archive_dest WHERE destination IS NOT NULL，看ARCHIVED_THREAD#是否持续卡住或ERROR列有ORA-00257 - 抓取AWR报告，重点看
Top 5 Timed Foreground Events中是否出现db file parallel write+log file sync双高 - 执行
SELECT owner, segment_name, bytes/1024/1024 mb FROM dba_segments WHERE segment_name LIKE 'MLOG$%' ORDER BY mb DESC，若单个日志表＞5GB，基本就是IO瓶颈源
最常被忽略的一点：MLOG$_表即使没被任何物化视图引用，只要没删日志定义，它就仍会接收DML变更记录——因为日志创建后，触发器已植入基表。清理必须用DBMS_MVIEW.PURGE_LOG或重建日志，不能只删数据。
