日志传输延迟高大概率是主库发送或网络问题，非备库应用慢；先查v$dataguard_stats中transport lag与apply lag差值，若transport lag明显更大（如＞30秒），则瓶颈在传输链路，需检查lgwr async参数配置、mtu巨帧、dns解析及网络连通性。
日志传输延迟高，大概率不是备库“慢”，而是主库发不出去或网络卡在半路——先查V$DATAGUARD_STATS里transport lag和apply lag的差值，差得大，问题就在传输链路上。
查清是传输卡住还是应用卡住
别一上来就调备库参数。用下面两个查询快速定位瓶颈环节：
- 主库执行：
SELECT value FROM V$DATAGUARD_STATS WHERE name = 'transport lag'—— 表示日志从主库生成到抵达备库归档目录的时间 - 再查：
SELECT value FROM V$DATAGUARD_STATS WHERE name = 'apply lag'—— 表示日志从生成到在备库实际重放完成的时间 - 如果
transport lag> 30秒且明显大于apply lag，说明日志压根没传过去，问题出在主库发送端或网络；反之若两者接近且都高，才轮到查备库I/O或MRP进程
LGWR ASYNC传输模式必须配全关键参数
只写LGWR ASYNC不够，缺了NET_TIMEOUT和REOPEN，反而比ARCH更不稳定：
-
NET_TIMEOUT=30：默认180秒太长，网络抖动时会傻等，设30秒可快速触发重试 -
REOPEN=60：断连后60秒内自动重连，设太大（如300）会导致故障恢复慢 - 必须加
NOAFFIRM：避免等待备库磁盘写确认，否则退化成准同步模式 - 完整示例：
LOG_ARCHIVE_DEST_2='SERVICE=standby_db LGWR ASYNC NOAFFIRM NET_TIMEOUT=30 REOPEN=60 DB_UNIQUE_NAME=standby_db'
网络层必须验证MTU与真实巨帧通路
Oracle Data Guard日志包默认较大，若链路MTU仍是1500，每条日志会被拆成多个IP包，丢一个就得全重传：
- 主备两端私网接口都执行：
ip link set dev eth1 mtu 9000（别用ifconfig） - 用
ping -M do -s 8972 -I eth1实测——失败说明交换机/网卡/驱动不支持巨帧，不是配置没生效 - 查
ethtool eth1确认Supports jumbo frames: Yes；若为No，需升级驱动或换网卡（如老版e1000e默认关闭jumbo） - RAC环境必须停集群统一改MTU，滚动生效无效；否则alert日志会出现
remote interconnect MTU mismatch
绕过DNS解析是最快见效的手段
tnsnames.ora里用域名？哪怕DNS只慢200ms，日志传输线程每秒建连多次，延迟直接滚雪球：
- 把
tnsnames.ora中所有HOST=rac-node1.example.com替换成对应IP（如HOST=192.168.10.11） - 确保
sqlnet.ora里NAMES.DIRECTORY_PATH=(HOSTNAME,TNSNAMES,EZCONNECT)，且HOSTNAME排第一 - /etc/hosts必须覆盖全部节点名、SCAN名、VIP名，大小写严格一致；漏一个，客户端回退DNS就会卡住
- 验证方式：
tnsping standby_db看“OK (xx ms)”是否稳定在50ms内
真正卡住的地方，往往不在数据库参数里，而在网卡驱动是否认得巨帧、DNS有没有被悄悄拖慢、或者NET_TIMEOUT还躺在默认值上睡大觉——这些点不逐个锤实，调LOG_BUFFER或STANDBY_FILE_MANAGEMENT都是隔靴搔痒。
