真正占用存储的是物化视图日志（MLOG$_表），而非物化视图本身；确认废弃需交叉验证DBA_REGISTERED_SNAPSHOTS和DBA_MVIEW_LOGS，唯一合规清理方式是DROP MATERIALIZED VIEW LOG ON owner.table_name。
物化视图本身占空间不大，真正吃掉存储的是它背后残留的物化视图日志（MLOG$_ 表）——删了物化视图不等于清掉了日志，这些表会一直躺在数据字典里，持续膨胀。
怎么确认 MLOG$_ 表是不是废弃的
不能只看物化视图是否存在。Oracle 从不自动清理日志，哪怕所有依赖它的物化视图都 DROP 了，MLOG$_xxx 还在。
- 查
DBA_REGISTERED_SNAPSHOTS：如果LOG_OWNER和LOG_NAME（比如'MLOG$_EMP'）组合查不到记录，说明没活跃 MV 正在注册使用它 - 查
DBA_MVIEW_LOGS：确认该日志的LOG_TABLE没被任何现存 MV 引用（注意：多个 MV 可共享一个日志，得逐个核对MASTER和LOG_TABLE） - 导出当前绑定关系留底：
SELECT LOG_OWNER, LOG_TABLE, MASTER, ROWIDS FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_EMP';
绝对不能直接 TRUNCATE 或 DROP TABLE MLOG$_ 表
这是高危操作，会破坏数据字典一致性，后续建同名物化视图大概率失败。
-
TRUNCATE TABLE sys.mlog$_emp→ 高水位线（HWM）下降，但段头块残留旧结构，下次插入可能异常扩展，甚至触发ORA-00604 -
DROP TABLE sys.mlog$_emp→ 数据字典损坏，后续 DDL 可能报ORA-12083（无法删除日志） - 唯一合规路径是走 DDL：
DROP MATERIALIZED VIEW LOG ON owner.table_name;
还有活跃 MV 共享日志，但想清理旧变更记录
当部分物化视图长期停用，而其他 MV 还在用同一日志时，可用内置过程精准清理「已被所有活跃 MV 消费」的旧记录，不碰未消费行。
- 执行：
EXECUTE DBMS_MVIEW.PURGE_MVIEW_FROM_LOG('OWNER', 'MLOG$_TABLE_NAME'); - 它只标记/清理已消费记录，不释放物理空间，也不会降低 HWM
- 清理边界由最晚的
LAST_REFRESH_DATE决定，不是按单个 MV 判断
真正释放空间的关键动作永远是 DROP MATERIALIZED VIEW LOG，而不是清数据或 shrink；而判断能否删，必须交叉验证 DBA_REGISTERED_SNAPSHOTS 和 DBA_MVIEW_LOGS，漏掉任一检查都可能误删正在被用的日志。
