调高parallel_max_servers对oracle 11g物理备库日志应用速度基本无效，因其由单线程mrp0进程串行执行，不受并行参数控制；真正影响速率的是standby redo log配置、磁盘i/o性能及归档传输效率。
parallel_max_servers 对物理备库归档应用无作用，别调它。
物理备库的归档应用由单线程 MRP0 进程串行执行，它不走 Oracle 并行执行框架，也不启动 P00x 类型的并行服务器进程。你看到的“归档延迟高”，根源从来不在“并行度不够”。
为什么加 ARCH 进程数量对物理备库没用
主库上的 ARCH 进程只负责把在线日志归档成文件，并触发传输；而备库上真正干活的是 RFS（接收）和 MRP0（应用）两个独立进程：
- RFS 负责接收网络传来的归档或 standby redo log，它本身不决定应用快慢
- MRP0 才是唯一做重做应用的进程，且只能一个线程、按 SCN 顺序逐块重放
所以无论你在主库启多少个 ARCH，或在备库设多高的 parallel_max_servers，MRP0 仍是单点瓶颈
归档延迟高时该查哪三个地方
真正影响 MRP0 吞吐的，只有三类硬约束：
-
standby redo log 配置不足：当主库每分钟切多组 online redo log，而备库
v$standby_log组数 ≤ 主库v$log组数，RFS就会因写满而阻塞，导致归档堆积。建议 standby redo log 至少比主库多 2 组，且每组大小 ≥ 主库最大 online redo log -
磁盘 I/O 响应慢：MRP0 需要随机读 datafile + 顺序写 standby redo log + 顺序读归档。若
v$sysstat中physical reads或redo writes等待事件占比高，或iostat -x 1显示 await > 50ms、svctm > 10ms，说明存储已成瓶颈 -
归档传输链路卡顿：检查主库
V$ARCHIVE_DEST中TRANSMIT_MODE是否为LGWR ASYNC（非ARCH），NET_TIMEOUT是否过小（建议 ≥ 180），以及中间防火墙是否剥离 TCP Options（导致窗口缩放失效）
网络带宽优化不是调 Oracle 参数，而是调 OS 和 Net 层
ORA-16198 这类超时错误，90% 是 TCP 层问题，不是 Oracle 配置不对：
- 先用
tcpping -x 5 1521测真实 TCP 握手延时，别信ping - 确认
sysctl net.ipv4.tcp_window_scaling和tcp_timestamps都为 1；否则接收窗口锁死在 64KB - 按 BDP（带宽 × RTT）调大
tcp_rmem和tcp_wmem，例如千兆网 + 20ms RTT → BDP ≈ 2.5MB，建议设为"4096 262144 10485760" - Oracle Net 层必须同步：在
sqlnet.ora加DEFAULT_SDU_SIZE=32767，在tnsnames.ora的 DG 连接里加SEND_BUF_SIZE=10485760和RECV_BUF_SIZE=10485760
误判最常发生在监控指标错位时
看到 v$dataguard_stats 中 apply_lag 高，第一反应不该是“加资源”，而是确认延迟类型：
- 如果
transport_lag ≈ 0但apply_lag > 30s，说明归档已到备库，但MRP0应用不动 —— 此时盯v$managed_standby中MRP0的STATUS（必须是APPLYING_LOG）、SEQUENCE#和BLOCK#是否稳定递增 - 如果
v$archive_gap查出缺口，别直接全量拷归档；先用LIST ARCHIVELOG FROM SEQUENCE ... THREAD ...在主库定位真实缺失范围，再手工REGISTER PHYSICAL LOGFILE+RECOVER AUTOMATIC - 如果
v$archived_log里某归档STATUS = 'X'或文件大小为 0，就是无效归档 —— FAL 不会自动修复，必须人工比对哈希、重新传输或注册
真正卡住 MRP0 的，从来不是线程数，而是它每次读块、写日志、等磁盘响应的那几十毫秒。这些延迟叠加起来，才是你看到的“归档延迟过高”的真实面目。
