arch传输需等主库日志归档完成才发送，lgwr则在事务提交时即通过lnsn推送未归档的在线重做日志，实现低延迟；sync要求备库有standby redo log并落盘确认，async仅本地写完即提交；arch无sync/async模式，且无法满足最大保护模式要求。
ARCH传输只等日志归档完成才发，LGWR传输能抢在归档前发
ARCH进程不参与事务提交链路，它只在主库发生log switch、本地归档完成后，才把已归档的archivelog文件通过网络传给备库的RFS进程。这意味着哪怕主库刚写完一组在线日志，只要没切换，ARCH就啥也不干。
LGWR则不同：它在事务提交时就触发LNSn进程，把尚未归档的在线重做日志（online redo log）直接推过去。所以即使主库还没log switch，备库也可能已经在接收和应用这些日志了——这是低延迟的基础。
常见错误现象：v$managed_standby里长期看不到LNS或RFS连接，只看到ARCH，说明实际走的是ARCH模式，哪怕LOG_ARCHIVE_DEST_2里写了LGWR也没用（参数没生效或没重启归档）。
SYNC和ASYNC只对LGWR有效，ARCH没有这两种模式
SYNC和ASYNC是LGWR传输路径上的网络行为开关，ARCH根本不存在这个选项。设成SYNC时，主库LGWR必须等LNSn把日志成功写入备库的standby redo log并收到确认，事务才能返回成功；设成ASYNC时，LGWR只管本地写完就提交，LNSn在后台异步推送。
关键影响点：
-
SYNC要求备库必须配置standby redo log，否则RFS只能写归档，无法满足“写入SRL即确认”的协议 -
SYNC下建议配NET_TIMEOUT，避免网络抖动导致主库事务长时间挂起 -
ARCH天然就是“异步”的——它不卡事务，但延迟高，且无法保证零数据丢失
备库是否启用standby redo log，直接决定LGWR传输能否实时应用
如果用了LGWR但备库没建standby redo log，RFS会退化成把接收到的日志直接写进archivelog目录，后续仍要等归档完成，再由MRP0去读取归档来恢复——这本质上又回到了ARCH那一套流程，白白浪费LGWR的实时能力。
正确做法：
- 备库
standby redo log组数至少比主库online redo log多1组 - 每组大小必须严格等于主库对应
online redo log大小（不能靠ALTER DATABASE ADD STANDBY LOGFILE自动推算） - 启用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE才能开启实时应用（Real-Time Apply）
最大保护/最高可用模式强制要求LGWR+SYNC+AFFIRM，ARCH无法满足
Oracle的MAXIMUM PROTECTION和MAXIMUM AVAILABILITY两种保护模式，底层硬性要求是：日志必须由LGWR传输、网络必须SYNC、磁盘写必须AFFIRM（即确保日志落盘才确认）。这三个条件缺一不可。
而ARCH传输既不介入事务提交，也无法保证网络级同步响应，所以一旦你启用了这两种模式却还在用ARCH，数据库启动时就会报错：ORA-16661: the primary database is not in a state that allows conversion to a standby database，或者在ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION时报ORA-16662类错误。
容易被忽略的一点：即使你改了LOG_ARCHIVE_DEST_2为LGWR，也必须执行ALTER SYSTEM ARCHIVE LOG CURRENT触发一次归档，让新参数真正加载进归档路径运行时状态，否则v$archive_dest_status里STATUS可能还是VALID但实际没走LGWR。
