物化视图日志写入慢，先检查MLOG$表是否位于高争用表空间，应迁至LOCAL+AUTOALLOCATE的专用SSD表空间；删除冗余索引，仅保留Oracle自建的I_MLOG$_xxx和I_SNAP$_xxx；禁用ROW MOVEMENT与COMPRESS；批量DML时启用ATOMIC_REFRESH=>FALSE缓解刷新阻塞。
物化视图日志写入慢，先看 MLOG$ 表是否在高争用表空间上
oracle 物化视图日志本质是一张普通堆表（如 user_mview_logs 查到的基表名对应 mlog$_xxx），其插入性能直接受所在表空间的 io 能力与段管理方式影响。常见误配是把所有日志表和业务表混放在同一 system 或 users 表空间，而该表空间可能使用手动段空间管理（manual）或未开启 autoallocate，导致频繁递归 sql 分配区段、产生大量 enq: tx - row lock contention 或 log file sync 等待。
- 确认日志表位置：
SELECT table_name, tablespace_name FROM user_tables WHERE table_name LIKE 'MLOG$%'; - 检查表空间类型：
SELECT tablespace_name, extent_management, allocation_type FROM dba_tablespaces WHERE tablespace_name = 'XXX';—— 优先选LOCAL+AUTOALLOCATE - 避免与业务数据共用表空间；专设一个高速 SSD 表空间（如
MVLOG_TBS），并用ALTER TABLE mlog$_xxx MOVE TABLESPACE mvlog_tbs;迁移
CREATE MATERIALIZED VIEW LOG 时加了多余索引？立刻删掉
Oracle 默认为物化视图日志表创建两个索引：I_MLOG$_xxx（主键/唯一约束隐式索引）和 I_SNAP$_xxx（用于快速刷新的 SNAPTIME$$ 字段）。但很多 DBA 手动再建 ON (seq$$) 或 ON (snaptime$$, dmltype$$) 索引，反而加重 DML 开销——每次 INSERT 到 MLOG$ 都要维护多个索引块，尤其在 OLTP 场景下极易出现 db file sequential read 和 latch: cache buffers chains 等等待。
- 查冗余索引：
SELECT index_name, column_name FROM user_ind_columns WHERE table_name LIKE 'MLOG$%' ORDER BY index_name, column_position; - 只保留 Oracle 自建的两个索引；其余一律
DROP INDEX xxx; - 若需按时间范围快速清理日志（如
DBMS_MVIEW.PURGE_LOG），可考虑对SNAPTIME$$单独建一个非唯一索引（非必须），但不要加INCLUDE或组合字段
日志表 ROW MOVEMENT 和 COMPRESS 会拖慢 INSERT
ROW MOVEMENT 启用后，Oracle 在更新日志行（极少见）或执行分区维护时会触发额外行迁移逻辑；而 COMPRESS FOR OLTP 对 MLOG$ 这类高频小插入场景毫无收益，反而因压缩单元（CU）锁定和解压开销显著拉高 CPU 与 latch 争用。实测中，启用这两项常使单条日志插入耗时从 0.2ms 升至 1.5ms+。
- 检查状态：
SELECT table_name, row_movement, compression FROM user_tables WHERE table_name LIKE 'MLOG$%'; - 禁用移动：
ALTER TABLE mlog$_xxx DISABLE ROW MOVEMENT; - 关闭压缩：
ALTER TABLE mlog$_xxx NOCOMPRESS;（即使原为BASIC或OLTP） - 注意：修改后无需重建索引，但建议在低峰期执行
批量 DML 导致日志堆积？用 DBMS_MVIEW.REFRESH 的 ATOMIC_REFRESH => FALSE 缓解
当基表发生大批量 UPDATE/DELETE（如 ETL 加载），物化视图日志会瞬间涌入数万条记录，而默认刷新行为（ATOMIC_REFRESH => TRUE）会在刷新前清空日志表，引发长事务 + 大量 UNDO + 全表扫描 MLOG$。此时日志写入本身未必慢，但“慢感”来自刷新卡住，连带阻塞后续 DML 的日志写入。
- 排查方法：查
v$session_longops中是否有Refresh materialized view类型长时间操作 - 刷新时显式指定：
DBMS_MVIEW.REFRESH('MV_NAME', METHOD => 'FAST', ATOMIC_REFRESH => FALSE); - 这会让刷新跳过 truncate，改用
DELETE WHERE snaptime$$ = ...，降低锁粒度与 UNDO 压力 - 副作用：需确保
SNAPTIME$$字段有索引（见第二部分），否则 DELETE 变全表扫描
真正卡点往往不在 SQL 写法，而在日志表的物理属性和基础配置——比如表空间用了 LMT 但 INITIAL 设成 64K，导致每插入 100 行就触发一次区扩展；又或者 DBA 为了“安全”给所有日志表加了 FLASHBACK ARCHIVE，却忘了它会强制开启行移动和额外日志捕获。这些细节不查 DBA_TABLES 和 DBA_SEGMENTS，光看 AWR 报告根本找不到根因。
