lgwr async未配net_timeout和reopen会导致传输延迟暴涨；默认net_timeout=180秒过长，reopen=300秒恢复慢，应据rtt设为60/30，并显式配置valid_for以确保走lgwr路径。
LGWR ASYNC没配NET_TIMEOUT和REOPEN，传输会卡住
主库用LGWR ASYNC却漏写NET_TIMEOUT或REOPEN，是延迟暴涨的高频原因。默认NET_TIMEOUT=180太长，网络抖动时会傻等；REOPEN=300又太大，故障恢复慢。实际要按链路RTT来设：若ping -s 1472测出平均延迟 25ms，NET_TIMEOUT设 60 就够用，REOPEN建议 30–60。
-
LOG_ARCHIVE_DEST_2必须显式带完整参数：LGWR ASYNC NET_TIMEOUT=60 REOPEN=30 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) - 漏掉
VALID_FOR会导致 fallback 到 ARCH 传输，压根不走 LGWR 路径 - 改完必须
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=... SCOPE=BOTH，否则只在内存生效
SDU和TCP缓冲区没对齐，实际吞吐上不去
设了DEFAULT_SDU_SIZE=32767但备库tnsnames.ora里没配，或/proc/sys/net/core/rmem_max小于RECV_BUF_SIZE，Oracle 就自动降级回 8KB。最终效果得看包——tcpdump -i any port 1521 -w dg.pcap抓包后用 Wireshark 看 TCP payload 是否接近 32KB。
- 主备两端
tnsnames.ora连接描述符里都得加：(SDU=32767)(SEND_BUF_SIZE=49152)(RECV_BUF_SIZE=49152) - Linux 上执行：
echo 49152 > /proc/sys/net/core/rmem_max和wmem_max，并写入/etc/sysctl.conf - 监听器必须重载：
lsnrctl reload，否则新 SDU 不加载
压缩开启但没验证是否真生效
_REDO_TRANSPORT_COMPRESS在 12.1–19c 默认关闭，且仅对 LGWR 路径有效。设了参数但v$archive_dest_status.TRANSMIT_MODE不是LGWR，说明根本没走压缩路径。压缩率不可控，典型值 1.3x–1.8x，全插入或加密表空间日志几乎不压。
- 先查版本：
SELECT * FROM v$version，低于 12.1 别折腾这个参数 - 确认传输模式：
SELECT TRANSMIT_MODE, STATUS FROM v$archive_dest_status WHERE DEST_ID = 2 - 启用需重启：
ALTER SYSTEM SET "_REDO_TRANSPORT_COMPRESS"=TRUE SCOPE=SPFILE - 别依赖压缩掩盖丢包——丢包率 >0.1% 时，压缩反而引发重传风暴
备库IO被其他进程抢占，MRP卡在 APPLYING_LOG
BI 抽数、报表、备份任务跑满磁盘 IO，MRP 进程就只能排队。此时v$managed_standby里PROCESS='MRP0'状态长期为APPLYING_LOG，但apply lag不降，CPU 占用却高。
- 把
standby redo log和DB_RECOVERY_FILE_DEST全挪到本地高性能盘，避开 NFS 或低 IOPS 云盘 - 用 cgroup 限 Oracle 用户读 IO，但要把 RFS、MRP、DBWn 进程从限制组移出：
cgclassify -g blkio:/ <pid></pid> - 禁用
STANDBY_FILE_MANAGEMENT=AUTO，除非真需要自动建数据文件，它每次应用都查字典
关键点不在参数堆得多，而在于主备两端配置是否真正对齐、OS 层是否放行、以及你看到的“延迟”到底卡在哪一环——传输未达（看v$dataguard_stats.transport_lag）还是应用不动（看v$managed_standby中 MRP 状态）。抓包和查视图比改配置更管用。
