备库延迟持续增长且arch进程卡在“waiting for archive log”，主库归档生成速度远超备库接收或应用能力，常见原因包括网络带宽不足、归档传输配置不合理（如lgwr async未配net_timeout/reopen）、备库i/o压力大、db_recovery_file_dest空间满、standby_file_management=auto引入额外开销、mrp进程受i/o或sql争用阻塞、归档压缩未启用、adg超时参数过严（standby_max_data_delay=0）、compatible参数不一致导致优化失效等。
备库延迟持续增长，arch进程卡在“waiting for archive log”
这说明主库归档日志生成速度远超备库接收或应用能力，根本原因常是网络带宽不足、归档传输配置不合理，或备库i/o压力过大。不是所有延迟都该立刻干预——先确认是否真有问题：select max(sequence#) from v$archived_log where dest_id=1 and applied='yes' 和主库 select max(sequence#) from v$log_history 对比差值超过 50 就值得查。
- 检查主库
LOG_ARCHIVE_DEST_2是否启用了异步传输但未配ASYNC参数（如漏写ASYNC=256K），导致默认同步阻塞归档进程 - 确认网络路径是否存在丢包或高延迟：从主库用
tnsping测备库监听，再用ping -s 1472（避开IP分片）测MTU级连通性 - 备库
DB_RECOVERY_FILE_DEST_SIZE满了会导致ARCH进程挂起，查V$RECOVERY_FILE_DEST中SPACE_USED/SPACE_LIMIT比值
LGWR 传输模式下仍出现日志堆积，V$DATAGUARD_STATS 显示 transport lag 高于 apply lag
说明日志还没传到备库，问题出在主库端发送环节，和备库应用能力无关。LGWR + ASYNC 是当前最优组合，但若没调好缓冲区或网络参数，反而更慢。
- 确保
LOG_ARCHIVE_DEST_2含完整参数：LGWR ASYNC NOAFFIRM NET_TIMEOUT=30 REOPEN=60——NET_TIMEOUT太小（如默认 180 秒）会让短暂抖动触发重传，REOPEN太大则故障恢复慢 - 主库
LOG_BUFFER建议 ≥ 100MB（尤其 OLTP 高并发场景），太小会频繁触发 LGWR 写，放大网络等待影响 - 禁用备库端的
STANDBY_FILE_MANAGEMENT=AUTO（除非真需要自动加数据文件），它会在每次日志应用时触发额外字典查询，拖慢MRP进程
备库 MRP 进程 CPU 占用高但 apply lag 不降，V$MANAGED_STANDBY 显示大量 APPLYING_LOG
这是典型的 I/O 瓶颈或 SQL 应用层争用。MRP 不是单线程，但默认只用一个协调进程驱动多个应用线程；若备库 redo 日志路径落在慢盘（比如 NFS 或低 IOPS 云盘），或归档日志压缩率低导致解压耗时，都会卡住。
- 把备库
DB_CREATE_FILE_DEST和DB_RECOVERY_FILE_DEST分开，且都指向本地高性能存储（非共享存储） - 主库开启归档压缩（Oracle 12.2+）：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='... COMPRESSION=ENABLE' SCOPE=BOTH，实测可减少 40%+ 网络传输量 - 检查备库是否有长事务回滚阻塞 MRP：
SELECT * FROM V$SESSION WHERE EVENT LIKE 'rdbms ipc message%' AND STATE = 'WAITING'，配合V$TRANSACTION查未提交事务
启用 ADG 后查询性能下降，SELECT 报 ORA-03172: STANDBY_MAX_DATA_DELAY exceeded
这不是传输问题，而是实时查询超时机制被误触发。ADG 要求物理备库打开只读的同时允许日志应用，但 STANDBY_MAX_DATA_DELAY 默认为 0（即不允许任何延迟），一旦网络抖动或 MRP 稍慢就直接报错。
- 业务可接受秒级延迟时，设为
ALTER DATABASE SET STANDBY_MAX_DATA_DELAY = 30（单位秒） - 避免在 ADG 备库跑分析类大查询，它们会持有大量 buffer cache 锁，间接拖慢 MRP 的 block 清理速度
- 确认没有在备库执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL后又忘记重启 MRP —— 此时备库实际已退化为只读快照，不再应用日志
延迟问题往往不是单一链路的问题，网络、主库归档策略、备库I/O、甚至SQL应用阶段的锁竞争都可能成为瓶颈。最常被忽略的是：把主备库的 COMPATIBLE 参数设成一致，否则某些优化特性（如压缩传输、并行日志应用）不会生效。
