物化视图日志（MLOG$_表）是表空间暴涨的隐性元凶，DROP MATERIALIZED VIEW后MLOG$_仍持续写入膨胀；需通过DBA_SEGMENTS定位高占用日志，再结合DBA_REGISTERED_SNAPSHOTS和DBA_MVIEW_LOGS确认其是否废弃；严禁TRUNCATE或DROP SYS.MLOG$_XXX表，必须使用DROP MATERIALIZED VIEW LOG ON owner.table_name安全清理，或用DBMS_MVIEW.PURGE_MVIEW_FROM_LOG清理已消费记录。
物化视图日志（MLOG$_ 表）是表空间暴涨最常见的隐性元凶，真正吃掉空间的不是物化视图本身，而是它背后残留的、无人消费的日志表——哪怕你已经 DROP MATERIALIZED VIEW 了，MLOG$_ 仍会持续写入并膨胀，直到你主动清理。
怎么确认哪个 MLOG$_ 表在撑爆表空间
别猜，直接查占用排名。先定位高水位段：
SELECT segment_name, segment_type, owner, bytes/1024/1024 AS mb FROM dba_segments WHERE segment_name LIKE 'MLOG$%' ORDER BY bytes DESC;
再交叉验证是否“真废弃”：
- 查
DBA_REGISTERED_SNAPSHOTS：若LOG_OWNER和LOG_NAME（如'MLOG$_ORDERS'）组合无返回，说明没活跃 MV 注册使用它 - 查
DBA_MVIEW_LOGS：确认该日志的LOG_TABLE没被任何现存 MV 的MASTER字段引用（注意：多个 MV 可共享一个日志，得逐个核对） - 导出当前绑定快照留底：
SELECT LOG_OWNER, LOG_TABLE, MASTER, ROWIDS FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_ORDERS';
为什么不能 TRUNCATE TABLE sys.mlog$_orders 或 DROP TABLE
这是最常踩的坑：Oracle 明确禁止直接操作 sys.mlog$_xxx 表，这不是权限问题，而是数据字典一致性风险。
-
TRUNCATE TABLE sys.mlog$_orders→ 高水位线（HWM）下降，但段头块残留旧结构；下次插入可能异常扩展，甚至触发ORA-00604 -
DROP TABLE sys.mlog$_orders→ 破坏数据字典，后续建同名日志时大概率报ORA-12083，刷新失败 - 即使
snaptime$$已标记为已消费，Oracle 仍认为日志“有效”，继续写入，空间很快又涨回来
安全清理的唯一合规路径：用 DDL，不是 DML
确认孤立后，必须走标准 DDL：
- 彻底清空日志及关联元数据：
DROP MATERIALIZED VIEW LOG ON owner.orders;（注意是ON owner.table_name，不是ON MLOG$_xxx） - 如果还想保留日志、只清理已消费的旧记录（比如部分 MV 停用但其他还在用），用内置过程：
EXEC DBMS_MVIEW.PURGE_MVIEW_FROM_LOG('OWNER', 'MLOG$_ORDERS'); - 关键点：
PURGE_MVIEW_FROM_LOG不释放物理空间，也不降低 HWM；它只标记/删除已被所有活跃 MV 消费的行，边界由最晚的LAST_REFRESH_DATE决定，不是单个 MV 的时间
清理后空间还不下来？别忘了 SHRINK SPACE 不适用
SHRINK SPACE 对 sys.mlog$_xxx 表无效，Oracle 不允许对这类系统表执行 segment shrink。真正释放空间的关键动作永远是 DROP MATERIALIZED VIEW LOG —— 它会连带删掉整个段。如果你已执行 DROP 但 dba_segments 里仍有记录，检查是否误删了非 SYS 用户下的日志（比如 owner.mlog$_orders），或是否遗漏了 DBA_REGISTERED_SNAPSHOTS 的验证，导致日志其实仍在被某个隐藏 MV 使用。
