2. Data Guard核心架构解析
Data Guard 的本质，是把“一份生产数据”变成“多份可切换、可验证、可恢复的数据副本”。要真正理解它，不能只记住“主库+备库”这两个词，而要把架构拆成五个相互咬合的部件：主库（Primary）、备库（Standby）、日志传输服务（Redo Transport）、日志应用服务（Redo Apply / SQL Apply），以及贯穿全局的保护模式（Protection Mode）与角色转换（Role Transition）。下面这张图先给出整体数据流与角色关系，再逐层展开。
一、主库与备库：不是简单复制，而是角色分工
主库是当前对外提供读写服务的数据库，所有业务变更都先在主库产生重做日志（Redo）。备库则是一份持续同步的副本，它不承担生产写入，而是接收主库传来的日志并应用，使自身数据与主库保持一致。物理备库（Physical Standby）通过块级恢复保持与主库完全相同的物理结构，逻辑备库（Logical Standby）则通过 SQL Apply 将日志转换为 SQL 语句在备库重放，因此逻辑备库可以额外建立索引、物化视图，甚至承担部分只读报表查询。
备库在同步过程中通常处于 MOUNT 或 READ ONLY WITH APPLY 状态。前者只做恢复，后者允许在应用日志的同时提供只读访问，这就是常说的 Active Data Guard。需要强调的是，备库不是“冷备份”，它必须持续接收并应用日志，否则同步延迟会不断累积，RPO 目标就无法保证。
二、日志传输服务：决定“丢多少数据”的关键环节
日志传输服务负责把主库的重做日志送到备库。它有两种传输进程：LGWR 和 ARCH。LGWR 传输是实时传输，主库日志缓冲区一有变更就发送，延迟最低；ARCH 传输则等主库归档完成后才发送，延迟相对较高。传输模式又分为 SYNC（同步） 和 ASYNC（异步）。同步模式下，主库提交事务前必须确认备库已收到日志，因此数据丢失风险极低，但主库提交延迟会受网络和备库影响；异步模式下，主库提交不等待备库确认，性能更好，但在主库故障时可能丢失最后一段未传输的日志。
实际配置中，通常通过 LOG_ARCHIVE_DEST_2 参数定义备库目标，例如：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 =
'SERVICE=standby1 LGWR SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=standby1';其中 LGWR SYNC AFFIRM 表示使用 LGWR 同步传输并要求备库确认写入。若改为 LGWR ASYNC，则变为异步传输。传输服务还依赖 LOG_ARCHIVE_DEST_STATE_2=ENABLE 启用目标，以及 FAL_SERVER、FAL_CLIENT 处理日志缺口自动补齐。
三、日志应用服务：把日志真正变成数据
日志到达备库后，并不会自动变成可用数据，必须由日志应用服务完成重放。物理备库使用 Redo Apply（MRP 进程），它直接对数据块做恢复，速度最快，数据与主库物理一致。逻辑备库使用 SQL Apply（LSP 进程），它先把日志解析成 SQL 语句，再在备库执行，因此备库可以保持打开状态并支持额外对象。
判断应用是否正常，主要看两个视图：V$MANAGED_STANDBY 查看 MRP/LSP 进程状态，V$DATAGUARD_STATS 查看 apply lag 和 transport lag。如果 apply lag 持续增大，说明备库应用速度跟不上主库日志产生速度，需要检查备库 I/O、CPU 或是否存在长事务阻塞。
四、保护模式：在性能与数据安全之间做取舍
保护模式决定了主库在备库不可用时的行为，是 Data Guard 架构中最重要的策略参数。三种模式对比如下：
| 保护模式 | 数据丢失风险 | 主库可用性影响 | 典型传输配置 |
|---|---|---|---|
| 最大保护 | 零丢失 | 备库不可用时主库停止写入 | LGWR SYNC AFFIRM |
| 最高可用 | 零丢失（备库正常时） | 备库故障时主库降级继续运行 | LGWR SYNC AFFIRM |
| 最高性能 | 可能丢失少量日志 | 主库性能优先，不受备库影响 | LGWR ASYNC 或 ARCH |
切换保护模式使用 ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; 这类命令。需要注意的是，最大保护模式要求至少一个备库处于同步确认状态，否则主库会挂起；最高可用模式在备库故障时自动降级为异步，保证主库继续服务；最高性能模式则始终不等待备库确认。
五、角色转换：Switchover 与 Failover 的区别
角色转换是 Data Guard 高可用能力的最终体现。它分为两种：Switchover 是计划内切换，主库先切换为备库，原备库再切换为主库，整个过程无数据丢失，通常用于数据库升级、机房搬迁、计划维护。命令为：
-- 原主库执行
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
-- 原备库执行
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;Failover 则是主库发生故障无法恢复时的紧急切换，备库直接提升为主库。此时如果保护模式为最高性能且存在未传输日志，就可能丢失部分数据。Failover 后原主库不能再自动加入，需要重新搭建或使用 Flashback 恢复。因此，生产环境应优先使用 Switchover 完成计划内切换，Failover 只作为最后手段。
V$DATAGUARD_STATS，观察 transport lag 和 apply lag 是否接近 0；同时检查 V$ARCHIVE_DEST_STATUS 中目标状态是否为 VALID。若 lag 持续增大，优先排查网络带宽、备库 I/O 和 MRP 进程是否卡住。
把以上五个部件串起来看：主库产生日志，日志传输服务按保护模式要求把日志送到备库，备库接收后由日志应用服务重放，最终形成一份可切换、可查询、可恢复的副本。角色转换则是在需要时把这份副本变成新的主库。理解这条链路，后续的配置、监控和故障处理才有稳定的判断依据。