Undo、Redo 和归档日志是 Oracle 可靠性的底座。Undo 支撑回滚和一致性读，Redo 支撑崩溃恢复，归档日志支撑介质恢复、Data Guard 和时间点恢复。

1. 学习目标与定位

维度	内容
难度层级	核心到恢复
核心目标	从底层运行链路理解本篇主题，能把概念、SQL、指标、故障和工程取舍连起来
适合人群	开发人员关注事务大小、提交频率和批量加载；运维人员关注日志写入、归档空间、恢复链路和灾备同步。

2. 核心概念总览

Undo Redo与归档日志
├─ Undo Segment
├─ Redo Record
├─ Redo Log Buffer
├─ Online Redo Log
├─ Log Switch
├─ Checkpoint
├─ Archive Log
├─ Force Logging
└─ Supplemental Logging

这张图只用来定位本章范围。正文不会把每个词机械拆成固定问答，而是按 Oracle 的真实运行机制解释它们之间如何协作、在哪里影响开发、在哪里影响运维。

3. 底层原理详解

Undo 记录变更前镜像，服务回滚和一致性读；Redo 记录变更后的物理重做信息，服务崩溃恢复。二者方向不同，但都由事务写入驱动。

提交时 Oracle 不要求数据块立即写入数据文件，而要求相关 Redo 被 LGWR 持久化到联机日志。崩溃后通过 Redo 重放变更，再用 Undo 回滚未提交事务，保证提交不丢、未提交不乱。

归档日志是联机 Redo 日志切换后的持久副本。没有归档，恢复能力通常只能到备份点；有归档，RMAN、Data Guard 和时间点恢复才有连续日志链。

4. 关键机制拆解

4.1. Undo 的双重职责

Undo 保存旧版本，事务回滚时沿 Undo 撤销修改，查询一致性读时沿 Undo 构造历史版本。Undo 表空间压力因此同时来自写事务和长查询。

长事务会延迟 Undo 清理，长查询会要求保留旧版本。两者叠加时，很容易出现 Undo 膨胀、快照过旧和回滚缓慢。

4.2. Redo、LGWR 与提交延迟

Redo 先写入 Redo Log Buffer，提交时 LGWR 将相关 Redo 写入联机日志。前台会话等待 LGWR 完成，因此日志盘延迟、同步备库和提交频率都会影响 log file sync。

循环单行提交会放大提交等待，超大事务会放大日志量和恢复成本。开发人员需要根据业务一致性选择合理提交粒度。

4.3. 日志切换、检查点与归档

联机日志写满后发生 log switch，ARCn 将旧日志归档。Checkpoint 推进数据文件头和控制文件记录，使恢复起点前移。日志组过小会导致频繁切换，归档慢会阻塞日志复用。

归档目录满是严重生产故障。处理时既要恢复写入能力，也要保护恢复链路，不能随意删除未备份归档。

4.4. Force Logging 与 Supplemental Logging

NOLOGGING 操作可以减少 Redo，但会影响介质恢复和备库一致性。Force Logging 强制记录必要 Redo，常用于 Data Guard 环境。Supplemental Logging 提供额外列信息，常用于逻辑复制和 GoldenGate。

批量加载、索引重建、迁移同步前必须确认日志策略。性能优化不能以破坏恢复能力为代价。

5. 功能模块细节补充

本节围绕概念图中的模块逐个补充底层细节，重点讲它们在 Oracle 运行链路中的位置和相互关系，而不是按固定角色模板拆分。

5.1. Undo Segment

Undo Segment 处在逻辑对象和物理文件之间。Oracle 最终以数据块读写，向上组织为区、段、表空间，向下落到数据文件或 ASM 磁盘组；空间不足、热点块、坏块和 IO 延迟都要从这个层级关系里定位。

5.2. Redo Record

Redo Record 是 Oracle 事务一致性链路中的关键点。查询依赖 SCN 和 Undo 构造一致版本，写入依赖当前读和行锁保护最新版本，提交依赖 Redo 持久化；长事务、大事务和频繁提交都会改变这条链路的压力。

5.3. Redo Log Buffer

Redo Log Buffer 属于 Oracle 内存运行路径。它影响 SQL 解析、游标复用、数据块缓存、排序哈希或 Redo 暂存；分析时要同时看命中率、等待事件、实际 SQL 行为和 PGA/TEMP 溢写，不能只靠调大内存解决。

5.4. Online Redo Log

Online Redo Log 是实例与数据库协作链路中的组成部分。实例侧负责运行时内存、进程和调度，数据库侧负责控制文件、数据文件和日志文件；该模块的异常通常会反映到启动阶段、后台进程等待、告警日志或恢复流程中。

5.5. Log Switch

Log Switch 是 Oracle 事务一致性链路中的关键点。查询依赖 SCN 和 Undo 构造一致版本，写入依赖当前读和行锁保护最新版本，提交依赖 Redo 持久化；长事务、大事务和频繁提交都会改变这条链路的压力。

5.6. Checkpoint

Checkpoint 是 Oracle 事务一致性链路中的关键点。查询依赖 SCN 和 Undo 构造一致版本，写入依赖当前读和行锁保护最新版本，提交依赖 Redo 持久化；长事务、大事务和频繁提交都会改变这条链路的压力。

5.7. Archive Log

Archive Log 是 Oracle 事务一致性链路中的关键点。查询依赖 SCN 和 Undo 构造一致版本，写入依赖当前读和行锁保护最新版本，提交依赖 Redo 持久化；长事务、大事务和频繁提交都会改变这条链路的压力。

5.8. Force Logging

Force Logging 是 Oracle 事务一致性链路中的关键点。查询依赖 SCN 和 Undo 构造一致版本，写入依赖当前读和行锁保护最新版本，提交依赖 Redo 持久化；长事务、大事务和频繁提交都会改变这条链路的压力。

5.9. Supplemental Logging

Supplemental Logging 是 Oracle 事务一致性链路中的关键点。查询依赖 SCN 和 Undo 构造一致版本，写入依赖当前读和行锁保护最新版本，提交依赖 Redo 持久化；长事务、大事务和频繁提交都会改变这条链路的压力。

6. 开发人员重点提醒

• 批量 DML 控制事务大小，避免极端提交频率。
• NOLOGGING 操作必须经过 DBA 确认。
• 大变更前确认恢复点、备份和回滚方案。

7. 运维人员重点提醒

• 监控 log file sync、log file parallel write、日志切换频率、归档空间和 Data Guard 延迟。
• 归档删除必须遵循备份保留策略。
• 定期验证归档链完整性和恢复能力。

8. 典型问题与排查

• 归档满：扩容或转移后检查备份删除策略和日志切换频率。
• 提交慢：检查 LGWR、日志盘、同步备库和提交模式。
• 备库不可恢复：检查 NOLOGGING 和 Force Logging。

9. 实践建议与检查清单

• 归档模式开启
• 日志组大小合理
• 归档备份删除策略明确
• Force Logging 策略明确
• log file sync 有基线

10. 阶段小结

本篇的学习重点不是记住术语，而是能把底层机制、业务语义和生产证据连起来。读完本篇后，应该能解释关键组件如何协作、常见问题为什么发生、开发侧如何避免制造风险、运维侧如何用指标和日志把问题定位到具体链路。