data guard 是 oracle 异地容灾的事实标准，非可选方案；rpo/rto 由业务需求决定，sync 模式 rpo=0 但受限于同城部署。
Data Guard 是 Oracle 异地容灾备份策略的底层支柱，不是“可选方案”，而是事实标准。绕开它谈异地容灾，基本等于在裸奔。
明确 RPO/RTO 要求再选同步模式
异地容灾的核心约束从来不是技术，而是业务能容忍多少数据丢失和停机时间。Data Guard 的 SYNC、ASYNC、MAXIMUM AVAILABILITY 三种重做传输模式直接决定 RPO：
-
SYNC：主库事务提交前必须等备库写入 standby redo log 并确认，RPO=0，但跨地域延迟高时会拖慢主库性能，只适合同城（ -
ASYNC：主库不等备库响应，RPO 取决于网络延迟+重做生成速率，适合真正异地（如北京→广州），但故障时可能丢几秒到几分钟数据 -
MAXIMUM AVAILABILITY：折中模式，主库优先用SYNC，若备库不可达自动降级为ASYNC，需配合FAL_SERVER配置防归档堆积
别盲目设 SYNC——跨省专线延迟常超 20ms，主库 COMMIT 延迟会翻倍，应用层感知明显。
物理备库是异地容灾的唯一可靠选择
逻辑备库（Logical Standby）看似灵活，但在异地场景下几乎不可用：
- DDL 支持有限，
ALTER TABLE ... ADD COLUMN等常见操作可能中断同步 - 无法保证块级一致性，
FLASHBACK DATABASE或RECOVER操作受限 - 主备字符集、补丁版本、甚至
COMPATIBLE参数不一致就直接报错ORA-01274 - 切换后需手动校验表数据一致性，异地环境下验证成本极高
物理备库（Physical Standby）用 Redo Apply 做块级重放，只要主备 Oracle 版本兼容、存储路径映射正确，SWITCHOVER 后秒级接管，这才是异地容灾该有的样子。
备份链必须独立于 Data Guard 复制流
RMAN 备份不能只依赖主库——主库宕机时，你无法连接它来执行 BACKUP DATABASE；也不能只备份物理备库——备库的 ARCHIVELOG 默认不归档到本地磁盘，且 RESTORE 时需要主库控制文件或备份控制文件。
- 必须配置
ARCHIVELOG DELETION POLICY，确保主库归档日志在传到备库并应用后才删除，避免备份窗口内日志被清理 - 推荐在备库开启
ARCHIVELOG并启用STANDBY ARCHIVELOG归档到独立 NFS 或对象存储，这样备库可独立做VALIDATE BACKUP -
CONTROLFILE AUTOBACKUP必须开启，且备份路径要指向共享存储或异地对象存储，否则切换后找不到控制文件备份
很多团队把 RMAN 脚本写死在主库 crontab 里，一主挂，备份全停——这根本不是容灾，是单点依赖。
切换演练必须包含网络隔离测试
真实灾难不是数据库进程崩溃，而是整个机房断网、DNS 失效、负载均衡器失联。只测 SWITCHOVER 命令成功没意义：
- 提前关闭主库所在 VPC 的所有出向规则，模拟网络隔离，再触发
FAILOVER，观察备库是否真能升为主库并接受连接 - 检查应用端 DNS 缓存：如果用域名连库，
TTL必须设成 ≤60 秒，否则客户端可能继续往已失效的主库 IP 发请求 - 验证监听器状态：
lsnrctl status在新主库上必须显示READY，且local_listener参数指向当前节点真实 IP，而非 VIP（VIP 切换常滞后）
最常被忽略的是应用连接池——HikariCP 默认 connection-test-query 不校验服务角色，旧连接可能持续发写请求到只读备库，导致 ORA-16000 错误却无感知。
