Oracle 19c RAC无法真正在线调整私网MTU至9000，必须滚动重启CRS；因KSXP通信启动时校验对端MTU，仅ifconfig临时修改无效，需同步修改网卡配置、系统服务、交换机Jumbo Frame并严格按序操作。
不能真正“在线”调整 Oracle 19c RAC 私网 MTU 到 9000 —— 所有节点必须滚动重启 CRS（crsctl stop has -f / crsctl start has），否则 ASM 和数据库实例会因 IPC 协议不兼容持续报错，无法完成握手。
为什么 ifconfig/ip link 临时改了 MTU 还是启动失败
Oracle RAC 的私网通信（KSXP）在集群启动时会校验对端网卡的 MTU 值。即使你用 ip link set dev eth3 mtu 9000 在节点 A 上临时生效，只要节点 B 仍是 1500，节点 A 的 +ASM1_lmon_*.trc 就会反复报：
ORA-27303: additional information: Remote port MTU does not match local MTU. [local: 9000, remote: 1500]
这个检查发生在 crsctl start has 阶段，不是数据库 open 之后才触发。所以仅改 OS 层 MTU 不等于“RAC 已启用巨帧”。
必须同步修改的三个位置
缺一不可，否则任意一个环节残留 1500，都会导致跨节点 IPC 失败：
-
/etc/sysconfig/network-scripts/ifcfg-eth3中添加MTU=9000（RHEL/CentOS/OEL 系统） - 所有 RAC 节点执行
ip link set dev eth3 mtu 9000（或ifconfig eth3 mtu 9000），并验证：ip link show eth3 | grep mtu - 确认交换机端口已启用 Jumbo Frame（MTU ≥9000），且两端交换机配置一致；直连模式（无交换机）不被 Oracle 官方支持，
Doc ID 341788.1明确要求使用专用私网交换机
滚动操作时最容易忽略的步骤
很多人以为改完网卡、重启 CRS 就完事，但实际漏掉关键校验点：
- 改完所有节点的
ifcfg-*后，必须在每个节点运行systemctl restart network（或nmcli connection reload），否则重启后 MTU 会回退到 1500 - 执行
crsctl stop has -f前，先用crsctl check cluster -all确保所有资源已 clean shutdown，避免ora.asm持有旧状态 - 重启 CRS 后，立刻检查
tail -20 /opt/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_lmon_*.trc，确认不再出现skgxpvalpidrt或MTU does not match类错误 - 最后验证私网连通性：用
ping -Mdo -s 8972 192.168.11.102（假设目标私网 IP 是 192.168.11.102），不是ping -s 9000—— 因为 ICMP header 占 28 字节，有效载荷只能是 8972
真正麻烦的不是改 MTU 这一步，而是所有节点必须严格按顺序停 CRS → 改配置 → 重启网络服务 → 启 CRS → 校验日志。任何节点遗漏或顺序错乱，都会让整个集群卡在 IPC handshake 阶段，且错误日志里不会直接说“你少改了一个节点”，只会沉默地 hang 住。
