ora-12034 是因物化视图日志时间戳（oldest_pk）晚于物化视图上次刷新时间（snaptime），导致增量刷新被拒；常见于ddl操作、跨库时间不同步或手动篡改日志表。
ora-12034 根本不是日志“过旧”，而是日志“太新”
报错信息里那句“物化视图日志比上次刷新后的内容新”，字面意思就是关键：日志里记录的变更时间戳（mlog$.oldest_pk 或 mlog$.oldest）比物化视图本地记录的上一次刷新时间（snap_reftime$.snaptime）还要晚。系统不敢用“未来”的日志做增量刷新，直接拒绝——这不是数据丢失风险，是逻辑校验失败。
常见诱因包括：
- 基表执行了
TRUNCATE、ALTER TABLE MOVE、DROP/RECREATE等 DDL 操作，导致物化视图日志被清空或重置，但物化视图元数据没同步更新 - 跨库刷新时主库和物化视图库系统时间不同步（差几秒就可能触发）
- 手动修改过
sys.mlog$或sys.slog$表（极不推荐），破坏了时间戳链 - 导出导入（EXPDP/IMPDP）后未重建物化视图，只重建了基表或日志
先确认哪个物化视图卡住了，别刷错对象
报错里写的 "SCOTT"."T_ROWID" 是基表名，不是物化视图名。你得反查真正依赖它的物化视图：
SELECT mview_name, last_refresh_date, refresh_mode, build_mode
FROM dba_mviews
WHERE owner = 'SCOTT'
AND master_link IS NULL
AND EXISTS (
SELECT 1 FROM dba_mview_logs l
WHERE l.log_owner = 'SCOTT' AND l.master = 'T_ROWID'
AND l.log_table = 'MLOG$_T_ROWID'
);
或者更直接地查刷新组：
SELECT * FROM dba_rgroup WHERE rowner IN ( SELECT owner FROM dba_mviews WHERE master = 'T_ROWID' );
重点看 last_refresh_date 是否明显早于当前时间，以及 refresh_mode 是否为 FAST —— 只有 FAST 刷新才依赖日志时间戳校验。
不要直接重建物化视图日志表（MLOG$_xxx）
DROP MATERIALIZED VIEW LOG ON t + CREATE MATERIALIZED VIEW LOG ON t 看似干净，但会彻底清空日志内容，并重置 OLDEST_PK 为当前时间。如果下游还有其他物化视图共享这个日志，它们的刷新就会全部中断——你救了一个，搞瘫一片。
真要重建日志，必须满足两个前提：
- 确认该日志只被**这一个**物化视图使用（查
dba_mview_logs的log_table和master组合唯一性） - 所有依赖它的物化视图都已停用或可接受完全刷新（
'C'模式）
否则，优先选下面更安全的方案。
最稳妥的修复路径：强制完全刷新 + 同步时间戳
90% 场景下，用完全刷新绕过日志时间校验即可恢复，且不破坏其他依赖：
- 对单个物化视图：执行
EXEC DBMS_MVIEW.REFRESH('MV_T_ROWID', 'C') - 对刷新组：先
DBMS_REFRESH.BREAK('GROUP_NAME')，再逐个REFRESH(..., 'C')，最后DBMS_REFRESH.RESUME('GROUP_NAME')
刷新成功后，系统会自动更新 SNAP_REFTIME$.SNAPTIME，并把 MLOG$.OLDEST_PK 推进到当前时间点之后，后续 FAST 刷新就能继续。
如果连完全刷新都失败（比如 UNDO 不足、锁冲突），说明基表本身状态异常，此时才考虑重建日志+物化视图组合——但务必注意：DROP MATERIALIZED VIEW 前，先用 DBMS_MVIEW.EXPLAIN_MVIEW 检查依赖，避免误删被其他应用引用的视图。
时间戳不一致这种底层细节，很容易被忽略。一旦主库和物化视图库的系统时间偏差超过 1 秒，SNAPTIME 就可能错位，而 Oracle 默认不做 NTP 校验——这是生产环境最隐蔽的定时炸弹之一。
