问题说明：
业务人员反馈有一个跑批作业中的一条 update 耗时变长，之前 2 分钟执行完成，最近需要 30 多分钟还未返回结果。
环境说明：
DB:Oracle 11.2.0.3.0 RAC
OS:AIX 7.1
问题分析：
猜测update语句变慢有如下几个原因： (1)数据量发生了变化。 经检查，数据量没有太大变化。 (2)执行计划发生了变化。 经检查，执行计划并没有发生改变。 (3)出现锁等待。 问题期间，检查此update操作并没有被阻塞。 (4)触发器 并没有触发器。 (5)数据库出现性能瓶颈。 通过等待事件可以看到最严重的的两个等待事件分别是"gc cr block lost" 和 "gc current block lost"
排查过程：
通过tfactl收集问题时间段的日志。 $ORACLE_HOME/bin/tfactl diagcollect -asm -crs -database all -os -from "Jul/26/2021 08:00:00" -to "Jul/26/2021 08:10" 没有执行成功，默认11203没有安装tfactl。
在检查update语句时，业务又反馈出现大批量select语句也执行慢的问题，比之前慢很多。 此刻意识到并不是某一个SQL出现了问题，可能是整个数据库出现了瓶颈。 根据"gc cr block lost" 和 "gc current block lost"等待事件，可以知道私网通信的包处理效率低或者包的处理存在异常。
"gc cr block lost" 和 "gc current block lost"等待事件出现的原因： Troubleshooting gc block lost and Poor Network Performance in a RAC Environment (Doc ID 563566.1) 1.网线/网卡/交换机问题 2.UDP设置太小/UDP buffer socket溢出 3.私网性能差，出现packet reassembly failures 4.网络传输坏块 5.通信通道中设置了不匹配的MTU的值 6.使用非专用的私网链接 7.服务器/交换机缺少“邻接”（adjacency）配置 8.配置了 IPFILTER 9.过时的网卡驱动程序 10.特别的私网链接和网络协议 11.错误配置的网卡绑定/链路聚合 12.错误的巨帧（Jumbo Frame）配置 13.网卡双工（ Duplex）模式不匹配 14.私网通信链路流量控制（Flow-control）不匹配 15.OS，网卡，交换机层面的数据包丢弃 16.网卡驱动/固件配置问题 17.网卡发送(tx)和接受（rx）队列的长度 18.有限的负载能力和过于饱和的带宽 19.过度的CPU申请和调度延迟 20.和交换机相关的数据包处理问题 21.QoS对私网数据包处理产生的负面影响 22.重聚过程中生成树限电 23.STREAMS队列的sq_max_size 配置太小 24.VIPA和DGD设置不正确（仅限Aix平台） 25.Solaris+Vertis LLT的环境上，交换机的错误配置
综上所述，出现 gc cr/current block lost 主要原因：
(1)网线/网卡/交换机出现问题。 (2)网络相关参数配置不合理。
收集问题期间 AWR 报告：
gc cr block lost等待了1万多次，平均等待时长568ms 通过AWR报告中的Global Cache Load Profile可以看到Estd Interconnect traffic(KB)只有400多KB，流量也不大。
检查操作系统网络信息：
发现有大量的fragments dropped after timeout sy-creditrisk-db02[/home/oracle]$netstat -s|grep fragments 21625481 fragments dropped after timeout no -a | grep -E 'udp_sendspace|udp_recvspace|tcp_sendspace|tcp_recvspace|rfc1323|sb_max|ipqmaxlen|tcp_ephemeral|udp_ephemeral' no -a | grep ephemeral
udp_sendspace 值设置偏小
官方的建议udp_sendspace = ((DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4 KB) 数据库的block_size应该是8192,多块读是128 可以考虑调整以下值： # /usr/sbin/no -p -o sb_max=20971520 # /usr/sbin/no -p -o tcp_sendspace=1048576 # /usr/sbin/no -p -o tcp_recvspace=1048576 # /usr/sbin/no -p -o udp_sendspace=2097152 # /usr/sbin/no -p -o udp_recvspace=20971520
但是由于这些值一直没有改过，并且其他很多数据库都是这种配置，并且出现问题期间， RAC 节点间通信流量并不大，所以问题很有可能出在网络上，需要重点排查网卡、交换机的。
网络排除：
测试两节点私有网络ping无延时和丢包现象。 最后发现节点1私有网卡光衰特别大，怀疑光模块损坏。
解决方案：
一、联系硬件厂商更换光模块。 二、切换主备网卡 由于心跳网卡做了双网卡绑定，主备模式，当前主网卡出现问题，可以尝试切换到备网卡解决此问题，切换网卡步骤如下： 1.查看bond网卡信息 lsdev -Cc adapter 2.查看bond卡绑定信息 lsattr -El ent01 ---绑定后的网卡名 确认ent01由ent2和ent3绑定的bond网卡 3.查看bond卡网卡流量输出状态 entstat -d ent01 |more 确认ent2为主网卡，流量包输出 4.强制漂移网卡 输入如下命令，点击回车 smitty etherchannel 5.选择：Force A Failover In An EtherChannel / Link Aggregation 选择要漂移网卡回车-回车确认 6.查看bond卡网卡流量输出状态 entstat -d ent01 |more 三、验证 切换完网卡后，业务反馈恢复正常，可以正常跑批，检查netstat -s|grep fragments值也不在继续增加。
#####chenjuchao 2021-08-13 13:00#####