物化视图日志（mlog$_表）仅标记消费状态而不自动删除数据，空间堆积源于失效mv未注销或共享日志中存在最晚刷新的mv；清理需先用dbms_mview.unregister_mview注销残留注册，再purge_mview_from_log逻辑清理，最后shrink space释放空间。
物化视图日志（MLOG$_ 表）不会自动物理删除数据，只更新 snaptime$$ 标记消费状态——哪怕所有物化视图都已完成刷新，行仍留在表里。空间涨到 200GB 而基表才 120MB，基本就是这个机制在“静默堆积”。
DBA_REGISTERED_MVIEWS 中 CAN_USE_LOG = 'NO' 也不触发清理
Oracle 只信任 DBA_REGISTERED_MVIEWS.CAN_USE_LOG = 'YES' 且注册有效的物化视图。哪怕你把某个 MV 的 CAN_USE_LOG 改成 'NO'，只要它还在注册表里，日志就不会被清理；更常见的是远程 MV 因 DB Link 断开、测试库下线、网络超时等原因停止刷新，但注册记录没注销，日志就一直卡住。
-
SELECT mview_name, mview_site, can_use_log FROM dba_registered_mviews WHERE master = 'YOUR_TABLE';—— 查出所有注册但实际已失效的 MV -
SELECT object_name FROM dba_objects WHERE object_type = 'MATERIALIZED VIEW' AND object_name = 'MV_NAME';—— 验证该 MV 是否真实存在（避免残留注册） -
CAN_USE_LOG是只读标记，不能直接 UPDATE；必须用DBMS_MVIEW.UNREGISTER_MVIEW显式注销
多个物化视图共享一个日志时，清理边界由最晚刷新者决定
一张基表上建一个日志，可能被 3 个不同业务的 MV 共用。Oracle 不会按“某个 MV 刷完了就清”，而是等所有依赖它的 MV 都完成消费才清理旧记录。只要其中一个 MV 的 LAST_REFRESH_DATE 是 2023 年，整个 MLOG$_ 表里 2023 年前的数据就永远不删。
-
SELECT master, log_table, last_refresh FROM dba_mview_logs WHERE master = 'YOUR_TABLE';—— 看日志本身最后刷新时间 -
SELECT mview_name, last_refresh FROM dba_mviews WHERE master = 'YOUR_TABLE';—— 找出所有依赖该基表的 MV，并比对它们的LAST_REFRESH_DATE - 注意：
DBA_MVIEWS.LAST_REFRESH_DATE可能为空或过期，真正权威的是DBA_BASE_TABLE_MVIEWS.MVIEW_LAST_REFRESH_TIME
PURGE_MVIEW_FROM_LOG 清理后空间不释放，不是 bug 是设计
DBMS_MVIEW.PURGE_MVIEW_FROM_LOG 做的是逻辑清理：把对应 SNAPID 之前的数据行标记为可重用，但不移动 HWM，也不释放段空间。即使行数归零，dba_segments.bytes 仍显示原大小。
-
SELECT bytes/1024/1024 AS mb FROM dba_segments WHERE segment_name = 'MLOG$_YOUR_TABLE';—— 确认真实空间占用 -
ALTER TABLE MLOG$_YOUR_TABLE ENABLE ROW MOVEMENT;→ALTER TABLE MLOG$_YOUR_TABLE SHRINK SPACE COMPACT;—— 手动收缩 HWM（仅限非SYS用户下的日志表） -
SYS用户下的MLOG$_表不支持SHRINK SPACE，只能导出数据 →DROP MATERIALIZED VIEW LOG ON owner.table_name→ 重建
真正难处理的从来不是“怎么删”，而是“删完谁还用着”——漏掉一个远程 MV 的注册残留，或者误判了多 MV 共享日志的最晚刷新点，清理就白做，空间几天内又涨回去。
