物化视图日志（mlog$_xxx）不会自动物理删除行，仅靠snaptime$$标记“已消费”，导致空间持续增长；常见原因包括mv长期未刷新、多mv共享日志时个别滞后、dba_registered_snapshots残留失效记录。
物化视图日志为什么越刷越大
物化视图日志（MLOG$_xxx）不会自动物理删除行，只靠 SNAPTIME$$ 字段标记“已消费”，哪怕所有物化视图都刷新成功了，数据仍留在表里。空间涨到几十GB而基表才几MB，基本就是日志堆积没被真正清理——这不是 bug，是 Oracle 的设计行为。
常见诱因包括：
- 某个物化视图长期未刷新（比如远程站点断连、定时 job 失败且未修复）
- 多个物化视图共享一个日志，但其中一两个刷新滞后，拖慢整体清理边界
-
DBA_REGISTERED_SNAPSHOTS里残留已失效的注册记录，让 Oracle 认为“还有 MV 在用”
怎么判断 MLOG$_xxx 能不能删
不能只查 DBA_MVIEWS 或看物化视图是否存在。必须交叉验证两处元数据：
- 查
DBA_REGISTERED_SNAPSHOTS：执行SELECT * FROM DBA_REGISTERED_SNAPSHOTS WHERE LOG_OWNER = 'OWNER' AND LOG_NAME = 'MLOG$_TABLE_NAME';，返回空才说明没有活跃注册 - 查
DBA_MVIEW_LOGS：确认该日志的LOG_TABLE没被任何现存物化视图引用，尤其注意多 MV 共享场景 —— 要逐个核对MASTER和LOG_TABLE - 导出当前绑定快照留底：
SELECT LOG_OWNER, LOG_TABLE, MASTER, ROWIDS, PRIMARY_KEY FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_EMP';
安全清理的两种路径
误删 sys.mlog$_xxx 表会破坏数据字典，后续建同名 MV 极大概率报 ORA-12003 或刷新失败。合规操作只有两条路：
- 彻底释放空间：执行
DROP MATERIALIZED VIEW LOG ON owner.table_name;—— 这是唯一能真正回收段空间的动作 - 只清已消费旧记录（不释放空间）：用
DBMS_MVIEW.PURGE_MVIEW_FROM_LOG，传入MVIEW_ID（来自DBA_BASE_TABLE_MVIEWS），它按最晚的LAST_REFRESH_DATE划定清理边界，不会碰未消费行
注意：PURGE_MVIEW_FROM_LOG 不降低高水位线（HWM），也不释放物理空间；TRUNCATE TABLE sys.mlog$_xxx 或 DROP TABLE 是高危操作，绝对禁止。
收缩日志表但保留功能的在线方案
如果日志还在被使用，又急需回收空间（比如表空间告警），可考虑在线重定义。前提是 Oracle 版本 ≥ 10g 且 compatible ≥ 10.0.0.0：
- 创建中间表：
CREATE TABLE temp_mlog AS SELECT * FROM mlog$_xxx; - 锁基表并清空日志：
LOCK TABLE owner.table_name IN EXCLUSIVE MODE;→TRUNCATE TABLE mlog$_xxx; - 回填已消费数据：
INSERT INTO mlog$_xxx SELECT * FROM temp_mlog WHERE snaptime$$ - 提交后释放锁：
COMMIT;→ROLLBACK;（在锁表会话中）
这个过程绕开了 DDL 锁，但需精确识别哪些行已被所有活跃 MV 消费——漏判会导致后续刷新报 ORA-12034（日志比上次刷新还新）。
