根本原因是主库在MAXIMIZE AVAILABILITY或PROTECTION模式下强制等待备库ACK，网络抖动导致LGWR卡在log file sync事件并阻塞所有提交；可通过SELECT protection_mode, protection_level FROM v$database确认模式，临时切LGWR ASYNC+NET_TIMEOUT=10+REOPEN=5可快速缓解。
主库因网络抖动被拖慢甚至挂起，根本原因是什么
不是网络本身慢，而是主库在最大可用性（MAXIMIZE AVAILABILITY）或最大保护（MAXIMIZE PROTECTION）模式下，强制等待备库确认日志写入。一旦网络延迟突增或丢包，LGWR进程就会卡在 log file sync 等待事件上，进而阻塞所有事务提交——你看到的“卡住不动”，其实是主库在等一个收不到的 ACK。
如何快速判断当前是否处于危险同步模式
别猜，直接查：
SELECT protection_mode, protection_level FROM v$database;
如果返回值是 MAXIMIZE AVAILABILITY 或 MAXIMIZE PROTECTION，且你没做任何容错兜底，那网络一抖，主库就真可能“原地结冰”。
-
MAXIMIZE PERFORMANCE模式下完全不受影响：LGWR 异步发日志，不等备库响应 -
MAXIMIZE AVAILABILITY模式下，若备库不可达，主库会自动降级为异步，但这个切换有延迟（默认 30 秒），期间仍会卡 -
MAXIMIZE PROTECTION模式下，只要备库失联，主库会直接关闭（ORA-16627），没有商量余地
网络抖动时最有效的三道防线
不能只靠“祈祷网络稳定”，得有可落地的缓冲机制：
- 把主库归档目标从
SERVICE=standby LGWR SYNC改为LGWR ASYNC，哪怕只是临时切回——用ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC ...' SCOPE=BOTH;即可生效，无需重启 - 在
LOG_ARCHIVE_DEST_2中显式加REOPEN=5（单位秒），避免单次失败后长期停传；再配NET_TIMEOUT=10，让 LGWR 在 10 秒无响应后主动超时退出，而不是无限等待 - 检查并调大主备之间 TCP socket buffer（
SEND_BUF_SIZE/RECV_BUF_SIZE），尤其当 RTT > 50ms 或带宽 > 1Gbps 时，小 buffer 会导致频繁重传和窗口阻塞
为什么改了参数还是卡？常被忽略的隐性依赖
很多 DBA 改完 LGWR ASYNC 就以为万事大吉，结果下次抖动照样卡——问题往往出在两个地方：
-
FAL_SERVER配置指向了不可达的备库监听地址，导致主库后台进程反复尝试连接，消耗大量 CPU 和连接资源；建议设为空或指向本地 FAL 归档服务（如FAL_SERVER=''或独立归档节点） - 备库的
DB_UNIQUE_NAME在LOG_ARCHIVE_CONFIG里拼写错误，或大小写不一致（Oracle 19c 默认区分大小写），导致主库认为“备库不存在”，转而走本地归档路径，间接引发归档目录满、ARCH进程阻塞等连锁反应
真正稳的配置，从来不是堆参数，而是每一条都经得起网络断续、监听重启、防火墙策略变更的反复验证。
