AWR报告不直接显示MLOG$_表膨胀，但可通过CPU尖刺、逻辑读飙升、TEMP争用及刷新失败告警定位；需检查FAST是否降级为COMPLETE、SQL执行计划突变、snaptime$$堆积窗口，并补全索引与统计信息。
AWR报告本身不直接显示物化视图日志（MLOG$_表）的膨胀，但能精准定位其引发的连锁反应：CPU尖刺、大量逻辑读、TEMP空间争用、刷新失败告警——这些才是你该盯住的信号。
为什么AWR里找不到MLOG$_表的IO或空间消耗
物化视图日志表（如MLOG$_ORDER_ITEMS）物理上属于用户表空间，其读写不计入SYSAUX或SYSTEM，AWR的I/O统计页（如“Tablespace IO Stats”）默认按表空间聚合，不会单独列出每个MLOG$_表。更关键的是，日志膨胀的伤害不在存储本身，而在刷新行为：DBMS_MVIEW.REFRESH执行时对MLOG$_的全表扫描会触发大量db file sequential read和direct path read，这些等待会真实出现在AWR的“Top 5 Timed Events”里。
- 不要在AWR中搜索“MLOG”关键字——它不会出现
- 真正要查的是：FAST刷新是否降级为COMPLETE？看
DBA_MVIEWS里的LAST_REFRESH_DATE和REFRESH_METHOD是否突变 -
MLOG$_表若含未被MV使用的列（如notesCLOB），会导致FAST刷新自动降级，而COMPLETE刷新会扫基表全量，CPU和逻辑读飙升
从AWR的SQL ordered by CPU页反向追踪日志问题
当MLOG$_表因字段冗余或缺失SEQUENCE导致刷新效率崩溃，AWR的“SQL ordered by CPU”页会出现两类典型SQL：
- 一条是
INSERT /*+ APPEND */ INTO "SCHEMA"."MV_NAME" SELECT ... FROM "SCHEMA"."MLOG$_TABLE" WHERE "SNAPTIME$$" <= :1——这是FAST刷新主体，若执行计划走TABLE ACCESS FULLonMLOG$_TABLE，且Rows Processed远超实际变更行数，说明日志里塞了太多无效字段 - 另一条是
DELETE FROM "SCHEMA"."MLOG$_TABLE" WHERE "SNAPTIME$$" <= :1——PURGE_LOG没生效的标志；若该SQL的Executions极低但Elapsed Time Per Exec极高，说明日志表HWM已碎，且没建snaptime$$, sequence$$复合索引 - 检查这两条SQL的
Plan Hash Value是否在波峰时段发生突变：突变前走索引范围扫描，突变后变全表扫描 → 直接指向日志表统计信息过期或索引缺失
用AWR快照时间戳交叉验证日志堆积窗口
MLOG$_表的snaptime$$字段决定了哪些日志可被清理。AWR快照本身不存这个值，但你可以用它锚定问题时段，再切到SQL*Plus做精准查询：
- 先从AWR确认CPU高峰发生在
2026-09-28 14:00–15:00（查dba_hist_snapshot拿到对应START_SNAP_ID/END_SNAP_ID） - 立刻连库执行：
SELECT MIN(snaptime$$), MAX(snaptime$$), COUNT(*) FROM MLOG$_ORDER_ITEMS;—— 若MIN(snaptime$$)是2026-09-25 03:17:22，而当前时间是2026-09-29，说明有近4天日志未被消费，“僵尸数据”已成型 - 再查：
SELECT COUNT(*) FROM MLOG$_ORDER_ITEMS WHERE snaptime$$ > SYSDATE - 1;—— 若结果仅几十行，而总行数百万，证实99%是无效残留 - 注意：这个时间差必须用AWR快照区间来框定，不能凭感觉——比如业务说“昨天下午慢”，但AWR可能显示峰值在快照
2026-09-28 14:00（end_interval_time），真实问题始于13:45左右
清理后AWR里仍慢？三个常被跳过的硬动作
调用DBMS_MVIEW.PURGE_LOG只是开始。若清理后AWR报告中FAST刷新SQL的逻辑读仍居高不下，大概率卡在这三处：
- 没收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS('SCHEMA', 'MLOG$_ORDER_ITEMS')—— 优化器不知道snaptime$$分布极度倾斜，继续选错执行计划 - 没重建关键索引：
CREATE INDEX idx_mlog_snap_seq ON MLOG$_ORDER_ITEMS (snaptime$$, sequence$$)—— 这是FAST刷新扫描日志的唯一高效路径，缺它必全表扫 - 没确认MV注册状态：
SELECT * FROM DBA_REGISTERED_SNAPSHOTS WHERE LOG_OWNER = 'SCHEMA' AND LOG_NAME = 'MLOG$_ORDER_ITEMS';—— 若返回空，说明日志已孤立，应直接DROP MATERIALIZED VIEW LOG ON SCHEMA.ORDER_ITEMS重建，而非反复PURGE
真正难的不是发现日志膨胀，而是意识到snaptime$$不是时间戳而是“刷新水位线”，它不动，PURGE就只是障眼法；索引和统计信息不补，AWR里看到的永远是旧伤疤。
