必须交叉验证dba_registered_snapshots和dba_mview_logs确认mlog$_表孤立后，方可执行drop materialized view log；若需保留日志则调用purge_mview_from_log清理已消费记录，且mvid须来自dba_base_table_mviews。
不能直接 TRUNCATE 或 DROP TABLE sys.mlog$_xxx 表——这不是权限问题，是数据字典一致性风险，会引发 ORA-00604、ORA-12083 等不可逆故障。
怎么确认一个 MLOG$_ 表真能删
必须交叉验证两个系统视图，缺一不可：
- 查
DBA_REGISTERED_SNAPSHOTS：用LOG_OWNER和LOG_NAME（如'MLOG$_EMP'）组合查询，返回空才说明没有物化视图正在注册使用它 - 查
DBA_MVIEW_LOGS：确认该日志未被其他物化视图引用；注意多个 MV 可共享一个日志，需逐个核对LOG_TABLE和LOG_OWNER - 执行前务必导出依赖快照：
SELECT LOG_OWNER, LOG_TABLE, MASTER, ROWIDS, PRIMARY_KEY FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_EMP'
安全清理的两种路径：全删 or 清旧记录
选哪种取决于你是否还要保留日志供其他 MV 使用：
- 若确认日志已完全孤立（上一步验证通过），走 DDL 删除整个日志：
DROP MATERIALIZED VIEW LOG ON owner.table_name - 若还想保留日志，但只清已被消费的旧记录，调用
DBMS_MVIEW.PURGE_MVIEW_FROM_LOG(mvid)；注意mvid必须来自DBA_BASE_TABLE_MVIEWS，不是DBA_MVIEWS - 多 MV 共享一个日志时，清理边界由所有关联 MV 中最晚的
LAST_REFRESH_DATE决定，不能只看单个 MV 的刷新时间
清理后必做的三件事，否则空间不释放、刷新照样慢
删完不是结束，以下操作漏掉任何一项，都可能让问题重现或恶化：
- 立即收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'MLOG$_TABLE_NAME')，否则优化器仍走全表扫描 - 检查并重建关键索引：
CREATE INDEX idx_mlog_snap_seq ON mlog$_xxx (snaptime$$, sequence$$)——这是快速刷新扫描日志的性能命脉 - 若空间仍未释放，
sys.mlog$_xxx不支持SHRINK SPACE；只能导出数据 →DROP MATERIALIZED VIEW LOG ON owner.table_name→ 重建日志
真正卡住人的，从来不是日志表有多大，而是清理后忘了建索引、没更新统计信息、也没确认 snaptime$$ 是否被所有 MV 正确推进。
