Oracle Data Guard是Oracle数据库内置的高可用与灾难恢复方案，核心思路是把主库产生的重做日志传到一台或多台备库，并在备库上持续应用，使备库数据和主库保持同步。当主库因为硬件损坏、机房断电或人为误删而无法服务时，备库可以接管业务，避免数据永久丢失。理解配置与故障切换的具体步骤，是数据库运维人员必须掌握的能力。
一、配置前的环境准备
在动手配置Data Guard之前，需要保证主库与备库运行在相同操作系统平台，并且Oracle数据库软件版本一致，避免日志传输或应用过程中出现兼容性问题。通常建议主备库使用独立的物理服务器或虚拟机，网络带宽稳定且延迟可控，因为日志传输会持续占用网络资源。
主库必须处于归档模式，并开启强制日志模式，确保每一次数据改动都写入重做日志。还需要配置唯一的数据库唯一名（db_unique_name），并在监听和TNS中互相注册对方地址。只有两边能通过网络互相连通，后续的日志发送与角色切换才可能正常进行。
二、物理备库的创建过程
最常用的是物理备库，它与主库在物理存储层面完全一致，通过RMAN的duplicate命令从主库备份直接生成。执行前在主库做全备，并把备份集或镜像拷贝到备库服务器，之后用RMAN连接主备库，运行duplicate target database for standby from active database命令，让Oracle自动完成拷贝与恢复。
备库创建完成后，先以mount状态启动，不直接open。接着配置备库上的日志应用服务，例如执行alter database recover managed standby database using current logfile disconnect，让备库实时接收并应用主库传来的日志。此时可以查询v$archive_dest_status视图，确认日志传输通道状态为valid，说明配置基础已就绪。
三、日志传输与同步保护模式
Data Guard提供三种保护模式，决定主库提交事务时是否等待备库确认。最大性能模式不要求备库确认，主库性能影响最小但可能丢失少量数据；最大可用模式在网络正常时类似最大保护，异常时自动降级；最大保护模式要求事务至少写入一个备库后才算提交，零数据丢失但依赖稳定网络。
选择模式要修改主库log_archive_dest_2等参数，指定sync或async方式及affirm属性。例如设置log_archive_dest_2='service=standby_db sync affirm valid_for=(online_logfile,primary_role) db_unique_name=standby'，再执行alter database set standby database to maximize availability切到对应模式。业务对数据一致性要求越高，越应靠近最大保护端。
四、计划内的切换操作
计划内切换（switchover）是在主库健康情况下，把主备角色互换，常用于硬件维护或机房搬迁。操作前先检查主库与备库均无日志应用缺口，在主库执行alter database commit to switchover to physical standby，重启为备库；再到原备库执行alter database commit to switchover to primary，打开为新主库。
切换后原主库变为备库，需重新开启日志应用，业务连接串通常指向新主库。整个过程不丢数据，因为两边数据在切换前已完全同步。建议切换后在新备库执行日志应用命令，并观察v$dataguard_status有无报错，确保容灾链路依旧有效。
五、紧急故障切换处理
当主库彻底崩溃且短时间无法恢复，就要做故障切换（failover）。在备库上先取消日志应用，执行alter database recover managed standby database cancel，再运行alter database failover to standby，强制把备库提升为主库并打开。此时原主库若 later 恢复，已不能作为备库直接加入，必须重新重建。
为避免脑裂，故障切换前应尽量确认主库确实不可达。如果采用了闪回数据库，可在原主库修复后闪回至切换前时间点，再用新主库重新同步。下表对比了两种角色变更方式的核心差异：
| 对比项 | 计划内切换 | 紧急故障切换 |
|---|---|---|
| 触发条件 | 主库正常，主动维护 | 主库失效，被动接管 |
| 数据丢失 | 无 | 可能丢失未传日志 |
| 原主库处理 | 转为备库继续用 | 通常需重建 |
六、切换后的检查与日常监控
无论哪种切换完成，都要确认业务能正常写入新主库，并检查备库（若有）的日志应用是否延迟过大。可定时查询v$archive_gap看有无缺口，用v$managed_standby观察MRP进程状态。把关键状态接入监控平台，能在主备异常时第一时间报警。
日常也应周期性做切换演练，验证文档与脚本有效。很多事故不是配置不对，而是真出故障时没人敢操作。把Data Guard的配置、保护模式选择与切换流程写成Runbook，并定期在测试环境走一遍，才能在生产环境真正放心依赖这套容灾机制。
Oracle_Data_Guard故障切换数据库容灾修改时间：2026-08-11 16:21:32