Data Guard 是 Oracle 灾备体系的核心能力，通过物理或逻辑备库、Redo 传输、应用和 Broker 管理实现故障切换与读写隔离。灾备设计要明确 RPO、RTO 和演练流程。

1. 学习目标与定位

维度	内容
难度层级	高可用到专家
核心目标	从底层运行链路理解本篇主题，能把概念、SQL、指标、故障和工程取舍连起来
适合人群	开发人员关注主备切换期间连接、读旧数据和幂等；运维人员关注传输、应用、保护模式和切换演练。

2. 核心概念总览

Data Guard与灾备架构
├─ Primary Database
├─ Physical Standby
├─ Logical Standby
├─ Redo Transport
├─ Redo Apply
├─ Data Guard Broker
├─ Switchover
├─ Failover
└─ Fast-Start Failover

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

3. 底层原理详解

Data Guard 的基础是 Redo。主库产生 Redo，传输到备库，备库应用 Redo 保持数据同步。物理备库以块级一致性复制数据库，逻辑备库以 SQL 应用方式提供更灵活但更复杂的能力。

保护模式体现数据安全与性能的取舍。最大保护、最大可用、最大性能对应不同同步要求、提交延迟和故障行为。生产设计必须先明确 RPO，而不是先搭环境。

Switchover 是计划内角色切换，Failover 是灾难场景切换。二者对数据一致性、应用连接、回切流程和演练要求不同。

4. 关键机制拆解

4.1. Redo 传输与应用链路

主库 LGWR 或归档进程将 Redo 传输到备库，备库接收后写入 standby redo log，再由 MRP 等进程应用。延迟可能发生在产生、传输、接收或应用任一环节。

排查 Data Guard 延迟不能只 ping 网络，要看 transport lag、apply lag、日志序列、备库 IO、并行应用和主库日志切换。

4.2. 物理备库、逻辑备库和读能力

物理备库保持与主库物理一致，适合灾备和 Active Data Guard 只读查询。逻辑备库可以打开读写并做部分对象过滤，但数据类型、DDL 和 SQL Apply 兼容性要仔细评估。

读备库适合报表分流，但开发人员要理解读延迟和只读限制。读到旧数据不是数据库错，而是架构一致性模型的一部分。

4.3. Broker、Switchover 与 Failover

Data Guard Broker 提供统一配置、监控和切换管理，能减少手工命令错误。Switchover 要求主备状态健康，适合维护演练；Failover 用于主库不可用，可能涉及数据损失判断。

切换不是 DBA 一个人的动作。应用连接、服务漂移、缓存失效、批处理暂停、监控静默和业务验收都应写入剧本。

4.4. FSFO 与灾备演练

Fast-Start Failover 可以在满足条件时自动故障切换，但自动化必须建立在可靠监控、观察者、网络隔离策略和业务接受的 RPO 上。

灾备演练要覆盖切换、回切、备份、数据校验、应用重连和异常中断。只演示命令成功，不等于灾备能力可靠。

5. 功能模块细节补充

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

5.1. Primary Database

Primary Database 是生产读写入口，也是 Redo 产生源。它的提交路径、日志切换频率、归档能力和网络传输状态会直接决定备库延迟；主库设计不稳定，备库只能复制这种不稳定。

5.2. Physical Standby

Physical Standby 以块级方式保持与主库一致，通常通过 Redo Apply 重放主库变更。它适合灾备、只读报表和快速角色切换；如果开启只读能力，也要接受读到的数据可能落后于主库。

5.3. Logical Standby

Logical Standby 通过 SQL Apply 将 Redo 转换为逻辑 SQL 变更，允许备库在一定范围内打开读写并做对象过滤。它比物理备库灵活，但对数据类型、DDL、对象兼容性和应用语义要求更高。

5.4. Redo Transport

Redo Transport 属于日志、检查点或恢复链路。Redo 让提交后的修改可以在崩溃后重放，归档让介质恢复和 Data Guard 有连续日志，检查点让恢复起点前移；任何一个环节异常都可能影响写入和恢复目标。

5.5. Redo Apply

Redo Apply 属于日志、检查点或恢复链路。Redo 让提交后的修改可以在崩溃后重放，归档让介质恢复和 Data Guard 有连续日志，检查点让恢复起点前移；任何一个环节异常都可能影响写入和恢复目标。

5.6. Data Guard Broker

Data Guard Broker 把主备配置、状态检查、切换和故障处理封装成统一控制面。它能减少手工命令错误，但不能替代架构判断；切换前仍要确认日志缺口、保护模式、服务漂移和应用验收。

5.7. Switchover

Switchover 是计划内主备角色互换，要求主库和备库都处于健康状态，日志没有缺口。它常用于补丁、机房维护和灾备演练；成功标准不只是角色切换完成，还包括应用服务、只读链路、监控和备份策略同步切换。

5.8. Failover

Failover 是主库不可用时的灾难切换动作，可能伴随数据损失判断、原主库隔离、新主库开放和应用流量迁移。Failover 后最难的往往是回切和数据一致性确认，因此必须提前准备 flashback、备份和重建流程。

5.9. Fast-Start Failover

Fast-Start Failover 通过 Observer 和 Broker 在满足条件时自动触发故障切换。它缩短人工判断时间，但也放大误判风险；网络隔离、观察者部署、保护模式、自动切换阈值和业务接受的数据损失窗口必须提前设计并反复演练。

6. 开发人员重点提醒

• 应用使用服务名和合理连接超时，支持重试和幂等。
• 读备库查询要接受延迟语义，不用于强一致读后写。
• 切换演练时验证缓存、任务和消息消费。

7. 运维人员重点提醒

• 监控 transport lag、apply lag、日志序列和 Broker 状态。
• 定期做 switchover 和 failover 演练。
• 归档、standby redo log 和网络链路要有容量基线。

8. 典型问题与排查

• 备库延迟：分段判断产生、传输、接收、应用瓶颈。
• 切换失败：检查 Broker 状态、日志缺口、监听服务和数据库角色。
• 回切困难：检查 flashback、备份和新主库日志链。

9. 实践建议与检查清单

• RPO/RTO 明确
• Broker 状态健康
• 延迟监控可用
• 切换剧本完整
• 应用重连验证通过
• 回切方案可执行

10. 阶段小结

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