3. 物理备库与逻辑备库选型
在 Data Guard 体系中，备库并不是只有一种形态。物理备库（Physical Standby）、逻辑备库（Logical Standby）和快照备库（Snapshot Standby）虽然都承担容灾职责，但它们对主库数据的“理解方式”、可开放的业务能力、切换代价和限制条件差异很大。选型时如果只看“能不能同步”，很容易在后期发现备库无法承担报表、无法做读写测试，或者切换时间超出 RTO 要求。因此，本节从数据形态、同步机制、可读可写能力、切换与限制四个维度展开，帮助你在真实项目中做出可落地的选择。
一、三种备库的本质差异
物理备库接收的是主库的物理块变化。它通过 Redo Apply（MRP 进程）把主库传来的归档日志或 Standby Redo Log 中的重做记录，按块地址直接应用到备库数据文件。因此，物理备库在数据文件、控制文件、数据块结构上与主库完全一致，本质上是一份“块级克隆”。这也决定了它只能以只读方式打开（Active Data Guard 下可读且持续应用），不能直接写入业务数据。
逻辑备库接收的则是主库的逻辑变更。它通过 SQL Apply（LSP 进程）先把重做记录转换成 SQL 语句，再由逻辑备库上的 SQL 引擎执行。因此，逻辑备库的数据文件结构可以与主库不同，表空间可以不同，甚至可以在备库上额外创建索引、物化视图或只写表。代价是它只支持部分数据类型和 DDL，且同步延迟通常高于物理备库。
快照备库是物理备库的一种临时可写形态。它先暂停 Redo Apply，把备库转换为可读写状态，供业务做上线前验证、压力测试或数据修补；测试结束后丢弃变更，再恢复为物理备库继续接收主库日志。它解决的是“既要真实数据、又要可写环境”的矛盾，但转换期间备库不再具备实时容灾能力。
二、物理备库：最稳、最快、最常用
物理备库是绝大多数生产容灾方案的首选。它的优势来自“同构”：主库和备库的数据文件、控制文件、参数结构高度一致，因此切换（Switchover/Failover）时不需要做数据字典重建，切换时间通常可以控制在分钟级。在 Active Data Guard 授权下，物理备库还可以在持续应用日志的同时对外提供只读查询，把容灾资源用于报表、查询卸载，这是它相比逻辑备库最实用的增值点。
物理备库的典型限制是：不能写入业务数据，不能创建与主库不同的表结构，不能单独在备库上做数据修补。如果业务方希望在备库上做“补数据、改状态、跑批处理”，物理备库无法满足。此外，物理备库对主库的 NOLOGGING 操作、数据文件添加、表空间变更等都需要确保日志完整传递，否则会出现 GAP，需要从主库补传归档日志。
三、逻辑备库：可读可写，但兼容性是门槛
逻辑备库的价值在于“备库也能承载一部分业务”。它通过 SQL Apply 把主库变更转换成 SQL 执行，因此备库上可以额外创建索引、物化视图、只写表，甚至可以在备库上做数据加工。对于报表系统、数据仓库前置层、需要读写混合的验证环境，逻辑备库比物理备库更灵活。
但逻辑备库的限制非常明确：它只支持部分数据类型和 DDL。例如，主库上使用某些特殊数据类型、加密列、部分分区操作或特定 DDL 时，逻辑备库可能无法应用，导致同步中断。逻辑备库的同步延迟通常也高于物理备库，因为 SQL Apply 需要解析、转换、执行，链路更长。因此，逻辑备库更适合“对实时性要求不是极致、但需要备库可写”的场景，而不是替代物理备库作为主容灾方案。
四、快照备库：临时可写的物理备库
快照备库的本质是物理备库的一个可写快照。它先暂停 Redo Apply，把备库转换为可读写状态，业务可以在真实数据上做上线验证、压力测试、数据修补。测试完成后，丢弃快照期间的变更，恢复为物理备库，继续接收主库日志。
快照备库的关键限制是：在转换为可写状态期间，备库不再实时应用主库日志，容灾能力暂时下降。如果此时主库发生故障，快照备库无法直接接管，必须先回滚到快照点并重新同步。因此，快照备库适合计划内的短时测试窗口，不适合长期作为可写环境使用。使用前必须确认测试窗口内主库风险可控，并预留回滚和重新同步的时间。
五、选型决策：从 RTO、RPO 和业务用途出发
选型时建议先明确三个问题：第一，RTO 要求多快？如果要求分钟级切换，物理备库是首选。第二，RPO 要求多低？物理备库在最大保护模式下可以做到零数据丢失，逻辑备库通常有秒级到分钟级延迟。第三，备库是否需要承载读写业务？如果只需要只读查询，物理备库加 ADG 即可；如果需要写入或做数据加工，才考虑逻辑备库；如果只是临时测试，快照备库更合适。
下面给出一个简化的选型参考表，便于在项目评审时快速对齐：
| 维度 | 物理备库 | 逻辑备库 | 快照备库 |
|---|---|---|---|
| 数据形态 | 块级一致 | SQL 级一致 | 物理基础 + 可写快照 |
| 同步机制 | Redo Apply（MRP） | SQL Apply（LSP） | 暂停 MRP 后转换 |
| 可读 | 只读 / ADG 实时读 | 可读 | 可读可写（临时） |
| 可写 | 否 | 可写附加对象 | 整库可写 |
| 切换速度 | 最快 | 中等 | 需回滚后切换 |
| 主要限制 | 不可写、结构不可变 | 数据类型/DDL 兼容性 | 转换期间容灾降级 |
| 典型场景 | 核心容灾、读写分离 | 报表、数据加工、验证 | 上线前测试、数据修补 |
最后需要强调：备库选型不是一次性的技术决策，而是随着业务变化需要复评的架构选择。当主库出现新的数据类型、新的 DDL 模式，或者业务对备库读写能力提出新要求时，应重新评估逻辑备库的兼容性；当测试窗口变长或频率变高时，应评估快照备库的转换与回滚时间是否仍在可接受范围内。只有把备库形态与业务目标对齐，Data Guard 才能真正成为可依赖的灾备体系。