选sync还是async取决于能否接受主库性能下降：sync在跨地域延迟超10ms时会导致commit显著延迟甚至卡顿，async虽rpo不为零但主库不受影响；实际部署常采用far sync中转架构平衡rpo与性能。
选 SYNC 还是 ASYNC，取决于你能不能接受主库性能被拖慢——如果跨地域延迟超过 10ms，SYNC 很可能让 COMMIT 延迟翻倍甚至卡住应用；而 ASYNC 虽然 RPO 不为零，但主库完全不受备库状态影响。
SYNC 模式下主库变慢的典型表现
不是“偶尔慢”，而是每次事务提交都等网络往返 + 备库写入 standby redo log 的确认。尤其在跨省专线场景（如北京主库 → 广州备库），实测 RTT 常超 20ms，叠加备库 I/O 压力后，COMMIT 延迟可升至 50–100ms，Web 应用明显卡顿、连接池频繁超时。
-
SELECT DEST_ID, TRANSMIT_MODE, SYNCHRONIZATION_STATUS FROM V$ARCHIVE_DEST_STATUS中TRANSMIT_MODE显示SYNC，但SYNCHRONIZATION_STATUS长期为DEFERRED或ERROR，说明备库响应已掉队 - 主库
v$session_event中出现大量log file sync等待，平均等待时间 > 10ms 就值得警惕 - 误配
LOG_ARCHIVE_DEST_2时用了SYNC却没配FAL_SERVER，备库断连后归档堆积，最终触发ORA-16038（归档无法删除）
ASYNC 模式不是“随便配就能用”
ASYNC 表面简单，但配置错一个参数就可能退化成半同步行为，甚至导致日志不传输。
-
LOG_ARCHIVE_DEST_2必须显式带ASYNC，不能只写SERVICE=...—— Oracle 默认值是ASYNC，但显式声明是防覆盖的底线 -
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)必须匹配主库角色和日志类型；写成(STANDBY_LOGFILES,STANDBY_ROLE)会导致主库根本不出日志 -
DB_UNIQUE_NAME区分大小写，且必须与备库init.ora中的db_unique_name完全一致，否则ALTER SYSTEM SWITCH LOGFILE后V$ARCHIVE_DEST_STATUS里STATUS是INACTIVE - 若启用 Data Guard Broker，
EDIT DATABASE ... SET PROPERTY LogXptMode='ASYNC'会覆盖手工配置，Broker 和手动混用极易冲突
真正跨地域容灾时，别只盯着 SYNC/ASYNC 二选一
纯主-备架构下，SYNC 和 ASYNC 是硬币两面；但生产中更常见的是组合路径：比如主库 → 本地 Far Sync 实例（SYNC），Far Sync → 异地备库（ASYNC）。这样既规避了长距离 SYNC 的性能惩罚，又把 RPO 控制在秒级。
- Far Sync 实例不存数据、不提供服务，只做重做中转，对网络延迟敏感度远低于真实备库
- 这种架构下，主库的
LOG_ARCHIVE_DEST_2指向 Far Sync，模式设为SYNC；Far Sync 自己再配LOG_ARCHIVE_DEST_2指向异地备库，模式为ASYNC - 验证时要分段查：
V$ARCHIVE_DEST_STATUS在主库看是否连 Far Sync，再登录 Far Sync 查它是否连异地备库，不能只盯主库到异地备库这一跳
最容易被忽略的点是：ASYNC 模式下 transport_lag 和 apply_lag 天然非零，这不是故障，是设计使然；而 SYNC 模式下一旦出现 SYNCHRONIZATION_STATUS = ERROR，主库其实已经自动降级（除非你禁用了 MAXIMUM AVAILABILITY 的降级逻辑），这时候光看参数配置会误判实际行为。
