LGWR ASYNC必须显式配置NET_TIMEOUT=120、REOPEN=60及VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，缺一不可；否则将退化为ARCH传输或引发重连风暴，且_REDO_TRANSPORT_COMPRESS仅在完整匹配条件下生效。
LGWR ASYNC + NET_TIMEOUT/REOPEN 必须显式配全
只写 LGWR ASYNC 不够，缺了 NET_TIMEOUT 和 REOPEN 会导致网络抖动时频繁重连或卡死。默认 NET_TIMEOUT=180 太保守，小抖动就触发重传；REOPEN=300（默认）又会让故障恢复太慢。
-
NET_TIMEOUT=120更合理：给压缩和传输留出缓冲，避免因短暂延迟误判断连 -
REOPEN=60：故障后 60 秒内重试，兼顾稳定性与恢复速度 - 漏写
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)会 fallback 到 ARCH 传输，压根不走 LGWR 路径，压缩也失效
_REDO_TRANSPORT_COMPRESS 不是开就有效
Oracle 19c 默认关闭该隐含参数，且仅对 LGWR 传输路径起作用。设了 _REDO_TRANSPORT_COMPRESS=TRUE 却没配对的传输模式，等于白设。
- 必须搭配
LGWR ASYNC和显式VALID_FOR，否则 RFS 进程收不到压缩流 - 压缩发生在主库 LGWR 写入 socket 前，备库完全无感，但主库 CPU 会上升 5%–15%，高并发 OLTP 下需实测
- 典型压缩率在 1.3x–1.8x，但全 INSERT 或加密表空间日志几乎不压，别指望靠它救低质量网络
- 丢包率 >0.1% 时开启压缩反而加剧重传风暴——先用
ping -s 1472和tnsping排查链路
SDU 和 Socket Buffer 要两端对齐
Oracle Net 层的 SDU 和 TCP 缓冲区不匹配，会引发大量小包、重传和 Nagle 等待，直接拖垮日志吞吐。光调主库没用，备库监听和客户端连接配置都得同步。
- 统一设
DEFAULT_SDU_SIZE=32767在主备双方sqlnet.ora中 -
tnsnames.ora里为 DG service 显式加SEND_BUF_SIZE=9375000和RECV_BUF_SIZE=9375000 -
listener.ora的 ADDRESS 段也要补上同样大小的SEND_BUF_SIZE/RECV_BUF_SIZE - Linux 系统级需确认
net.core.wmem_max和net.core.rmem_max≥ 9375000，否则 Oracle 设置被内核截断
备库 I/O 和空间瓶颈常被当成网络问题
看到 transport lag 高就猛调网络参数，结果发现是备库 DB_RECOVERY_FILE_DEST 满了，或者 redo 日志路径落在 NFS 上——这种“假网络延迟”占实际排查量的 40% 以上。
- 查
V$RECOVERY_FILE_DEST.SPACE_USED / SPACE_LIMIT > 0.85？满了会卡住 RFS 进程，主库ARCH进程显示 “waiting for archive log” -
V$MANAGED_STANDBY里如果PROCESS=MRP0 且STATUS=APPLYING_LOG，但SEQ#长期不更新，大概率是备库 I/O 慢或 SQL 应用争用 - 禁用
STANDBY_FILE_MANAGEMENT=AUTO（除非真需要自动建文件），它每次应用日志都查数据字典，拖慢 MRP - 备库
DB_CREATE_FILE_DEST和DB_RECOVERY_FILE_DEST必须分开、且都指向本地 NVMe 或高性能 SAS 盘，别共用 ASM 或共享存储
ping -s 8972 和 tcpdump -i any port 1521 看包是否被截断或重传。 
