物化视图刷新卡住时不可直接删除MLOG$表，应先通过V$MVREFRESH和DBA_MVIEW_LOGS定位问题，再安全清理job、临时段或挂起会话；重建日志前须确认是否被多MV共用，并手动处理残留job与依赖。
物化视图刷新卡住时，不能直接删 MLOG$ 表
oracle 不允许你手动 drop 或 truncate 物化视图日志表（如 mlog$_sales），哪怕它看起来“损坏”或“残留”。这类表由 oracle 内部管理，结构受约束保护，强行删会破坏依赖关系，导致后续 refresh fast 报 ora-12052 或静默退化为 complete。真正该清理的不是日志表本身，而是其元数据状态和关联的 job/transaction 上下文。
先查清楚到底卡在哪：V$MVREFRESH 和 DBA_MVIEW_LOGS 是关键入口
执行刷新失败后，别急着删东西。先确认问题类型：
-
V$MVREFRESH查当前活跃刷新任务：SELECT * FROM V$MVREFRESH WHERE MVIEW_NAME = 'YOUR_MV';—— 若STATUS为WAITING或EXECUTING且长时间不动，说明刷新进程被锁或 hang 住 -
DBA_MVIEW_LOGS验证日志有效性：SELECT master, rowids, primary_key, log_table FROM DBA_MVIEW_LOGS WHERE master = 'YOUR_BASE_TABLE';—— 若rowids = 'N'且primary_key = 'N'，说明日志根本不可用于 FAST 刷新，此时所谓“损坏”其实是配置缺失 - 检查
USER_JOBS或DBA_SCHEDULER_JOBS：若 job 状态为BROKEN = 'Y'或FAILURES > 0，说明定时刷新已中断，但日志表本身完好
真正能安全清理的三类对象：job、临时段、挂起事务
所谓“清理损坏容器”，实际是释放被占用的资源，而非删除物化视图或日志：
- 停掉失控 job：
EXEC DBMS_JOB.REMOVE(<code>JOB_NUMBER);（注意：JOB_NUMBER来自USER_JOBS.JOB）；RAC 环境下需确认 job 是否跨节点重复注册 - 清空临时段争用：
SELECT tablespace_name, segtype, blocks FROM v$sort_segment;—— 若TEMP表空间有大量未释放 segment，重启实例或手工 shrink 可能比删 MV 更有效 - 杀掉挂起刷新会话：
SELECT sid, serial#, sql_id FROM v$session WHERE program LIKE '%DBMS_MVIEW%';→ALTER SYSTEM KILL SESSION '<code>SID,SERIAL#' IMMEDIATE;；注意不要杀错，尤其避免杀基表 DML 会话
重建前必须绕过的两个坑：MV Log 复用与依赖残留
如果真要重建物化视图或日志，以下两点常被忽略：
- 一个基表日志可能被多个物化视图共用。执行
DROP MATERIALIZED VIEW LOG ON t前，务必先查：SELECT mview_name FROM dba_mviews WHERE master = 'T' AND refresh_mode = 'FAST';—— 若返回多行，删日志等于让其他 MV 刷新失效 -
DROP MATERIALIZED VIEW mv_name不会自动删其关联的日志表，也不会清USER_JOBS中残留 job。重建后若忘记手动注册 job 或重设NEXT，定时刷新就永远不会触发
最易被忽略的是：日志表名（如 MLOG$_T）在数据字典里仍存在，但 Oracle 已不认它为有效日志——你得靠 DBA_MVIEW_LOGS 的 rowids/primary_key 字段判断，而不是看表是否存在。
