不能直接drop mlog$_表。oracle禁止手动删或截断该表，否则破坏数据字典，导致ora-12083等错误；须通过dbms_mview.unregister_mview、purge_mview_from_log和purge_log三步安全清理。
物化视图删了但MLOG$_表还在，能直接DROP吗？
不能。Oracle 明确禁止手动 DROP 或 TRUNCATE mlog$_xxx 表——哪怕物化视图已用 DROP MATERIALIZED VIEW 删除，日志表仍受内部约束保护。硬删会破坏数据字典，后续建新 MV 时大概率报 ORA-12083 或 ORA-12052，刷新退化为 COMPLETE。
- 日志表是否“可用”，不看物理存在，而看
DBA_MVIEW_LOGS和DBA_REGISTERED_SNAPSHOTS中的元数据状态 - 一个基表日志可能被多个 MV 共用，
DROP MATERIALIZED VIEW只删 MV 本身，不自动解绑日志 -
SELECT * FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_EMP'返回非空，说明日志仍被注册，哪怕没 MV 在用
怎么确认MLOG$_表真没人用了？
必须交叉验证三处系统视图，缺一不可：
- 查注册快照：
SELECT * FROM DBA_REGISTERED_SNAPSHOTS WHERE LOG_OWNER = 'SCHEMA_NAME' AND LOG_NAME = 'MLOG$_EMP'—— 若无返回，说明没有 MV 正在消费该日志 - 查日志引用：
SELECT mview_name FROM DBA_MVIEWS WHERE master = 'EMP' AND refresh_mode = 'FAST'—— 确保没有其他用户下的 MV 还在依赖这个日志 - 查日志本身：
SELECT last_refresh, rowids, primary_key FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_EMP'—— 若last_refresh是数月前，且rowids = 'N'、primary_key = 'N'，基本可判为废弃
安全清理残留日志的正确顺序
不是删表，是注销 + 清理 + 收尾。顺序错一步，后续刷新就出问题：
- 先注销残留注册：
EXEC DBMS_MVIEW.UNREGISTER_MVIEW('SCHEMA_NAME', 'MV_NAME', 'MVIEW_SITE')——MVIEW_SITE必须和DBA_REGISTERED_MVIEWS.MVIEW_SITE完全一致（含大小写、域名、端口），否则报ORA-12006 - 再按 SNAPID 清日志：
EXEC DBMS_MVIEW.PURGE_MVIEW_FROM_LOG('SCHEMA_NAME', 'EMP', 12345)——SNAPID必须来自上一步查到的DBA_REGISTERED_MVIEWS.SNAPID，不能猜 - 最后执行清理：
BEGIN DBMS_MVIEW.PURGE_LOG('EMP', 0); COMMIT; END;—— 参数0表示清空所有未消费记录，但不会删日志结构
清理完空间没释放？别急着 SHRINK
mlog$_xxx 表不支持 SHRINK SPACE，且即使 purge 完成，高水位线（HWM）也不会自动下降。常见误操作是直接跑 ALTER TABLE mlog$_xxx SHRINK SPACE，结果报 ORA-10636 或无效。
- 先收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'MLOG$_EMP')—— 否则优化器仍走全表扫描，刷新变慢 - 检查并重建索引：
CREATE INDEX idx_mlog_snap_seq ON mlog$_xxx (snaptime$$, sequence$$)—— 这是 FAST 刷新扫描日志的关键路径 - 若空间仍占满，唯一办法是导出有效数据 →
DROP MATERIALIZED VIEW LOG ON SCHEMA_NAME.EMP→ 重建日志；注意重建前确保无任何 MV 在用该基表
真正卡住的往往不是“删不掉”，而是“以为删了，其实只是断开了连接”。SNAPID、MVIEW_SITE、LOG_OWNER 这三个字段大小写敏感、域名完整、权限匹配——漏掉任一细节，清理就变成埋雷。
