MaxConnects 是客户端连接池参数，不影响 Oracle 主备库同步；同步依赖 LOG_ARCHIVE_DEST_n 中的 NET_TIMEOUT、REOPEN 等传输级参数，且需结合网络诊断（如 ping、mtr、MTU 检查）和加密配置优化。
MaxConnects 参数在 Oracle 主备库场景中根本不起作用
maxconnects 是 oracle 客户端（如 jdbc、odbc）或中间件（如 weblogic 数据源）里的连接池配置项，不是 oracle 数据库服务端参数。主备库之间的数据同步走的是 redo transport service，完全不经过应用层连接池。你在 sqlnet.ora 或数据库实例里搜 maxconnects，查不到任何生效记录。
常见误操作是把应用连接池的 MaxConnects=50 当成能加速备库日志接收——实际它只影响应用连备库查数据的并发上限，对物理备库的 ARCH 进程拉日志、MRP 进程应用日志毫无关系。
- 物理备库同步依赖的是
LOG_ARCHIVE_DEST_n配置中的SYNC/ASYNC、NET_TIMEOUT、REOPEN等传输级参数 -
MaxConnects改再大，也不能让ARCH进程发得更快、MRP解析得更准 - 若误配导致连接池耗尽，只会让只读查询报
IO Error: Socket read timed out，和同步延迟无关
真正该调的是 NET_TIMEOUT 和 REOPEN，但必须配合网络诊断
NET_TIMEOUT 控制的是归档传输过程中，等待对端响应的超时秒数；REOPEN 决定重试前等待多久。它们只在 LOG_ARCHIVE_DEST_n 中生效，且仅对 ASYNC 模式下的网络抖动敏感。
直接把 NET_TIMEOUT=30 改成 NET_TIMEOUT=5 不是优化，是自找麻烦：网络偶发延迟 8 秒就会触发重传，反而增加 redo 传输碎片和 gap。
- 先确认是否真有网络问题：在主库执行
ping -s 65507 备库IP测巨型帧通断，用mtr 备库IP看中间跳点延迟毛刺 - 若链路本身稳定（
avg ，无丢包），<code>NET_TIMEOUT保持默认30即可 - 若存在间歇性丢包，优先调
REOPEN=15（默认 300），让重试更及时，而非压低NET_TIMEOUT - 切勿在
SYNC模式下调NET_TIMEOUT：它会直接拖慢主库事务提交，引发log file sync等待飙升
比参数更关键的是传输协议与加密开销
Oracle 19c 默认启用 SQLNET.ENCRYPTION_SERVER = requested，主备之间 redo 传输也会走加密通道。如果网络带宽充足但 CPU 负载高（尤其备库 MRP 进程 %us 长期 > 70%），加密可能成为瓶颈。
验证方式：在主库临时关闭传输加密，观察 V$ARCHIVE_DEST_STATUS 中 TRANSMIT_TIME 是否下降明显：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby ENCRYPTION=DISABLED';
- 加密关闭后同步延迟未改善 → 问题不在 CPU，应回归网络或存储侧（如备库
ARCH进程写磁盘慢） - 加密关闭后
TRANSMIT_TIME缩短 40%+ → 说明网卡或 CPU 加密能力不足，需评估硬件加速（如 Intel QAT）或降级加密算法 - 禁用加密仅作诊断，生产环境必须配合
ENCRYPTION=REQUIRED与合规策略重新启用
容易被忽略的底层 MTU 和 TCP 栈配置
主备库跨机房同步时，若中间网络设备（防火墙、负载均衡器）不支持 jumbo frames，而两端系统却设了 MTU=9000，会导致大量 IP 分片。Linux 内核处理分片包的开销远高于整包，MRP 进程解析 redo 时会出现周期性卡顿。
检查命令必须在主备库**物理网卡**上运行，不能只看 bond 或 vlan 接口：
ip link show eth0 | grep mtu
- 主备库 MTU 必须一致，且不超过路径最小 MTU（用
tracepath 备库IP查） - 若路径最小 MTU 是 1500，主备库都设成
MTU=1500，并关闭tcp_sack和tcp_timestamps（减少 TCP 头开销） - Oracle 19c 的
LGWR进程使用异步 I/O 发送 redo，但底层仍依赖 TCP 栈缓冲区，net.core.wmem_max建议 ≥ 4M
网络层参数调错，再怎么改 NET_TIMEOUT 都只是掩盖症状。真正稳定的主备同步，永远从 ping、mtr、ss -i 这些命令开始。
