log_archive_dest_n参数中sync或async仅是传输行为的初步标识，实际生效需结合保护模式、affirm设置及srl存在性共同判定；transmit_mode为sync/async才有效，否则被静默忽略；maximum protection强制lgwr sync affirm且依赖srl，maximum availability默认同步但可降级，maximum performance默认异步；sync必须配affirm、async必须配noaffirm，混搭报ora-16025；备库无srl或lns进程非lgwr则sync失效；事务提交时log file sync等待显著增加表明sync真正生效。
log_archive_dest_n 参数里是否含 sync 或 async，是判断 data guard 传输行为最直接的依据。但仅看这个参数容易误判——它必须和保护模式、affirm 设置、srl 是否存在共同生效，否则 oracle 会静默忽略或报错。
查 LOG_ARCHIVE_DEST_2（或实际使用的 dest）的真实配置
主库上执行：SELECT DESTINATION, STATUS, PROTECTION_MODE, TRANSMIT_MODE FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;
重点看 TRANSMIT_MODE 字段：值为 SYNC 或 ASYNC 才算有效；若为 DISABLED 或 UNKNOWN，说明该归档目标未启用或配置非法。
更稳妥的做法是直接查参数值：SHOW PARAMETER LOG_ARCHIVE_DEST_2
确认输出中明确包含 LGWR SYNC AFFIRM 或 LGWR ASYNC NOAFFIRM 这类组合——SYNC 必须配 AFFIRM，ASYNC 必须配 NOAFFIRM，混搭如 SYNC NOAFFIRM 会导致启动时报 ORA-16025。
看保护模式是否强制绑定了 SYNC 行为
V$DATABASE.PROTECTION_MODE 的值才是最终裁决者：
-
MAXIMUM PROTECTION→ 强制LGWR SYNC AFFIRM，且备库必须有STANDBY REDO LOG，否则启动失败（ORA-01271） -
MAXIMUM AVAILABILITY→ 默认走LGWR SYNC AFFIRM，但备库失联时自动降级为异步，主库不宕机 -
MAXIMUM PERFORMANCE→ 默认ARCH ASYNC NOAFFIRM或LGWR ASYNC NOAFFIRM，不等备库响应
LOG_ARCHIVE_DEST_n 里的 SYNC 却不调保护模式，Oracle 不会真正启用同步行为——它会按当前保护模式兜底。验证备库是否真在用 SRL 并收到 AFFIRM 确认
同步模式下，备库必须有 STANDBY REDO LOG，否则 LGWR 无法等待 AFFIRM：SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG;
空结果或状态不是 ACTIVE/UNASSIGNED，说明 SRL 未就位，SYNC 实际失效。
再查主库 LNS 进程是否活跃：SELECT PROCESS, STATUS, CLIENT_PROCESS, SEQ# FROM V$MANAGED_STANDBY WHERE PROCESS = 'LNS';
若 STATUS 是 WRITING 且 CLIENT_PROCESS 为 LGWR，说明 LGWR 正在推日志；若为 ARCH，哪怕参数写了 LGWR SYNC，实际也退化成归档异步传输。
别信“看起来在同步”，得看事务提交是否被阻塞
最硬核的验证方式：在主库开一个长事务，提交前抓取 v$session_event：SELECT EVENT, TIME_WAITED_MICRO FROM V$SESSION_EVENT WHERE SID = <your_sid> AND EVENT LIKE '%log file sync%';</your_sid>
如果 TIME_WAITED_MICRO 显著高于平时（比如 >100ms），且伴随大量 log file sync 等待，大概率是 LGWR 在等备库 AFFIRM 响应。
但要注意：网络延迟、备库 IO 慢、SRL 写满都会放大这个等待——这恰恰说明 SYNC 生效了，而不是配置错了。
真正难的不是查参数，而是理解 Oracle 不让你“单独开关 SYNC/ASYNC”。它把传输行为锁死在保护模式里，又用 SRL 和 AFFIRM 做双重校验。漏掉任意一环，SYNC 就只是参数文件里一行漂亮的文字。
