归档日志暴增主因是物化视图日志表（MLOG$_表）堆积、无人消费，叠加源表DML与刷新操作三重REDO；需先止血（停作业+PURGE_LOG）、再定位（查LAST_REFRESH_DATE、snaptime$$、调度状态）、最后重建链路（验证FAST支持、精准建日志）。
归档日志暴增不是刷新本身出问题，而是物化视图日志（mlog$_表）持续写入但无人消费，叠加源表dml和刷新操作三重redo，直接撑爆归档。必须先止血、再定位、最后重建链路。
查日志表是否真在堆积
别只看告警，先确认是不是MLOG$_表在疯长：
- 执行
SELECT COUNT(*) FROM MLOG$_your_master_table，如果结果远超基表日常变更量（比如基表一天改几百行，日志却有80万条），基本就是它了 - 查
DBA_MVIEW_LOGS中对应记录的LAST_REFRESH_DATE是否为空或明显过期（比如停留在三天前） - 对比
SELECT MAX(snaptime$$) FROM MLOG$_your_master_table和当前时间，差值若超过UNDO_RETENTION（如差45分钟而undo_retention=900），后续FAST刷新大概率报ORA-01555
确认刷新任务是否已中断或禁用
Oracle 11g默认用DBMS_SCHEDULER，老式DBMS_JOB可能早已失效：
- 查调度器状态：
SELECT job_name, state, last_start_date, next_run_date FROM dba_scheduler_jobs WHERE job_name LIKE '%MV%'；若state为DISABLED或next_run_date是异常时间（如4000-01-01），说明任务已被自动停用 - 查
DBA_JOBS（兼容旧作业）：SELECT job, broken, failures, next_date FROM user_jobs WHERE what LIKE '%your_mv_name%'；若BROKEN = 'Y'且NEXT_DATE是4000-01-01，需用DBMS_JOB.BROKEN(job => xxx, broken => FALSE, next_date => SYSDATE)重置 - 手动试一次FAST刷新：
BEGIN DBMS_MVIEW.REFRESH('YOUR_MV_NAME', 'F'); END;；若报ORA-12008，大概率是基表结构变更（如删主键）或日志损坏
安全清积压日志并重建刷新链路
别直接TRUNCATE TABLE MLOG$_xxx——这会破坏数据字典，后续建同名日志可能报ORA-12083或ORA-12003：
- 先停掉所有相关作业：
EXEC DBMS_SCHEDULER.DISABLE('MV_REFRESH_JOB_NAME') - 用官方接口清理：
EXEC DBMS_MVIEW.PURGE_LOG('your_master_table')；它比TRUNCATE安全，会同步更新内部snaptime$$标记 - 重建日志前，务必确认物化视图定义支持FAST：
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('YOUR_MV_NAME')，再查MVIEW_EXCEPTIONS中RECOMMENDATION字段；若提示AGGREGATE或JOIN，说明定义本身不满足FAST条件，强行建日志也没用 - 重建日志时只包含物化视图SQL实际引用的列：
CREATE MATERIALIZED VIEW LOG ON your_master_table WITH SEQUENCE, ROWID (id, status) INCLUDING NEW VALUES；若SQL没用OLD_NEW$，就去掉INCLUDING NEW VALUES
警惕SYSTEM表空间被IDL_UB1$拖垮
归档暴增常伴随SYSTEM表空间告急，但罪魁祸首往往不是MLOG$_表本身（它通常不在SYSTEM），而是IDL_UB1$这类PL/SQL编译缓存表：
-
SELECT segment_name, SUM(bytes)/1024/1024 AS size_mb FROM dba_segments WHERE tablespace_name = 'SYSTEM' GROUP BY segment_name ORDER BY size_mb DESC；若IDL_UB1$排第一，说明频繁FAST刷新触发大量重编译 - 临时缓解可清理PL/SQL缓存：
ALTER SYSTEM FLUSH SHARED_POOL（慎用，影响全局） - 根治要减少不必要的FAST刷新频次，或对稳定物化视图改用
COMPLETE方式（配合atomic_refresh => FALSE降低锁表时间）
真正难处理的不是日志体积本身，而是多个物化视图共享一个MLOG$_表时，清理边界由最晚刷新的那个MV决定——你清得再快，只要有一个MV卡住，积压就永远清不完。
