最大保护模式下延迟过高说明主库事务卡在提交前等待备库确认，实为同步失败而非同步慢，主库写入直接受阻需立即干预；根本原因是备库网络、I/O、进程或配置异常导致LGWR无法完成同步写入。
最大保护模式（MAXIMUM PROTECTION）下出现延迟过高，说明主库事务已卡在提交前等待备库确认，这不是“同步慢”，而是“同步失败”——此时主库写入会直接受阻，必须立刻干预。
为什么最大保护模式下延迟会高到影响业务
最大保护模式要求每个事务的 redo 必须同步写入主库 online redo log 和备库 standby redo log 后才能提交。一旦备库端出现以下任一情况，主库就会 hang 住：
– 备库网络不可达或丢包率 >1%
– 备库 standby redo log 空间不足或路径 I/O 延迟 >50ms
– 主库未配置 AFFIRM 对应的 NET_TIMEOUT 和 REOPEN，导致短暂抖动触发重连超时
– 备库 MRP0 进程异常终止，但主库仍持续尝试发送
此时你看到的不是 apply lag，而是主库 v$session 中大量状态为 LOG FILE SYNC 的等待，或 ARCH 进程在 waiting for archive log 上长期挂起。
检查主库 LOG_ARCHIVE_DEST_n 配置是否真启用 AFFIRM
最大保护模式依赖 LOG_ARCHIVE_DEST_n 中显式指定 AFFIRM，仅靠 alter database set standby database to maximize protection 不足以生效。
- 查当前配置：
SELECT DEST_ID, STATUS, TARGET, AFFIRM, TRANSMIT_MODE, DELAY_MINS FROM V$ARCHIVE_DEST WHERE DEST_ID = 2; - 必须看到
AFFIRM = ENABLED且TRANSMIT_MODE = SYNCHRONOUS；若为ASYNC或AFFIRM = DISABLED，实际走的是最大性能模式 - 常见错误：误配
LGWR ASYNC AFFIRM——ASYNC和AFFIRM互斥，Oracle 会静默忽略AFFIRM，降级为异步传输
异地链路下 AFFIRM 模式必须调参，不能用默认值
默认 NET_TIMEOUT=180 在跨城/跨云场景中极易误判网络抖动为故障，频繁触发重连，反而放大延迟。
-
NET_TIMEOUT应设为链路 P99 RTT 的 3~5 倍（例如实测ping -s 1472P99 是 42ms，则设NET_TIMEOUT=200） -
REOPEN不能大于NET_TIMEOUT，建议设为NET_TIMEOUT / 2（如REOPEN=100），避免故障恢复过慢 - 必须关闭
DELAY：最大保护模式下DELAY参数非法，若存在会导致ALTER SYSTEM报错ORA-16028 - 确认备库
standby redo log组数 ≥ 主库online redo log组数，且每组大小一致（差 1 字节都会导致LGWR写失败）
备库端 I/O 和进程状态比主库更关键
主库只是等待，真正卡点永远在备库。不要只看 v$dataguard_stats，直接查底层：
- 查备库
v$managed_standby：关注PROCESS = 'RFS'的STATUS是否为IDLE；若为CONNECTED但无新日志接收，说明主库没发出来或 RFS 被阻塞 - 查备库
v$standby_log：确认STATUS为ACTIVE或UNASSIGNED，若长期UNUSED说明 LGWR 没成功写入 - 查备库磁盘 I/O：用
iostat -x 1观察%util>90% 或await>20ms 的设备，尤其注意standby redo log所在路径是否落在 NFS 或低 IOPS 云盘上 - 备库
DB_RECOVERY_FILE_DEST必须是本地高速存储，且SPACE_USED / SPACE_LIMIT < 0.85，否则 RFS 进程会静默暂停
异地容灾中，最大保护模式本质是用可用性换零丢失，它对网络和备库 I/O 的苛刻程度远超大多数人预期——哪怕主备之间只有 0.3% 的丢包率，也可能让主库每分钟卡住 2~3 秒。真要零丢失，就得按电信级链路标准去压测和加固，而不是只改一个参数。
