一、背景与问题现象

在数据库运维中，性能突降是最常见的“疑难杂症”之一。本次案例中，业务反馈某核心库响应变慢，我们首先通过 AWR（Automatic Workload Repository）报告 定位数据库层等待事件，再结合系统级网络统计，最终发现问题的根源竟藏在网络分片重组失败的底层细节中。

步骤1：AWR报告——数据库层的“症状”诊断

打开AWR报告的「Top 10 Foreground Events by Total Wait Time」部分（图1），重点关注以下指标：

关键解读：

• DB CPU占比高：说明数据库自身计算负载大，但需结合其他等待事件判断是否为“真瓶颈”。
• Cluster类等待事件突出：gc cr block lost（全局缓存一致性读块丢失）、gc buffer busy acquire（全局缓存缓冲区忙等待）等事件占比超40%，指向RAC集群节点间的缓存同步效率低下。

步骤2：系统级网络统计——跳出数据库层的“盲区”

若仅盯着AWR，容易陷入“数据库调优”的思维定式。此时需下沉到操作系统层，用 netstat -s 命令查看网络协议栈的统计信息（图2、图3）：

[root@ts860a ~]# netstat -s | grep dropped
...
223635 fragments dropped after timeout  # 分片超时丢弃！
9 ICMP packets dropped because they were out-of-window
...

更致命的是 packet reassembles failed 计数：

关键解读：

• IP分片超时丢弃：当数据包被拆分为多个分片传输时，若部分分片因网络延迟/丢包未及时到达，接收端会因“超时”丢弃整个数据包，导致重传。
• 分片重组失败：进一步验证了网络层存在MTU不匹配、链路不稳定或中间设备（如防火墙、交换机）对分片处理异常的问题。

步骤3：全链路归因——从“数据库等待”到“网络分片”的逻辑链

将AWR与网络统计关联后，可梳理出清晰的因果链：

1. 网络层分片问题 → 数据包丢失/重传 → 节点间通信延迟增加；
2. RAC集群依赖高速内网同步缓存 → 网络延迟导致 gc cr block lost（缓存块传输超时丢失）、gc buffer busy acquire（等待其他节点的缓存响应）；
3. 数据库层等待时间飙升 → 业务SQL执行变慢，最终表现为“性能突降”。

二、解决方案与优化方向

针对上述分析，需从网络层和数据库层双向发力：

1. 网络层：修复分片与链路稳定性

• MTU统一配置：检查RAC节点间网卡、交换机、存储网络的MTU值，确保一致（推荐Jumbo Frame，如9000字节），避免因MTU不匹配触发分片。
• 链路冗余与监控：部署双网卡绑定（Bonding）、多路径交换，同时用 ping、mtr 等工具持续监测节点间延迟与丢包率。
• 中间设备调优：若存在防火墙/负载均衡器，需关闭“分片重组”功能（让终端设备自行处理），或调整其分片超时阈值。

2. 数据库层：缓解集群等待压力

• 缓存参数优化：调整 gc_buffer_pool、cache_size 等参数，减少跨节点缓存请求频率。
• SQL执行计划审查：通过AWR的「SQL Statistics」模块，定位高消耗SQL，优化索引、改写SQL逻辑，降低单条SQL的缓存交互次数。
• 集群架构评估：若业务增长导致节点间通信成为瓶颈，可考虑拆分热点表、引入读写分离或升级硬件（如万兆内网）。

三、调整MTU解决问题

网络交换机私网端口和服务器网卡调整MTU
网络配置：

*****************************************************************************
*Copyright (c) 2004-2022 New H3C Technologies Co., Ltd. All rights reserved.*
*without the owner's prior written consent,                                 *
*no decompiling or reverse-engineering shall be allowed.                    *
*****************************************************************************
<DC-B1-LT2-02>
<DC-B1-LT2-02>dis cur in
<DC-B1-LT2-02>dis cur interface te
<DC-B1-LT2-02>dis cur interface Ten-GigabitEthernet
<DC-B1-LT2-02>dis cur interface Twenty-FiveGigE 1/4/5
#
interface Twenty-FiveGigE1/4/5
 port link-mode bridge
 port access vlan 2028
 jumboframe enable 9000
#return
<DC-B1-LT2-02>

vi /etc/sysconfig/network-scripts/ifcfg-<网卡名称>，配置文件末尾新添加一行MTU=9000的配置，并ifconfig确认：

配置完成，启动发现有gipc异常

跟踪了一下，发现MTU不能达到9000，主要是交换机配置的问题，建议交换机配置比9000要大

[root@ts860a bin]# ping -c 2 -M do -s 8973 ts860b-priv2
PING ts860b-priv2 (192.168.19.243) 8973(9001) bytes of data.
ping: local error: Message too long, mtu=9000
ping: local error: Message too long, mtu=9000

--- ts860b-priv2 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms

[root@ts860a bin]# ping -c 2 -M do -s 8900 ts860b-priv2
PING ts860b-priv2 (192.168.19.243) 8900(8928) bytes of data.
8908 bytes from ts860b-priv2 (192.168.19.243): icmp_seq=1 ttl=64 time=0.138 ms
8908 bytes from ts860b-priv2 (192.168.19.243): icmp_seq=2 ttl=64 time=0.134 ms

--- ts860b-priv2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.134/0.136/0.138/0.002 ms
[root@ts860a bin]#

当然修改服务器的MTU为8900也是可以的。

四、经验总结：性能排查的“分层思维”

本次案例的核心启示是：数据库性能问题未必是“数据库本身”的锅。当AWR显示集群等待事件突出时，需跳出“SQL调优”的惯性，向下穿透到操作系统、网络甚至硬件层，才能找到真正的根因。