ORA-01555 根本原因是物化视图刷新时所需 SCN 的 undo 数据被覆盖，与回滚表空间大小无直接关系；典型场景为基表变更频繁、刷新耗时长且 undo_retention 设置过短，应优先采用快速刷新、合理设置 retention 并避开业务高峰。

ORA-01555 是快照过旧，不是回滚表空间不够

ora-01555 的根本原因是物化视图刷新过程中，查询需要读取的 scn 对应的数据块已被覆盖（undo 数据被覆写），和回滚表空间大小没有直接关系。盲目增大 undo_tablespace 或调高 undo_retention 可能无效，甚至掩盖真正问题。

典型触发场景是：基表数据变更频繁 + 刷新耗时长（比如全量刷新或复杂 join）+ undo 保留时间短于刷新执行时间。

• 检查当前 undo 保留时间：SELECT value FROM v$parameter WHERE name = 'undo_retention';
• 确认刷新任务实际运行时长（查 DBA_MVIEW_REFRESH_TIMES 或日志）
• 如果刷新耗时 20 分钟，而 undo_retention 只设了 600（10 分钟），大概率报 ORA-01555

优先用快速刷新（FAST）替代完全刷新（COMPLETE）

完全刷新会重建整个物化视图，扫描全量基表，极大拉长查询时间窗口；快速刷新只处理增量变更，大幅缩短一致性读所需的时间跨度。

• 确保物化视图已启用日志：CREATE MATERIALIZED VIEW LOG ON your_table WITH ROWID, SEQUENCE (col1, col2) INCLUDING NEW VALUES;
• 创建物化视图时指定 REFRESH FAST ON COMMIT 或 ON DEMAND，且必须满足快速刷新限制（如无 AVG()、MAX() 等禁止聚合）
• 刷新前用 DBMS_MVIEW.EXPLAIN_MVIEW 检查是否支持快速刷新，输出中 fast_refreshable 字段必须为 YES

调整刷新方式与时机，避开业务高峰

即使支持快速刷新，若在高并发 DML 时段执行，仍可能因 undo 链争用或延迟提交导致快照过旧。主动控制刷新节奏比硬调参数更可靠。

• 改用 ATOMIC_REFRESH => FALSE：刷新时先 truncate 再 insert，避免长事务持有 undo；但注意这会短暂清空 MV 数据
• 在低峰期调度刷新，例如用 DBMS_SCHEDULER 设置凌晨执行，配合基表变更低谷
• 对超大基表，考虑分片刷新：按分区或时间范围拆成多个小 MV，单次刷新窗口缩短

undo_retention 要设得“够用”，不是“越大越好”

UNDO_RETENTION 是 soft limit，Oracle 在空间压力下仍会覆写 undo。设太高会导致 undo 表空间膨胀、自动扩展频繁，甚至引发空间不足错误。

• 先估算安全值：取最近 7 天最长刷新耗时的 1.5 倍（例如最长 18 分钟 → 设 2700 秒）
• 监控 undo 使用率：SELECT BEGIN_TIME, END_TIME, UNDOBLKS, TXNCOUNT FROM V$UNDOSTAT ORDER BY BEGIN_TIME DESC FETCH FIRST 10 ROWS ONLY;
• 配合设置 RETENTION GUARANTEE（仅限专用 undo 表空间）可强制保留，但务必确保表空间有足够冗余空间

真正难处理的是基表本身变更太猛又无法停写的情况——这时候得回到 MV 设计源头，看能否简化逻辑、拆分依赖，或者接受一定延迟改用异步 CDC 方案。