优先降压：调高log_archive_max_processes至5～8，启用async并加compression=enable；同步调大sdu_size、socket缓冲区及txqueuelen，确保oracle net与os层缓冲对齐，避免小包重传导致带宽利用率低下。
带宽跑满导致归档传输卡住，怎么快速缓解？
单个归档 1GB、专线仅 100M，理论传输需 ≥80 秒，网络抖动时极易超时积压 gap。这不是配置问题，是物理瓶颈，必须优先降压。
-
LOG_ARCHIVE_MAX_PROCESSES调高到 5～8，避免单通道挤爆（默认通常为 2） - 确认
log_archive_dest_2中已启用ASYNC，禁用SYNC模式——后者会阻塞主库提交 - 若用 Oracle EE，立刻加
COMPRESSION=ENABLE：实测对归档压缩率常达 60%～70%，直接减半传输量 - 检查主库
V$ARCHIVED_LOG的CREATION_TIME和COMPLETION_TIME差值，若持续 >90 秒，说明单个归档已在带宽边界反复重传
SDU 和 TCP 缓冲区不调，光加带宽也白搭
Oracle Net 层的 SDU_SIZE 和 OS 层的 socket buffer 不匹配，会导致大量小包、重传、ACK 延迟——这些在 AWR 里根本看不到，但会让 100M 带宽实际吞吐不到 30M。
- 在主备库
sqlnet.ora统一设DEFAULT_SDU_SIZE = 32767（11g+ 默认 8192，太小） - 在
log_archive_dest_2的 TNS 连接串里显式加(SDU=32767)，确保 RFS/LNS 连接也生效 - Linux 下调大 socket 缓冲：临时生效用
sysctl -w net.core.wmem_max=4194304和net.core.rmem_max=4194304；永久写入/etc/sysctl.conf - 别忽略
txqueuelen：网卡队列太小（默认常为 1000）会丢包，ifconfig eth0 txqueuelen 5000可缓解
RAC 主库和 DG 备库补丁不一致，MRP 会莫名卡在 WAIT FOR LOG
你描述中 RAC 未打补丁、DG 已打最新补丁，这非常危险。补丁差异会导致 LNS/RFS 协议解析错位、SRL 写入异常、MRP 读取日志时校验失败——现象就是重启 MRP 无效，必须重启实例。
- 立刻在两边执行
opatch lsinventory，比对Database和Oracle RAC Components补丁号是否完全一致 - 尤其注意 PSU（Patch Set Update）和 RU（Release Update）版本，哪怕只差一个数字，都可能引发日志应用中断
- 若不一致，RAC 必须打上与 DG 相同的补丁集；不能只“回退 DG”，因为新补丁往往含关键修复
- 补丁后务必重启所有实例，并验证
V$MANAGED_STANDBY中PROCESS='RFS'的STATUS是否稳定为WRITING
gap 脚本自动处理，但重启备库才能恢复？说明底层状态已损坏
脚本发现 gap 后传归档 + 重启 MRP 仍卡在 WAIT FOR LOG，本质是 RFS 写入 SRL 时出错，或 MRP 读取位置偏移，内存状态不一致。此时强制重启 MRP 只是掩盖问题。
- 先查
V$ARCHIVED_LOG中最近几条记录的NAME和DEST_ID，确认归档是否真写到了备库本地路径（而非 NFS 挂载点超时失败） - 检查备库 alert 日志里是否有
ORA-00354（损坏的 redo 日志块）或ORA-00363（日志序列不连续） - 若确认 RFS 写入异常，不要反复重启 MRP，而是手动切换 SRL：
ALTER DATABASE DROP STANDBY LOGFILE GROUP 1;→ 重建 →ALTER DATABASE ADD STANDBY LOGFILE ... - 最稳妥做法：当 gap 超过 5 分钟且 MRP 无法自愈，直接运行
RECOVER MANAGED STANDBY DATABASE CANCEL;→ 清理残留事务 → 重新启动 MRP
