sync与async本质区别在于主库事务提交时是否等待备库rfs进程将redo写入磁盘：sync等待落盘后返回，async完全不等待；两者均需lgwr传输且依赖standby redo log。
sync 和 async 的本质区别在哪？
SYNC 不是“等备库应用完”，而是等备库的 RFS 进程把 redo record 写入磁盘（即写入 standby redo log 文件），就立刻返回确认；ASYNC 则完全不等，LGWR 提交事务前连网络发没发成功都不管。
- SYNC 模式下，
LNS进程从redo buffer实时抓取日志，边写 online redo log 边往外推，主库事务延迟直接受网络 RTT + 备库磁盘 I/O 影响 - ASYNC 模式下，
LNS跟不上时会自动降级去读online redo log文件发，所以即使备库短暂断连，主库也不卡 - 两者都依赖
LOG_ARCHIVE_DEST_n中的SYNC/ASYNC属性，但必须搭配LGWR（不能是ARCH），否则谈不上实时性
常见错误现象：ORA-16198（timeout 掉线）、主库大量 log file sync 等待、DG Broker 显示 TRANSMIT STATUS = FAILED —— 很可能是因为用了 SYNC 却没配 NET_TIMEOUT 或备库磁盘太慢。
什么时候必须用 SYNC？又为什么很多人悄悄切回 ASYNC？
最大保护（MAXIMUM PROTECTION）模式强制要求 SYNC，且主库会在备库不可写时直接 shutdown；最大可用性（MAXIMUM AVAILABILITY）也用 SYNC，但允许临时降级为 ASYNC 维持主库运行。
- 如果主备之间跨公网或高延迟链路（比如 >10ms），SYNC 基本不可用：一个简单
INSERT/COMMIT可能多出 50–200ms 延迟 - 备库若没配置
standby redo log，SYNC 会直接失败 —— 因为 RFS 没地方落盘，只能报ORA-16055 - ASYNC 在主备网络抖动时更“耐操”：ARCH 进程会在恢复连通后自动补传归档，而 SYNC 断了就是断了，得靠 DBA 手动干预
性能影响很实在：在 OLTP 高并发场景下，启用 SYNC 后 log file sync 平均等待时间可能翻 3–5 倍；ASYNC 下该指标基本和单机库持平。
怎么验证当前走的是 SYNC 还是 ASYNC？
别只看 LOG_ARCHIVE_DEST_2 里写了 SYNC，得确认实际生效路径：
- 查主库：
SELECT DEST_ID, TRANSMIT_MODE, AFFIRM, DATABASE_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;-
TRANSMIT_MODE = 'SYNC'且AFFIRM = 'YES'才是真 SYNC（写磁盘才确认） - 若
AFFIRM = 'NO'，哪怕写了 SYNC，也只是等 RFS 收到 network buffer 就返回（12c+ 支持，叫SYNC NOAFFIRM，性能接近 ASYNC）
-
- 查备库：
SELECT PROCESS, STATUS, CLIENT_PROCESS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;- 看
PROCESS = 'RFS'对应的CLIENT_PROCESS是LNS（说明走 LGWR）还是ARCH（说明实际退化成归档传输）
- 看
容易踩的坑：改完参数没 reload，或者忘了在备库开 STANDBY_FILE_MANAGEMENT=AUTO，导致 standby redo log 创建失败，SYNC 自动失效。
ASYNC 真的安全吗？数据丢失风险到底有多大？
ASYNC 不等于裸奔。它只是不阻塞主库提交，但日志依然会持续外送 —— 只是“尽力而为”。
- 最坏情况：主库刚写完一条 redo record 到
redo buffer，还没来得及刷盘或发送，主机就硬重启，这条记录就丢了 - 实测中，只要主库配置了合理大小的
LOG_BUFFER（比如 256MB）+ 快速刷盘策略，未发送的 redo 通常不超过几 MB，对应几秒事务量 - 关键点在于：ASYNC 仍依赖
LGWR发送，不是 ARCH；如果误配成ARCH+ASYNC，那宕机瞬间 online redo log 里的所有未归档内容全丢
真正危险的是“以为用了 SYNC，其实 fallback 到了 ASYNC”，比如备库磁盘满、standby redo log 权限不对、或者 NET_TIMEOUT 设得太小频繁超时 —— 这些状态不会自动告警，得靠定期查 V$DATAGUARD_STATS 里的 transport lag 和 apply lag。
DG 的传输机制看着绕，但核心就两条：主库愿不愿意等、备库有没有地方存。其余都是在这两个约束下的工程权衡。
