Oracle Data Guard 实现业务无感容灾需选物理备库+Maximum Availability模式，配置Far Sync应对跨域延迟，启用Active Data Guard并授权，依赖Broker自动化切换，持续巡检Apply Lag等指标。
Oracle Data Guard 不是“出了问题再救”，而是让故障发生时业务几乎无感——主库宕机，备库秒级接管；网络抖动，重做日志不丢不乱；计划维护，切换过程对应用透明。关键在于配置选型、传输机制和角色管理是否贴合真实负载。
物理备库 + Maximum Availability 模式才是零数据丢失的底线
很多团队误以为只要开了 data guard 就自动“零丢失”，其实取决于保护模式。只有 maximum availability（最大可用性）在同步传输 + 备库实时应用的前提下，才能保证主库提交后，redo 已落盘到至少一个备库的 standby redo log 中。
常见错误现象：ORA-16143（客户端等待超时）、主库因备库不可达而挂起写入（实际是配成了 MAXIMUM PROTECTION 但未配 Far Sync）、或切换后发现最后几秒事务丢失（实为用了 MAXIMUM PERFORMANCE 异步模式）。
-
MAXIMUM AVAILABILITY要求主库与至少一个物理备库间启用SYNC重做传输，且备库必须开启standby redo log并运行Redo Apply - 若主备跨地域（如同城双中心），直接 SYNC 易受网络延迟影响，应部署
Far Sync实例作中继，避免主库性能抖动 - 不要在生产环境用
MAXIMUM PROTECTION：它强制所有备库都写成功才提交，单点故障即阻塞主库，违背高可用初衷
Active Data Guard 必须显式启用，否则备库只是“冷备”
物理备库默认只接收并存档 redo，不开放读取。要让报表、BI、备份等只读负载卸载到备库，必须手动启用 Active Data Guard 功能——这不只是开个参数，而是涉及 license、启动方式和会话隔离。
典型疏漏：ALTER DATABASE OPEN READ ONLY 后发现无法执行查询，报错 ORA-16000；或应用连上备库后修改了数据，导致后续 switchover 失败。
- 启用前确认已持有
Oracle Active Data Guard许可证，否则实例启动时会拒绝READ ONLY WITH APPLY模式 - 正确启动方式是：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT，再ALTER DATABASE OPEN READ ONLY - 连接备库的应用必须使用只读服务（如通过
DBMS_SERVICE.CREATE_SERVICE创建的BPM_RO），避免混用读写 service_name 导致意外 DML
Broker 配置不是可选项，而是故障切换可靠性的核心依赖
靠手工 ALTER DATABASE COMMIT TO SWITCHOVER 或 FAILOVER 命令做切换，在真实故障场景下极易出错：步骤遗漏、状态判断不准、备库未完全应用 redo 就强行激活，最终导致数据不一致甚至库损坏。
Broker（DGMGRL）的价值在于把切换逻辑封装成原子操作，并内置状态校验——比如自动检查 Apply Lag 是否为 0、Transport Lag 是否持续增长、备库是否处于 TO STANDBY 状态。
- 初始化 Broker 时，必须为每个数据库配置
StaticConnectIdentifier，否则switchover过程中无法反向连接原主库 - 日常必须定期执行
VALIDATE DATABASE和SHOW CONFIGURATION VERBOSE，关注输出中的Warning行（如 “Redo Transport is not enabled”） - 切勿在 Broker 配置中混用
LOG_ARCHIVE_DEST_n手动归档路径——Broker 会覆盖并禁用它们，导致传输中断
Far Sync 实例不能省，尤其当主备距离 >50km 或网络 RTT >10ms
远距离部署物理备库时，直接启用 SYNC 会让主库每次 commit 都卡在网络往返上。有人试图用 ASYNC + 定期 switchover 应对，结果是 RPO（恢复点目标）不可控，一次网络分区就可能丢失数分钟数据。
Far Sync 是轻量级实例（无数据文件），只负责接收主库 SYNC 发来的 redo 并立即转发给远端备库，把主库的等待从“跨城”缩短为“同城”。它的存在让 MAXIMUM AVAILABILITY 在广域网下真正可用。
- Far Sync 实例必须部署在离主库更近的一侧（例如主库在北京，Far Sync 在天津，备库在上海）
- 其
LOG_ARCHIVE_DEST_2必须指向远端备库，且设置SYNC NOAFFIRM（不等备库落盘确认），否则自身变成瓶颈 - Far Sync 故障时，Broker 默认会降级为异步传输；需配合监控脚本检测
V$DATAGUARD_STATS中transport lag突增，及时告警
Apply Lag 数值——这些不是部署完就一劳永逸的指标，而是每小时都该被巡检的“生命体征”。哪怕所有组件都标着 SUCCESS，如果 APPLY LAG 长期维持在 30 秒以上，说明备库 I/O 或 CPU 已成为隐性瓶颈，下次故障切换大概率失败。 
