概要
在Oracle的RAC環境中，數據庫會收集global cache 的工作負載統計信息，並把這些信息通過STATSPACK, AWRs 和 GRID CONTROL等工具呈報。對於每個節點，以及集群匯總統計信息中的global cache數據塊丟失的統計信息("gc cr block lost" 和/或 "gc current block lost") 代表了私網通信的包處理效率低或者包的處理存在異常。這些信息是需要定期進行監控和評估來保證私網之間的global cache和 Enqueue服務（gcs/ges）以及集群之間的正常通信。任何塊丟失的信息都說明私網在對數據包的處理過程中是存在異常情況並且需要進行調查。
數據庫絕大部分的 “global cache lost blocks”的問題都可以直接聯系到私網的故障和錯誤的配置。本文可以作為調查和評估常見原因（有時是非常明顯）的指南。
盡管我們討論的大部分都是性能問題，但是這些問題也有可能會導致節點或實例的驅逐。Oracle集群和RAC實例依賴於心跳來維持節點關系。如果網絡心跳持續無法連通，那么實例/節點驅逐就會發生 。因此，以下的這些症狀也和節點/實例驅逐相關。
場景
主要:
"gc cr block lost" / "gc current block lost" 出現在AWR的top 5等待事件中或者產生了非常多的等待。
其次:
-
SQL traces 文件中多次出現 gc cr requests / gc current request
-
出現 gc cr multiblock requests 等待，每次等待時間都很長而且elapsed times 都一樣。
-
應用的性能和吞吐量都很差
-
通過ifconfig或者其它第三方的工具能夠看到網絡上發送和接受包的錯誤
-
使用netstat命令會看到一些error/retransmits/reassembly failures
-
節點故障和節點通信錯誤
-
大量的CPU消耗在網絡進程上
注意: 塊丟失的問題通常會和gc cr multiblock requests 等待同時出現，如：等待連續的塊掃描。
診斷指南1網線/網卡/交換機問題
描述：壞掉的網線連接，錯誤的電纜，制作粗糙的電纜，過於冗長和錯誤的端口分配，有問題的交換機都會導致低下的傳輸率，塊損壞，數據包丟失和性能問題。
解決：敦促網絡供應商對網絡進行檢查，更換壞掉的網絡組件。集群私網應該使用CAT 5 級或者是更好的通信線纜.所有的設備都需要確保安全插牢，並且按照線纜和端口進行標識，線纜的長度需要符合供應商指定的要求。
2UDP設置太小/UDP buffer socket溢出
描述:Oracle RAC Global cache塊的處理是突發性的，因此，操作系統需要緩沖區來接受接收（RX）數據包並等待CPU的處理,如果緩沖區設置的不合理或者過小會導致塊丟失和global cache 塊丟失。通過'netstat -s' 或者 'netstat -su'命令可以幫助我們在unix平台上獲取到UDPInoverflows，package receive errors, dropped framces 或packets dropped due to buffer full errors信息。
解決:數據包丟失往往是由於在接收服務器上設置的UDP緩沖區不足，從而導致了塊在緩沖區中溢出而產生塊丟失。當OS的緩沖區設置小於128k的時候，Oracle 在打開一個socket 時會設置 UDP receive buffer 尺寸為 128k。如果OS的緩沖區設置大於128k，Oracle會采用OS 的設置。如果數據庫的塊尺寸大於8k，那么緩沖區會自動的進行調整，但是不會超過OS的限制。當DB參數DB_FILE_MULTIBLOCK_READ_COUNT的值大於4時，如果發現 UDP buffer overflows, packet loss 和 lost blocks，並且數據庫出現了大量的"global cache cr requests"等待超時，這是由於緩沖區設置過小導致的，我們可以通過調大OS的UDP緩沖區的或者調低數據庫參數DB_FILE_MULTIBLOCK_READ_COUNT來解決問題 ，這個參數可以在系統或session級別調整。
對於大部分的unix平台，我們可以通過以下的一些命令來判斷是否出現UDP緩沖區溢出或者block loss，執行：
'netstat -s' 或 'netstat -su'，並根據具體平台查看 "udpInOverflowsudpInOverflows", "packet receive errors", "fragments dropped" 或 "outgoing packet drop" 信息
注意：UDP丟包通常會引起更多的延遲，網絡帶寬減少，更高的CPU使用率(kernel 和user)，以及消耗更多的內存來處理這些包的重傳。
在系統運行時，如果工作節點（運行負載的節點）對應的遠程節點上命令netstat –s的輸出中 "outgoing packets dropped"值顯著的增加，同時增加wmem_default 和 wmem_max到4M（Linux平台）可以解決問題。
UDP發送和接收緩沖區參數是和操作系統有關的，它們可以滾動（rolling）修改（例如：每次1個節點）。
3私網性能差，出現packet reassembly failures
描述：根據MTU（Maximum Transmission Unit）的尺寸，大的UDP數據包可能被分片，並在多個幀中發送。這些零散的數據包需要在接收節點上重新組合。高CPU使用率（持續的或者是頻繁的峰值），過小的reassembly buffer或者UDP buffer也會導致塊重組失敗。在接收節點’netstat -s’輸出的 "IP Statistics"部分提示有大量的Internet Protocol (IP)上的"reassembles failed" 和 "fragments dropped after timeout"信息。分片的報文需要在指定時間（time-to-live）內完成重組（reassemble）。沒有能夠完成重組的分片報文會被丟棄並要求重傳。已經收到，但是由於空間不足沒有進行重組的數據分片會被直接丟棄。
`netstat -s` IP stat counters:
3104582 fragments dropped after timeout
34550600 reassemblies required
8961342 packets reassembled ok
3104582 packet reassembles failed.
解決:增加reassemble buffer尺寸，給重組分配更多的空間。增加reassemble的時間，增加UDP receive buffer以避免由於網絡延遲導致的reassemble失敗，並找到對網絡數據包處理產生負面影響的高CPU 利用率原因.
注意:增加以下設置的同時也會增加內存的使用
LINUX
我們可以通過以下設置來修改reassemble buffer大小
/proc/sys/net/ipv4/ipfrag_low_thresh (default = 196608)
/proc/sys/net/ipv4/ipfrag_high_thresh (default = 262144)
我們可以通過以下設置來修改reassemble的時間:
/proc/sys/net/ipv4/ipfrag_time (default = 30)
請參考OS文檔了解不同平台的對應命令語法。
4網絡傳輸壞塊
網絡傳輸壞塊（corruption）導致的UDP checksum errors 和/或 send (tx) / receive (rx) transmission errors。
描述：UDP包傳輸的過程中，接受進程會讀取數據包頭的校驗值。任何校驗值損壞都會使這個包被丟棄，並導致重發，這會增加CPU的使用率並且延緩數據包處理。
解決：使用 tcpdump，snoop等網絡工具來捕獲數據包的dump,定位這些checksum錯誤並確認checksum corruption。敦促OS或者網絡管理員查找產生corruption的原因。 已知的問題是由於網卡上開啟了Checksum offloading 導致了checksum 錯誤，如果出現這樣的問題請檢查checksum offloading的功能是否被禁用，測試后考慮關閉網卡上的該項功能。在Linux系統上執行ethtool -K <IF> rx off tx off可以關閉該功能。
5通信通道中設置了不匹配的MTU的值
描述：不匹配的MTU大小設置會導致傳輸過程中出現 "packet too big" 錯誤並丟失數據包，導致global cache block丟失和大量的重傳（retransmission）申請。.
解決：MTU 是"Maximum Transmission Unit" 或者是私網通信過程中幀的尺寸.
對於以太網（Ethernet），大多數UNIX平台的默認值是1500字節。私網鏈路中所有設備都應該定義相同的MTU。請確認並監控私網鏈路中的所有的設備。為ping ,tracepath,traceroute命令指定大的，非默認尺寸，ICMP probe 包來檢查MTU設置是否存在不一致。使用ifconfig或者廠商推薦的工具為服務器網卡（NIC）的MTU設置合適的值。關於JUMBO Frames的設置，請見第12點的介紹。
注意：私網中不一致的MTU值會導致節點無法加入集群的問題。
6使用非專用的私網鏈接
描述:共享的公網和私網配置會導致應用性能低下，網絡擁堵，在一些極端的情況下會導致global cache block loss.
解決:數據庫/集群私網應該使用獨占的VLAN，並定義在non-routed子網中。私網的交換機需要獨立於其他的交換機，例如，私網交換機不應該是從接入層的交換機擴展出來,私網的交換機不應該和公網或者NAS的交換機共享。如果使用了VLANs，那么私網應該被划分在單獨的VLAN中，並且位於獨占的 ，non-routed 子網，獨立於公網或者NAS網絡。
7服務器/交換機缺少“鄰接”（adjacency）配置
描述:通常，如果網絡上的設備能夠通過單跳鏈接，我們稱為“鄰接”(adjacency).多跳的配置會增加網絡上的延遲，也會增加更多的節點故障風險.
解決:所有的 GbE(千兆以太網)服務器的私網鏈接都應該鄰接在交換機或者交換機組（如果配置了交換機冗余）上。在私網鏈路中，不應該出現中間網絡設備，例如：路由器。在Unix平台上，我們可以通過tracetroute命令來確定“鄰接”問題。
8配置了 IPFILTER
描述：配置主機防火牆或網絡地址轉換（NAT）軟件-- IPFILTER (IPF)也是導致私網通信問題的原因之一。IPF還會導致嚴重的應用程序性能下降，丟包以及global cache block loss問題.
解決:禁用 IPFILTER。
9過時的網卡驅動程序
描述:過時的網卡驅動程序或固件，是已知的私網數據包傳輸問題原因。不兼容的網卡驅動程序會導致節點間通信過程中數據包處理延遲，延遲增加和丟包。
解決：所有節點上的網卡應該采用相同的制造商和型號，相同的性能參數，和對稱的插槽(slot) ID。集群中所有節點的私網網卡固件和驅動程序都應該是一致的（最新的）。
10特別的私網鏈接和網絡協議
描述:非標准的，專享的網絡協議，如LLT ，HMP等已經被證明是不穩定的而且很難debug。使用非標准的，專享的網絡協議會導致應用的性能下降，丟包和節點重啟等故障。
解決:Oracle使用1GbE UDP 作為傳輸和通信協議，這已經被證明是穩定的，可靠的和高性能的。請避免使用特別的和非標准的通信協議。 在一些平台上，基於Inifiniband 的IP和RDS協議是可用的並且是Oracle支持的，而且10GbE已經被認證(詳細信息請參見OTN) - Oracle還在進行這方面的認證工作。
11錯誤配置的網卡綁定/鏈路聚合
描述:服務器上錯誤的網卡綁定或鏈路聚合配置，鄰接的私網交換機上錯誤的聚合配置會導致性能下降，出現由"port flapping"導致的block loss，交換機上構成私網端口的聚合鏈路發生頻繁的"UP"/"DOWN"狀態切換。
解決：如果在集群服務器上為私網配置了鏈路聚合，那么交換機上的端口也應該支持這種配置，並按照聚合配置來配合私網的通信。交換機上構成私網端口的聚合鏈路配置錯誤會導致 'port flapping'，交換機端口會被隨機刪除，導致丟包.對於綁定和聚合，請參考驅動器（driver）文檔進行配置，並且在有工作負載的環境下進行測試。 有很多公開的工具和軟件可以協助進行帶寬和性能延遲的測試（請參考iperf）。我們應該通過評估OS,網絡和網絡驅動器的統計數據來確定綁定的性能。
12錯誤的巨幀（Jumbo Frame）配置
描述：錯誤的Jumbo Frames配置會產生之前提到的不一致的MTU問題
解決：Jumbo Frames 並不是IEEE 標准配置，所以配置的時候應該很小心。單個Jumb Frame的大小是9000 bytes左右。Frame 的大小取決於網絡設備供應商，在不同的通信設備上的大小可能是不一致的。如果默認的MTU 尺寸不是9000bytes，請保證通信路徑中的所有設備（例如：交換機/網絡設備/網卡）都能夠支持一個統一的MTU值，在操作的過程中必須把Frame Size（MTU Size）配置成這個值。不合適的MTU設置，例如：交換機上配置MTU=1500,但是服務器上的私網網卡配置成MTU=9000，這樣會造成丟包，包的碎片和重組的錯誤，這些都會導致嚴重的性能問題和節點異常宕機。大部分的平台上我們都可以通過netstat –s命令的‘IP stats’輸出發現包的碎片和重組的錯誤。大部分的平台上我們可以通過ifconfig –a命令找到frame size的設置。關於交換機上的配置查詢，需要查看交換機提供商的文檔來確定。
13網卡雙工（ Duplex）模式不匹配
描述：網卡的雙工模式不匹配是指，在同一個交互的鏈路上，一端使用的是全雙工模式，另外一端使用的是半雙工模式。這通常是是手動配置錯誤導致的 或者是一端配置被修改成半雙工模式時，另外一端配置成了auto-negotiate引起的。雙工模式不匹配會導致嚴重的私網通信性能問題
解決:集群中所有節點的私網網卡和交換機上的私網線路對應的雙工模式都應該配置為auto-negotiate。千兆以太網標准要求auto-negotiate 設置為”on”。雙工模式不匹配可能會導致嚴重的網絡性能下降，數據沖突和丟包的情況出現。 每次進行網絡硬件和軟件升級后都應該檢查auto-negotiate設置， Auto-negotiate 在所有的設備上都應該是1000全雙工模式。
14私網通信鏈路流量控制（Flow-control）不匹配
描述：流量控制是指，當一台服務器傳輸的速度比接收節點（或者是網絡設備）的接受速度快 。接收設備會發送“暫停”幀來請求發送端暫時停止發送數據包.
解決：交換機和服務器網卡之間Flow-control設置不匹配的時候會導致丟包和嚴重的網絡性能問題。大部分的情況下，默認的設置"ON"是最好的結果。例如：
tx flow control should be turned on
rx flow control should be turned on
tx/rx flow control should be turned on for the switch(es)
盡管如此，對於一些特殊的案例，例如一些OS或交換機固件的bug，設置成OFF(所有的網絡路徑)會有更好的結果。
注意：Flow control的設置在固件/網絡驅動程序升級后會發生變化，網卡/交換機的設置應該在升級后重新檢查。如果沒有設備提供商的其它建議值，請使用默認的值。
15OS，網卡，交換機層面的數據包丟棄
描述：任何被OS，網卡或者交換機提示的包丟棄信息都應該被徹底的調查和解決。包丟失會導致私網性能降低，CPU使用過高以及節點異常宕機等情況。
解決：具體的工具會幫助我們確定包或幀丟失問題發生在那個層面（process/OS/network/switch）。netstat ,ifconfig,ethtool,kstat(依賴於OS的平台)命令輸出和交換機端口狀態是首先要進行檢查和評估的。您需要一些網絡嗅探器（sniffer）跟蹤點對點數據通信來排查問題（常見的工具：snoop/wireshare/ethereal）.
注意：從底層來理解丟包的原因是我們找到根本原因不可缺少的步驟。在網絡環境中，過小的網卡ring buffers或者receive queues是已知的導致網絡上異常丟包的原因，比如：在所有層面都沒有提示發生了丟包。請查看下面的網卡驅動問題和Kernel queue長度.這種情況，需要聯系系統管理員和網絡工程師來確定根本的原因。
16網卡驅動/固件配置問題
描述：不合適的配置或者網卡中一些可調屬性的不恰當的默認也會導致丟包並增加重傳的請求.
解決：大部分網絡設備供應商提供的默認出廠配置是可以滿足應用要求的。盡管如此，一些網絡供應商提供的網卡設備需要修改interrupt coalescence設置和ring buffers描述符數量。interrupt coalescence是CPU發送和接受數據包的中斷率。ring buffer在 CPU中斷之間持有需要處理的rx 包。不合適的配置會導致在這個層面丟失數據包，診斷這個層面的問題需要系統管理員以及OS/設備提供商的參與。
17網卡發送(tx)和接受（rx）隊列的長度
描述：設置過小的網卡tx/rx隊列長度會導致在隊列滿的時候出現丟包的情況，這會導致gc block loss，增加重傳並且降低私網的效率。
解決：在內核網絡子系統（kernel network subsystem）和網絡接口設備驅動程序之間移動數據時，發送（TX）和接收（Rx）隊列用來實現對數據包的傳輸和處理進行管理.這些隊列的大小是可以配置的。針對產生的網絡流量或者配置了MTU的情況，如果這些隊列的配置不合適或者過小，隊列填滿后會導致數據包的丟失或溢出。取決於設備的驅動程序和搜集到的統計信息數量，這類丟包是不容易被發現的，診斷這個層面的問題需要系統管理員和OS/設備的提供商的介入。（通常在linux上我們設置參數：iftxtqueue 和netdev_max_backlog）。
18有限的負載能力和過於飽和的帶寬
描述：過載的網絡使用也會導致私網的性能問題和丟包。
解決：私網配置的最佳實踐是您需要知道您的網絡使用情況和帶寬。這需要通過定期的監控來獲取使用的趨勢，瞬時值和恆定的值。私網上突然增加的使用請求可能是應用程序調整或異常導致的，如性能很差的SQL語句或者異常產生的數據流量。找到產生帶寬飽和的原因並解決它。
19過度的CPU申請和調度延遲
描述：持續的高負載和網絡堆棧的調度延遲也會對私網的數據包傳輸產生負面的影響並且會導致私網的性能下降，丟包，gc block loss和節點的重啟問題。
解決：持續的高CPU使用率導致的調度延遲也會導致網絡上數據包的延遲處理。過度，持續的延遲會導致嚴重的性能下降，並可能導致群集節點故障。關鍵是要找到持續的高CPU使用率的原因。使用uptime命令能夠列出大部分操作系統的平均負載情況，和網絡堆棧處理相關的CPU問題，可以通過NIC interrupt coalescence或者綁定網絡到單個CPU得到緩解，請和網絡設備的供應商一起來進行此類的優化。調度延遲會導致數據包重組錯誤。請參見本文的第2點。
20和交換機相關的數據包處理問題
描述：交換機的端口緩沖區溢出，交換機擁堵和配置問題，比如MTU大小，網絡聚合和VLANS 都能導致低效率的數據包處理和集群節點故障。
解決：Oracle私網需要一個包含交換機的以太網網絡。交換機是私網中點對點通信至關重要的組成部分。作為一個網絡設備，這個交換機會受到多種因素的影響並導致私網通信性能和高可用性出現異常。監控交換機的異常，數據包處理事件，臨時的或持續的吞吐量信息是非常重要的。交換機的狀態統計信息，應該定期進行檢查並評估是否正常，並找出異常情況。
21QoS對私網數據包處理產生的負面影響
描述：在交換機上定義的QoS會共享私網通信的帶寬並影響私網處理能力，導致私網性能的下降。
解決：如果私網布置在共享交換機的VLAN上，QoS應該通過優先級配置來避免對私網通信產生負面的影響。任何QoS的定義在布置前都應該進行評估，確保不會影響私網通信。
22重聚過程中生成樹限電
描述：以太網使用生成樹協議(STP)來避免網絡環路，確保交換機和冗余的交換機能直接路由到服務器。任何包含在STP拓撲中的設備故障都會導致重新計算路由到主機的重聚。如果STP協議在局域網中被起用，但是配置的有問題或未經優化，網絡重聚事件可能需要長達1分鍾或者更長的時間（取決於網絡的規模和參與設備）。這種延遲會導致私網問題和集群范圍的中斷。
解決：很多交換機供應商提供優化的擴展，使STP能夠實現更快的網絡重聚。例如： Rapid Spanning Tree (RSTP), Per-VLAN Spanning Tree (PVST)和Multi-Spanning Tree (MSTP) 可以避免集群大范圍的異常出現。
23STREAMS隊列的sq_max_size 配置太小
描述：AWR 提示 "gc cr block lost" 和/或"gc current block lost"等待時間很高。 netstat 並沒有提示有任何數據包處理的錯誤. `kstat -p -s '*nocanput*` 返回非0值. nocanput 說明streaming message隊列已滿，並且包被丟棄。 客戶在Solaris平台RAC環境下使用STREAMS。
解決：增加UDP max buffer space，並且把STREAMS隊列設置成unlimited能夠解決問題，並且消除"nocanput" lost messges。以下是Solaris平台下對應的命令：
`ndd -set /dev/udp udp_max_buf <NUMERIC VALUE>`
set sq_max_size to 0 (unlimited) in /etc/system. Default = 2
udp_max_buf 控制UDP socket發送和接受緩沖區的大小，默認值是262,144 bytes，這個值對於使用STREAMS的應用來說是不夠用的。sq_max_size 控制message的隊列的長度。
24VIPA和DGD設置不正確（僅限Aix平台）
如果您在AIX平台上使用了VIPA（Virtual IP Address），那么Dead Gateway Detection (DGD)必須配置成允許UDP failover模式。
默認的DGD參數可以作為配置起始值，但是在一些客戶的環境中，這些參數可能需要調整，但是無論何種情況，都必須設置成大於1的值。默認的設置如下：
dgd_packets_lost = 3
dgd_ping_time = 5
dgd_retry_time = 5
更多配置信息，請參考文章Using VIPA and Dead Gateway Detection on AIX for High Availability Networks, including Oracle RAC： http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102177
25Solaris+Vertis LLT的環境上，交換機的錯誤配置
當VCS命令lltstat的輸出顯示"Snd retransmit data"增加時，gc block lost 也會增加。把私網交換機的速度從fixed修改成auto-negotiate，更均勻地分布電纜到每個模塊的鏈接，這樣有助於解決"gc blocks lost"的問題。
原因
綜上，正如上面解釋的，塊丟失問題通常是由不可靠的私有網絡造成的。這可能是由於一個不良補丁或錯誤的網絡配置或硬件問題導致的。
大多數情況下，gc block lost 問題是由於：(a)、缺少OS補丁；(b)、壞掉的網卡；(c)、 有問題的線纜；(d)、有問題的交換機；(e)、網絡設置 造成的。