同一个数据库，同一次故障，两个人出据的数据库故障报告深度截然不同，很难受。
我要是早看到就不会多次发生这个问题了，不完全一致但解决排查思路是一致的，关键字：心跳网络、oracle rac 、网络异常宕机、packet reassembles failed 、UDP error
转载 自 https://www.anbob.com/archives/2851.html
转载 自 https://www.anbob.com/archives/2851.html
转载 自 https://www.anbob.com/archives/2851.html
以下为原文：
前几日和好友赵彬同学交流在ANBOB公众号投稿分享了一个案例，数据库第二个节点被驱逐出集群，并且多次自动重启以失败告终，驱逐原因在GI Alert log显示是私网通信丢失，而重启失败也是因为ASM无法启动，ASM db alert显示IPC Send timeout. 当时ping和tracert并没发现什么异常，从OSW中的netstat -s查看IP packet reassembles failed时间段值大量增长， 这是一套oracle 11.2.0.4 2Nodes RAC on RHEL 6.6的环境，另个每个数据库服务器CPU核数过百， 这个案例有多种巧合,如果CPU只有几个，问题也可能不会发生，如果是RHEL7也不会发生等等。当然最终以调速OS参数解决，但是原因更值得分析。
Node1 GI ALERT LOG
2017-03-02 11:46:26.607:
[/u01/11.2.0/grid/bin/oraagent.bin(121496)]CRS-5011:Check of resource "testdb" failed: details at "(:CLSN00007:)" in "/u01/11.2.0/grid/log/anbob/agent/crsd/oraagent_oracle//oraagent_oracle.log"
2017-03-02 11:46:26.612:
[crsd(175117)]CRS-2765:Resource 'ora.testdb.db' has failed on server 'anbob'.
2017-03-02 11:46:42.866:
[cssd(172139)]CRS-1612:Network communication with node db2 (2) missing for 50% of timeout interval. Removal of this node from cluster in 14.620 seconds
2017-03-02 11:46:50.869:
[cssd(172139)]CRS-1611:Network communication with node db2 (2) missing for 75% of timeout interval. Removal of this node from cluster in 6.620 seconds
2017-03-02 11:46:54.870:
[cssd(172139)]CRS-1610:Network communication with node db2 (2) missing for 90% of timeout interval. Removal of this node from cluster in 2.620 seconds
2017-03-02 11:46:57.493:
[cssd(172139)]CRS-1607:Node db2 is being evicted in cluster incarnation 351512591; details at (:CSSNM00007:) in /u01/11.2.0/grid/log/anbob/cssd/ocssd.log.
2017-03-02 11:46:58.626:
[cssd(172139)]CRS-1662:Member kill requested by node db2 for member number 0, group DBHBCRM
Node2 GI ALERT LOG
2017-03-02 11:46:45.378: [cssd(177450)]CRS-1663:Member kill issued by PID 84816 for 1 members, group DBCRM. Details at (:CSSGM00044:) in /u01/11.2.0/grid/log/db2/cssd/ocssd.log. 2017-03-02 11:46:58.982: [cssd(177450)]CRS-1608:This node was evicted by node 1, anbob; details at (:CSSNM00005:) in /u01/11.2.0/grid/log/db2/cssd/ocssd.log. 2017-03-02 11:46:58.983: [cssd(177450)]CRS-1656:The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /u01/11.2.0/grid/log/db2/cssd/ocssd.log
Note:
node2 因网络通信失败而自杀 member kill.
* allocate domain 7, invalid = TRUE
* domain 7 valid = 1 according to instance 1
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
Set master node info
Submitted all remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
Thu Mar 02 11:54:14 2017
IPC Send timeout detected. Sender: ospid 153935 [oracle@db2 (LMD0)]
Receiver: inst 1 binc 430132771 ospid 174276
IPC Send timeout to 1.0 inc 92 for msg type 65521 from opid 10
Thu Mar 02 11:54:16 2017
Communications reconfiguration: instance_number 1
Thu Mar 02 11:54:16 2017
Dumping diagnostic data in directory=[cdmp_20170302115416], requested by (instance=1, osid=174274 (LMON)), summary=[abnormal instance termination].
Reconfiguration started (old inc 92, new inc 96)
List of instances:
2 (myinst: 2)
Nested reconfiguration detected.
Global Resource Directory frozen
* dead instance detected - domain 1 invalid = TRUE
freeing rdom 1
* dead instance detected - domain 2 invalid = TRUE
freeing rdom 2
Note:
NODE2 的ASM因ipc time out失败一直未启动。
Node2 OSW netsat信息
zzz ***Thu Mar 2 11:40:31 CST 2017
75646 packet reassembles failed
zzz ***Thu Mar 2 11:40:52 CST 2017
77043 packet reassembles failed
zzz ***Thu Mar 2 11:46:33 CST 2017
131134 packet reassembles failed
Note:
这段时间产生了大量的IP packet reassembles failed. 汇总统计了之前的时间里是不存在这个问题的。
当然到这里如果你以以上信息为关键字在MOS中应该已经可以找到解决方案RHEL 6.6: IPC Send timeout/node eviction etc with high packet reassembles failure (Doc ID 2008933.1)。在NOTE中记录是因为OS过多的IP包重组失败导致，解决方法是加大重组的BUFFER大小或启用jumbo frame，对于jumbo frame需要硬件的支持，简单的就是增加network IP 重组buffer的大小。如RHEL 6.6中的
net.ipv4.ipfrag_high_thresh = 16M --default 4M net.ipv4.ipfrag_low_thresh = 15M -- default 3M
通常默认的应该满足基本需求的，像上面的调整在ORACLE的RHEL的最佳实践中也并未建议安装里调整，那后续的LINUX平台都要调整该参数么？ 带着这个问题我查开了LINUX 7.2的内核参数
[root@MiWiFi-srv ~]# sysctl -a|grep ipfrag net.ipv4.ipfrag_high_thresh = 4194304 net.ipv4.ipfrag_low_thresh = 3145728 net.ipv4.ipfrag_max_dist = 64 net.ipv4.ipfrag_secret_interval = 600 net.ipv4.ipfrag_time = 30
如果是参数配置不是最佳，为什么LINUX最新版并未改变，连ORACLE软件也没建议修改？ 那我们可以再深入研究一些。
什么是IP packet reassembles failed？
在linux平台使用netstat -s命令时会看到packet reassembles failed项， 记录的是IP重组包失败的累计数据值，什么时候要重组呢？当IP包通信存在碎片时。在网络通信协议中MTU（最大传输单元）限制了每次传输的IP 包的大小，一种是源端和目标端使用了不同的MTU时会交生碎片，这里需要先确认传输过程中的MTU大小配置，确认使用了相同的MTU；还有就是当传送的数据大于MTU时，回分成多个分片传递。这时调整MTU就不可能解决所有的IP包碎片的问题，可以通过加大通信的buffer值，尽可能保留更多的数据在源端拆包，目标端缓存等接收完整后再重组校验。 在LINUX系统中调整BUFFER使用ipfrag_low_thresh 和ipfrag_high_thresh参数，如果调整了这个参数仍有较大的重组失败还可以加大ipfrag_time 参数控制IP 碎片包在内存中保留的秒数时间。
如果在ORACLE RAC环境中一个节点突然产生了大量的数据包输送给另一个节点，如应用设计问题，如数据文件cache fusion或归档只能一个节点访问时,都加大了网络通信量，这里需要检查网络负载及丢包或包不一致的现象，因为ORACLE在网络通信中使用了UDP和IP通信协议，这两类信息都需要关注。
那是不是LINUX所有的系统都需要调整上面的参数呢？
不是的， 从RHEL了解这个问题基本也就出现在LINUX6.6，和部分6.7中，这个问题的根本原因是在linux6.6中引入了percpu
counters计数器在内核 kernel-2.6.32-477.el6， 在后面的linux
6.8(kernel-2.6.32-642.el6)和linux
6.7.x(kernel-2.6.32-573.8.1.el6)已经修复了该问题， 所以在其它配置中没有影响。
这个计数器是在每个CPU上一个，当CPU多时很容易超过默认的4M ipfrag_high_thresh， 所以这也是就是我一开始说的CPU多了也是这个问题的巧合，当网络传输大里更容易超过，而产生faild.
下面是RHEL的官方解释：
A bug has been added to address this for RHEL6.6, where IP fragmentation memory accounting fails under some conditions.