在Oracle RAC的環境中，如果我們發現OSW監控數據顯示包重組失敗率過高，就需要引起足夠的重視，因為這很可能會引發member kill/Node kill等重大故障，甚至在有些場景會連帶影響到所有RAC節點不可用。
一般我們會選擇調整ipfrag相關參數。除此之外，還有一種解決方案就是選擇調整私網網卡的MTU值，通常Oracle使用8k標准塊大小時，會選擇設置MTU=9000，從而減緩包重組失敗次數的增長速率，期望的理想狀態下是完全沒有包重組失敗的發生。
需要注意的是，修改MTU需要心跳交換機配合做相應的修改和適配，確保使用的交換機能夠支持巨幀，所以通常給客戶的建議會優先給出方案一，實施方案一效果不理想的情況下才會考慮方案二。
方案一：修改ipfrag相關參數
官方建議一般是修改：
net.ipv4.ipfrag_high_thresh=16M
net.ipv4.ipfrag_low_thresh=15M
這個修改的官方主要依據是 RHEL 6.6: IPC Send timeout/node eviction etc with high packet reassembles failure (Doc ID 2008933.1) ，雖然文檔給出的是RHEL6.6，但實際經驗是在6.6以后的版本也建議修改，在很多真實案例中，不止局限於6.6這個版本。
另外，如果實際業務量比較大，可以考慮進一步增大這兩個值，比如修改為32M/31M甚至64M/63M，一般high和low相差1M即可。
結合公司專家們的實戰經驗，對ipfrag系列參數給了一個參考，我這里結合網上的資料和RHEL7系統的默認值進行對比：
net.ipv4.ipfrag_high_thresh = 41943040 #分片占用內存的高閾值，默認值4194304
net.ipv4.ipfrag_low_thresh = 40894464 #分片占用內存的低閾值，默認值3145728
net.ipv4.ipfrag_time = 120 #分片超時時間，默認值30
net.ipv4.ipfrag_secret_interval = 600 #默認值600
net.ipv4.ipfrag_max_dist = 1024 #分片有效的最長間隔距離，默認值64
這里除了修改ipfrag_high/low_thresh由默認的4M/3M改為40M/39M之外，還將ipfrag_time由默認值的30修改為120，ipfrag_max_dist由默認的64修改為1024。但是這個並沒有找到Oracle官方的說明，只是從參數含義的角度來看應該會有所改善。這里先不作為優先修改項。
方案二：使用巨幀，調整MTU值
這個修改的官方主要依據：Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID 341788.1)
當方案一實施后效果不明顯時，則考慮調整MTU值，這里選擇設置MTU=9000：
修改私有網卡MTU為9000:
ifconfig <網卡名稱> mtu 9000
查看MTU是否更改成功：
ifconfig <網卡名稱>
修改私有網卡配置文件，添加MTU=9000的配置，以確保主機重啟后MTU=9000不變：
vi /etc/sysconfig/network-scripts/ifcfg-<網卡名稱>
配置文件末尾新添加一行MTU=9000的配置：
MTU=9000
在實際測試驗證中發現，節點1主機重啟后無法啟動ASM實例，alert明確報錯MTU遠端是1500，即使遠端ifconfig臨時修改MTU=9000也不行，這個結果還是很意外的，之前沒想到這個mtu的修改居然不能實現完全滾動，也就是說停機是不可避免的（ifconfig可以動態修改mtu，但是如果rac想用上mtu=9000的話需要重啟）。
--節點1主機重啟后無法啟動ASM實例，alert明確報錯MTU遠端是1500，即使遠端已經臨時修改過MTU=9000：
2020-07-03T17:15:52.602414+08:00
Errors in file /oracle/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_lmon_12878.trc:
ORA-27300: OS system dependent operation:config_check failed with status: 0
ORA-27301: OS failure message: Error 0
ORA-27302: failure occurred at: skgxpvalpid
ORA-27303: additional information: Remote port MTU does not match local MTU. [local: 9000, remote: 1500] (169.254.1.60)
在MOS 947223.1文檔中也有說明：After correct MTU issue, a node reboot is required to bring up CRS stack and ASM instance for 11.2 release.
如何判定包重組失敗的現象是否存在風險？
上面講了半天的包重組失敗，那該如何判定當前系統包重組失敗是否存在風險？當然理想環境下，不應該出現包重組失敗的現象，但如果環境不夠理想，那有沒有一個參考值，多長時間內包重組失敗超過多少次就會有問題？或者有其他的判定標准？
目前了解到的是對於Oracle RAC，對包重組失敗速率並沒有一個統一的標准來定義正常/不正常的臨界值：
為此客戶也開過SR求證，O原廠回復也是說沒有一定的標准，只是基於數據庫性能和穩定性方面建議是減少內網包重組現象。
我也咨詢了專家羅海雄老師，認為一般30s內包重組失敗超過5個就需要給予一定的關注，持續觀察是否存在風險，並給出下面的awk命令來輔助觀察osw的netstat數據：
awk '/zzz/{d=$4"-"$5}/packet reassembles failed/{curr=$1;diff=curr-prev;if(diff>5)print d,diff,prev,curr;prev=curr}' *.dat
根據上述語句分析了10余套系統，唯有出現過問題的這套環境依然存在風險，下一步計划修改MTU值后再觀察。
此外，O原廠建議增加OSW私網的監控，但需要注意增加這個監控后，不止多了oswprvtnet等監控數據，之前netstat監控數據的格式也會發生變化，會詳細列出每個網卡的監控信息，但格式變化后的連帶影響就是上面awk腳本不再可用了，觀察新的數據格式，改寫腳本如下：
awk '/zzz/{d=$4"-"$5}/IpReasmFails/{curr=$2;diff=curr-prev;if(diff>5)print d,diff,prev,curr;prev=curr}' *.dat
最后要提一下的是，當出現這類問題時，還要配合檢查私網本身是否存在問題，比如：網卡、網線、交換機等，都要確保狀態正常，排除硬件本身的問題。