查mlog$_表是否有新数据写入需结合行数与时间戳：先执行select count(*) from mlog$_your_table看总量是否异常飙升，再用select max(snaptime$$), min(snaptime$$) from mlog$_your_table判断消费状态——若min(snaptime$$)为01-jan-4000或max值远滞后系统时间，则刷新已卡住。
怎么查MLOG$_表当前有没有新数据写入
直接看行数变化最直观，但不能只看一次。Oracle 的 MLOG$_ 表是追加写，不会自动删旧记录，所以“有增长”不等于“在正常工作”，得结合时间戳判断是否被消费。
执行这两条语句对比：
-
SELECT COUNT(*) FROM MLOG$_your_table;—— 看总量是否异常飙升（比如一天涨 50 万，而基表 DML 才几百条） -
SELECT MAX(snaptime$$), MIN(snaptime$$) FROM MLOG$_your_table;—— 如果MIN(snaptime$$)还是01-JAN-4000，说明完全没被任何 MV 消费；如果MAX(snaptime$$)比系统时间早 2 小时以上，大概率刷新卡住了
如何确认MLOG$_表的变更是否被物化视图真正处理了
SNAPTIME$$ 字段才是关键指标：它不是“写入时间”，而是“被哪个 MV 刷新到的时间”。初始值固定为公元 4000 年，每次 FAST 刷新后，Oracle 会把已处理的记录的 SNAPTIME$$ 更新为该次刷新的开始时间。
所以，要验证是否真被消费，不能只查 COUNT(*)，得查未处理部分：
-
SELECT COUNT(*) FROM MLOG$_your_table WHERE snaptime$$ = DATE '4000-01-01';—— 这个数字才是“积压未消费”的真实量 - 再比对
DBA_BASE_TABLE_MVIEWS中对应MVIEW_LAST_REFRESH_TIME，如果后者比上面查询的MIN(snaptime$$)还晚，说明刷新逻辑已断裂
为什么DBA_MVIEW_LOGS.oldest_snapshot和MLOG$_表的MIN(snaptime$$)不一致
这是常见误解点。DBA_MVIEW_LOGS.oldest_snapshot 是 Oracle 内部根据所有依赖该日志的 MV 中最老的 LAST_REFRESH_DATE 推算出的“理论最早可消费时间”，而 MLOG$_xxx.MIN(snaptime$$) 是物理存在的、尚未被标记为已处理的最早记录时间。
二者不一致通常意味着：
- 某个 MV 长期没刷新（
LAST_REFRESH_DATE过旧），拖累了整个日志的清理边界 - 有 MV 被 DROP 或重建过，但没触发日志重置，导致
oldest_snapshot滞后于实际日志内容 -
DBA_MVIEW_LOGS视图本身缓存或延迟更新，不能完全信任，必须以MLOG$_xxx表中真实数据为准
刷新任务停摆后，MLOG$_表还会继续增长吗
会，而且增长更快。只要基表有 DML（INSERT/UPDATE/DELETE），且物化视图日志存在（无论是否被消费），Oracle 就会无条件往 MLOG$_ 表里写记录。
典型静默失败场景包括：
- 调度任务状态是
DISABLED或STOPPED（查DBA_SCHEDULER_JOBS） - 刷新 Job 报错后被 Oracle 自动标记为
BROKEN = 'Y'，且NEXT_DATE = DATE '4000-01-01' - 目标 MV 所在表空间满、UNDO 不足、或权限丢失，导致
DBMS_MVIEW.REFRESH调用静默失败
这种情况下，MLOG$_ 就成了黑洞——只进不出，直到你手动干预。最危险的是，它会持续产生大量归档日志，甚至引发 ORA-01555。
