直接TRUNCATE sys.mlog$_xxx会导致HWM下降但段头块残留元信息，引发ORA-00604异常扩展；DROP TABLE会损坏数据字典致ORA-12083；且TRUNCATE不更新snaptime$$，Oracle仍认为日志有效，空间迅速回升。
直接 TRUNCATE sys.mlog$_xxx 会出什么事
不能这么做。oracle 明确不支持、也不允许直接操作 sys.mlog$_xxx 表：
- truncate 后高水位线（hwm）虽降，但段头块仍残留日志结构元信息，后续插入可能触发异常扩展，甚至报 ora-00604
- drop table 会直接损坏数据字典，再执行 create materialized view log 很可能报 ora-12083
- 日志是否被消费，由 snaptime$$ 字段标记，而非物理行存在；truncate 不改这个标记，oracle 仍认为“日志还在”，下次刷新继续写入，空间很快又涨回来
怎么确认一个 MLOG$_ 表真能删
不能只查有没有物化视图存在，必须交叉验证两个系统视图：
- 查询 DBA_REGISTERED_SNAPSHOTS：若 LOG_OWNER 和 LOG_NAME（如 MLOG$_EMP）组合无返回，说明没有 MV 正在注册使用该日志
- 查询 DBA_MVIEW_LOGS：确认该日志未被其他 MV 引用，尤其注意多个 MV 可共享一个日志，得逐个核对 LOG_TABLE 和 LOG_OWNER
- 执行前务必导出依赖快照：运行 SELECT LOG_OWNER, LOG_TABLE, MASTER, ROWIDS, PRIMARY_KEY FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_EMP'
安全清理旧日志的正确姿势
推荐分批调用 Oracle 原生过程，避免锁表和 UNDO 撑爆：
- 先查时间边界： SELECT MIN(snaptime$$), MAX(snaptime$$) FROM mlog$_xxx
- 按窗口清理： BEGIN DBMS_MVIEW.PURGE_LOG('MASTER_TABLE', 7); COMMIT; END;（数字 7 表示保留最近 7 天）
- 若需按年份清理（如只清 2023 年前），用 PL/SQL 构造循环，每次传入固定天数并 COMMIT
- 切勿 DELETE FROM mlog$_xxx WHERE snaptime$$ —— 它会全表锁、撑 UNDO、易被长事务阻塞
清理完不补这三步，刷新照样慢
删完不是结束，以下三件事必须立刻做：
- 立即收集统计信息：DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'MLOG$_TABLE_NAME')，否则优化器仍走全表扫描
- 检查并重建关键索引：CREATE INDEX idx_mlog_snap_seq ON mlog$_xxx (snaptime$$, sequence$$) —— 这是快速刷新扫描日志的性能命脉
- 若空间仍未释放，mlog$_xxx 不支持 SHRINK SPACE，只能导出数据 → DROP MATERIALIZED VIEW LOG ON owner.table_name → 重建日志
真正卡住人的，从来不是日志表有多大，而是清理后忘了建索引、没更新统计信息、也没确认 snaptime$$ 是否被所有 MV 正确消费——这些细节一漏，问题就原样复现。
