RAC 環境における gc block lost やネットワークパフォーマンス低下のトラブルシューティング (Doc ID 2215983.1)

Last updated on JANUARY 03, 2021

適用範囲:

Oracle Database - Enterprise Edition - バージョン 9.2.0.1 以降
Oracle Database Cloud Schema Service - バージョン N/A 以降
Oracle Database Exadata Cloud Machine - バージョン N/A 以降
Oracle Cloud Infrastructure - Database Service - バージョン N/A 以降
Oracle Database Backup Service - バージョン N/A 以降
この文書の内容はすべてのプラットフォームに適用されます。
Oracle Clusterware & Oracle Real Application Clusters

本文書利用上のご注意
本文書は英語の文書 <Document 563566.1> (最終メジャー更新日: 2018年02月01日) の日本語翻訳版です。
英語の文書のメジャー更新に応じて本文書を随時更新いたします。

現象

Summary

Oracle RAC 環境では、RDBMS は STATSPACK、AWR そして GRID CONTROL にレポートされる
グローバルキャッシュ作業負荷統計を収集します。
クラスタの集計統計のみならずクラスタの各ノードの Global cache lost blocks 統計
("gc cr block lost" や/または "gc current block lost") は、インターコネクトのトラ
フィックのパケット処理の問題や非効率性を表します。
これらの統計情報は、効率的なインターコネクトのグローバル・キャッシュとエンキュー・
サービス (GCS/GES) 及びクラスタ処理を保証するため、定期的に監視、評価される必要が
あります。ブロック損失は、ネットワークパケット処理に問題があることを示しており、
調査されるべきです。

RDBMS の global cache lost blocks に起因したエスカレーションの大半は、障害があるか
インターコネクトの誤った構成に関連しています。このドキュメントは、共通の (そして
時々明らかな) 原因を評価、調査するためのガイドを提供します。

議論の多くはパフォーマンスの問題に焦点を当てているにも関わらず、これらの問題により
ノード/インスタンス排除に至る可能性があります。Oracle Clusterware と Oracle RAC
インスタンスはノードメンバーシップのためのハートビートに依存しています。もし、ネット
ワークハートビートが常にドロップされる場合には、インスタンス/ノード排除が発生すること
があります。以下の事象は、ノード/インスタンスの排除に関連しています。

事象:

Primary:

top 5 または多くの "gc cr block lost" / "gc current block lost" 待機イベント

Secondary:

SQL トレースが長く均一の経過時間で複数の gc cr requests / gc current request /
gc cr multiblock requests をレポートする

アプリケーションのパフォーマンスの低下/スループット

ifconfig またはベンダーが提供するユーティリティに表示されるパケットの send/
receive のエラー

Netstat が errors/retransmits/reassembly の失敗をレポートする

ノードの障害とノードの組み込みの失敗

ネットワーク処理に起因する異常な CPU 消費

注: ブロック損失の問題はたいてい gc cr multiblock の待機と一緒に発生します。
例. 連続ブロックのスキャンを待機

原因:

考えられる原因は以下の診断ガイドに記載されています。(可能性の高いものから低い順)

Global Cache Block Loss の診断ガイド

故障またはきちんと取り付けられていないケーブル/カード/スイッチ

説明: 故障したネットワークケーブルの接続、誤ったケーブル、不完全に構築されたケーブル、
過度な長さと誤ったポートの割り当て、故障したスイッチは、劣ったビット速度、破損した
フレーム、パケットのドロップ、パフォーマンスの低下をもたらすことがあります。

アクション: フィジカルネットワークチェックを実施する、故障したネットワーク部品を交換
するため、ネットワークベンダーに問い合わせてください。CAT 5 またはより良いグレードの
ケーブルがインターコネクトリンクに配備される必要があります。該当する場合には、全ての
ケーブルはLAN/ポートとアグリゲーションに従って、しっかりと取り付け、ラベル付けされる
必要があります。ケーブルの長さは、ベンダーのイーサネットの仕様に準拠する必要があります。
不十分なサイズの UDP 受信 (rx) バッファサイズ / UDP バッファソケットオーバーフロー
説明: Oracle RAC の Global cache block 処理は、本来集中的なものです。その結果、OS は CPU の
待機中、受信 (rx) パケットをバッファする必要があるかもしれません。使用できないバッファ
スペースは、パケットロスや global cache block loss につながる可能性があります。
ほとんどの UNIX 上での 'netstat -s' または 'netstat -su' は、UDPInOverflows、パケットの
受信エラー、破棄されたフレーム、またはバッファフルエラーによるパケットの破棄の判断に
役立ちます。

アクション: パケットロスは、受信サーバ上のの適切ではない (rx) UDP バッファのサイズに起因し、結果として
バッファオーバーフローや global cache block loss となります。OS の設定が 128k 未満の場合、
Oracle がソケットをオープンする際、ソケットの UDP 受信 (rx) バッファサイズは 128k に設定
されます。OS の設定が 128k より大きいと、Oracle は変更せずにその値を使用しますが、OS に依存
する制限を超えて増加することはありません。UDP バッファオーバーフロー、パケットロス、破棄
ブロックは、DB_FILE_MULTIBLOCK_READ_COUNT が 4 より大きい場合に、不適切なバッファの設定による
"global cache cr requests" での過度なタイムアウトが発生する環境で見られます。この問題を軽減
するために、システムまたはアクティブセッションの UDP バッファサイズを増加し、
DB_FILE_MULTIBLOCK_READ_COUNT を下げます。

UDP ソケットバッファオーバーフローやパケットロスが発生しているかどうかを確認するには、
ほとんどの UNIX プラットフォーム上で、以下を実行してください。

プラットフォームに応じて 'netstat -s' または 'netstat -su' で "udpInOverflowsudpInOverflows",
"packet receive errors", "fragments dropped" または "outgoing packet drop" のいずれかを探します。

注: UDP パケットロスは通常、パケットの再送に対応するために、結果として待ち時間の増加、帯域の
減少、CPU 使用量 (kernel と sys) とメモリ消費量の増加となります。
もし、ワークロードが実行されているリモートノードの netstat -s の出力の TCP セクションの
"outgoing packets dropped" の大幅な増加がある場合、wmem_default と wmem_max の両方を 4MB (Linux)
に増やすことで問題が解消する可能性があります。

UDP の送受信バッファのパラメータが OS 依存の場合、ローリング方式 (例: 1 度に 1 ノード) で
変更することが可能です。
インターコネクトのパフォーマンスの低下、高い CPU 使用率。'netstat -s' が packet reassembly failures を記録する

説明: 大きな UDP データグラムが断片化し、最大伝送ユニット (MTU) サイズに基づいて、複数のフレームで送信
される場合があります。これらの断片化されたパケットは、受信ノードで再構成をする必要があります。

高い CPU 使用率 (持続的または頻繁な上昇)、不適切な再構成バッファ、そして UDP バッファスペースは、
packet reassembly failures を引き起こすことがあります。'netstat -s' は、受信ノードの出力の
"IP Statistics" セクション内で多数のインターネットプロトロコル (IP) "reassembles failed" と
"fragments dropped after timeout" を記録します。断片化されたパケットは再構築のための time to live が
あります。再構築されていないパケットは廃棄され、再度要求されます。到着して再構築のためのスペースのない
断片化は破棄されます。

`netstat -s` IP stat counters:
     3104582 fragments dropped after timeout
     34550600 reassemblies required
     8961342 packets reassembled ok
     3104582 packet reassembles failed.

アクション: fragment reassembly buffers を増やし、再構築のためのスペースをさらに割り当てます。パケットの断片化を
再構築する時間を増やします。再構築の失敗を悪化させるネットワーク処理の待ち時間に対応するため、udp の
受信バッファを増やし、ネットワークスタック処理に悪影響を与える CPU 使用率を特定します。
注: 次の設定を増やすとメモリ使用量も増加します。

LINUX では:
再構築バッファスペースを変更するため、以下の閾値を変更してください:

/proc/sys/net/ipv4/ipfrag_low_thresh (default = 196608)
/proc/sys/net/ipv4/ipfrag_high_thresh (default = 262144)

パケットの断片化の再構築時間を変更するため、以下を変更してください:
/proc/sys/net/ipv4/ipfrag_time (default = 30)

対応するコマンド構文は、ご使用の OS を参照してください。上記は RHEL 6.6 には適用されません。
<Note 2008933.1> RHEL 6.6: IPC Send timeout/node eviction etc with high packet reassembles failure
を参照してください。
UDP チェックサムエラーや send(tx)/receive(rx) 送信エラーによるネットワークパケットの破損

説明: UDP は受信時に読み取られるパケットヘッダ内にチェックサムフィールドを含みます。チェックサムが破損すると
パケットが破棄されます。チェックサムの破損は、パケットの再送、追加の要求に対する追加の CPU オーバヘッド、
およびパケット処理における待ち時間をもたらします。

アクション: cpdump/snoop/network ユーティリティやスニファユーティリティを使用して、パケットダンプをキャプチャして
チェックサムエラーを特定し、チェックサムの破損を確認します。根本的な要因のため、システム管理者とネット
ワークエンジニアに確認してください。NIC 上のチェックサムオフロードは、チェックサムエラーを生成することが
知られています。構成されている場合には、NIC チェックサムのオフロードの無効化をしてテストすることを検討
してください。LINUX では、ethtool -K <IF> rx off tx off でチェックサムのオフロードを無効化します。
通信パスの MTU サイズの不一致
説明: MTU サイズの不一致は "packet too big" の障害とパケットロスが発生し、global cache block loss と過剰な
パケット再送信要求が発生します。
アクション: MTU は、"Maximum Transmission Unit" または、インターコネクトインターフェース用に構成された最大伝送
ユニットまたはフレームサイズです。ほとんどの UNIX のデフォルトの標準は、イーサネットでは1500バイトです。
MTU の定義は、インターコネクト接続通信パス内の全てのデバイスで同一である必要があります。インターコネクト
通信パス内のすべてのデバイスを識別して監視します。ping, tracepath または traceroute には大きくデフォルト
ではないサイズの ICMP プローブパケットを使用して、パス内の MTU の不一致を検出します。サーバの NIC の MTU
サイズを決定して設定するには、ifconfig またはベンダー推奨ユーティリティを使用します。以下のジャンボフレーム
#12 を参照してください。
注: インターコネクトの MTU サイズが一致しない場合、10g と 11g ではノードのクラスタ参加が妨げられます。
専用ではないインターコネクト LAN
説明: インターコネクト LAN 上で共有パブリック IP トラフィックおよび/または共有 NAS IP トラフィックを共有すると、
アプリケーションのパフォーマンスの低下、ネットワークの混雑、および極端な場合には global cache block loss が
発生します。
アクション: インターコネクト/クラスタウェアのトラッフィックは、ルーティングされていないサブネットによって定義された専用
LAN 上にある必要があります。インターコネクトトラッフィックは、隣接するスイッチと分離されている必要があります。
例. インターコネクトトラフィックは、リンクが接続されているアクセスレイヤスイッチを超えて拡張してはなりません。
インターコネクトトラッフィックは、パブリックまたは NAS トラフィックと共有されてはなりません。仮想 LAN (VLANS)
を使用する場合は、パブリックまたは NAS トラフィックから隔離されたルーティングされていない専用のサブネットに
マップされた単一の専用 VLAN にインターコネクトを配置する必要があります。
サーバ/スイッチ隣接の不足
説明: ネットワークデバイスは、リンクレイヤを介して単一のホップで互いに到達できる場合、隣接すると言われています。
複数のホップがレイテンシを追加し、他のネットワークデバイスが通信パスに入っている場合、不要な複雑さとリスクを
招きます。
アクション: すべての GbE サーバインターコネクトリンクは、(スイッチが設定されている場合) スイッチまたはスイッチに直接接続
する (OSI) レイヤ2 である必要があります。インターコネクト通信パスには、ルータなどの仲介ネットワークデバイスは
存在しないはずです。unix コマンド 'traceroute'は、隣接関係の問題を特定するのに役立ちます。
IPFILTER の設定
説明: IPFILTER (IPF) は、ホストベースのファイアウォールまたは NAT (Network Address Translation) ソフトウェア
パッケージで、インターコネクトトラフィックの問題を引き起こすことが確認されています。IPF は、アプリケー
ションのパフォーマンスの大幅な低下、パケットロス、global cache block loss につながる可能性があります。
アクション: IPFILTER を無効にします。
古くなったネットワークドライバまたは NIC ファームウェア
説明: 古い NIC ドライバまたはファームウェアは、インターコネクト全体のパケット処理に問題を引き起こすことが知られて
います。ノード間通信における互換性のない NIC ドライバは、パケット処理レイテンシ、スキューされたレイテンシ
およびパケットロスを引き起こす可能性があります。
アクション: サーバの NIC は、すべてのノードで同じメイク/モデルで同一のパフォーマンス特性を持ち、スロット ID が
対称でなければなりません。クラスタ内のすべてのサーバのインターコネクト NIC でファームウェアと NIC ドライバは
同じ (最新の) rev. にする必要があります。
独自のインターコネクトリンク転送およびネットワークプロトコル
説明: LLT、HMP などの非標準の独自のプロトコルは、信頼性が低く、デバッグが困難であることが知られています。
ミス構成の独自のプロトコルにより、アプリケーションのパフォーマンスが低下し、パケットがドロップされ、
ノードの停止が引き起こされました。
アクション: Oracleは、トランスポートおよびプロトコルとして 1GbE UDP を標準化しています。これは、安定性、信頼性が
高く、実績があることが証明されています。独自のプロトコルと低水準のトランスポートは避けるべきです。
Infiniband 上の IP および RDS は、インターコネクトのネットワークの配置に対してサポートされており、
一部のプラットフォームでは 10GbE が動作保障されています (詳細は OTN を参照して下さい)。- この分野での
動作保障は継続中です。
正しく構成されていないボンディング/リンクアグリゲーション
説明: サーバ上の NIC リンクアグリゲーションまたはボンディングを正しく構成しなかったり、隣接するスイッチで
インターコネクト通信を行うためのアグリゲーションを設定できないと、パフォーマンスが低下し、ポート
フラッピングが発生し、スイッチのインターコネクトポートが集約されたリンクを頻繁に "UP"/"DOWN" 状態に
変更します。
アクション: クラスタ化されたサーバでリンクアグリゲーションを使用する場合は、スイッチ上のポートもインターコネクト
リンクのリンクアグリゲーションをサポートし、構成する必要があります。スイッチのインタコネクトポートの
アグリゲーションを正しく構成できないと、ポートフラッピングが発生し、スイッチポートがランダムにドロップ
し、パケットロスが発生します。ボンディング/アグリゲーションは、ドライバのドキュメントにより正しく構成
され、負荷をかけてテストする必要があります。リンク帯域幅とレイテンシのパフォーマンスをテストし測定する
のに役立つパブリックドメインユーティリティがいくつかあります (iperf を参照してください)。ボンディングの
効率を判断するために、OS、ネットワーク、およびネットワークドライバの統計を評価する必要があります。
正しく構成されていないジャンボフレーム
説明: 正しく構成されていないジャンボフレームは上述の MTU サイズのミスマッチを作り出すことがあります。
アクション: ジャンボフレームは IEEE 標準ではないため、設定時には注意が必要です。ジャンボフレームは約9000バイトの
フレームサイズです。フレームサイズは、ネットワークデバイスのベンダーによって異なる場合があり、通信する
デバイス間で一貫性がない場合があります。既定値が9000バイトでない場合、通信パス内のすべてのデバイスに
対して同じ最大伝送単位 (MTU) サイズを構成する必要があります。すべてのネットワークデバイス、スイッチ/
NIC/ラインカードは、同じフレームサイズ (MTU サイズ) をサポートするように設定する必要があります。
スイッチが MTU:1500 に設定されていてもサーバのインターコネクトインターフェイスが MTU:9000 に設定されて
いる場合、スイッチのパケットロス、パケットの断片化、再構成エラーが発生し、重大なパフォーマンスの低下や
クラスタノードの停止が発生する可能性があります。ほとんどのプラットフォームの netstat -s の IP 統計は、
フレームの断片化と再アセンブリのエラーを特定します。ほとんどのプラットフォームの ifconfig -a コマンドは
使用中のフレームサイズ (MTU:1500) を識別します。ジャンボフレームのサポートについては、スイッチのベンダの
マニュアルを参照してください。
NIC は全二重と二重モードの不一致を強制します。
説明: 二重モードの不一致は、通信チャネル内の2つのノードで片方は半二重で動作し、その他は全二重で動作している
場合です。これは、手動で誤って構成された二重モード、もしくは通信相手がオートネゴシエーション中に手動で
半二重に設定されているかもしれません。二重モードの不一致により、インターコネクト通信が著しく低下します。
アクション: 二重モードは、インターコネクトリンクを処理するスイッチ上のクラスタおよびラインカード内のすべてのサーバ
NIC に対してオートネゴシエーションに設定する必要があります。ギガビットイーサネット標準では、動作する
ためにオートネゴシエーションを「オン」に設定する必要があります。二重モードのミスマッチは、重大なネット
ワークの劣化、衝突、パケットの破棄を引き起こす可能性があります。オートネゴシエーションの二重モードは、
ハードウェア/ソフトウェアのアップグレードがネットワークインターフェイスに影響するたびに確認する必要が
あります。すべてのインターフェイスのオートネゴシエーションは、全二重で1000で動作します。
インターコネクト通信経路におけるフロー制御の不一致
説明: フロー制御とは、サーバがネットワークピア (またはパス内のネットワークデバイス) がそれを受け入れるよりも
速くデータを送信している状況です。受信デバイスは、送信者に送信を一時的に停止するよう要求する PAUSE
フレームを送信することがあります。
アクション: サーバ上のスイッチと NIC 間のフロー制御ミスマッチにより、パケットが失われ、インターコネクトネットワークの
パフォーマンスが著しく低下する可能性があります。ほとんどの場合、「ON」のデフォルト設定は最良の結果を
もたらします。例えば:

tx フロー制御を ON にする必要があります。
rx フロー制御を ON にする必要があります。
スイッチの tx/rx フロー制御を ON にする必要があります。

ただし、OSドライバやスイッチファームウェアのバグなど、特定のケース (<Note 400959.1> など) では、OFF
(すべてのネットワークパス上) を設定するとより良い結果が得られます。

注: フロー制御の定義は、ファームウェア/ネットワークドライバのアップグレード後に変更されることがあります。
NIC とスイッチの設定は、アップグレード後に確認する必要があります。ハードウェアベンダが他を提示する場合を
除き、デフォルト設定を使用してください。
OS、NIC またはスイッチレイヤでのパケット破棄
説明: OS、NIC、またはスイッチで報告されたパケット破棄は、徹底的に調査して解決する必要があります。パケットロスは
インターコネクトのパフォーマンスの低下、CPU オーバーヘッド、およびネットワーク/ノードの停止を引き起こす
可能性があります。
アクション: 特定のツールは、パケット/フレーム損失 (プロセス/OS/ネットワーク/NIC/スイッチ) が発生しているレイヤを特定する
のに役立ちます。netstat, ifconfig, ethtool, kstat (OS によって異なります)、およびスイッチポートの統計情報は、
最初の診断になります。エンドツーエンドのパケット通信をトレースして問題を特定するには、ネットワーク sniffer を
使用する必要があります (snoop/wireshare/ethereal などのパブリックドメインツールを参照してください)。根本的な
原因を特定するには、下位層のパケットロスを理解することが不可欠であることに注意してください。ネットワークインター
フェイス上のサイズリングバッファまたは受信待ち行列の下では、パケットロスが発生することが知られています。パケット
ロスはどのレイヤでも報告されません。下記の NIC ドライバの問題とカーネルキューの長さを参照してください。システム
管理者とネットワークエンジニアと共に、根本原因を突き止めてください。複数のプライベートインタコネクトと Linux
カーネル 2.6.32 以降を使用するシステムの場合は、<Note 1286796.1> を参照してください。
NIC ドライバ/ファームウェアの構成
説明: 調整可能な NIC のパブリックプロパティのデフォルト設定が正しくないか不十分であると、パケットが消失し、再送要求が
増加する可能性があります。
アクション: 出荷時のデフォルト設定は、大部分のネットワーク導入おいて十分なものです。しかし、いくつかのベンダーの NIC と
インターコネクトトラフィックの性質によって、割り込みの結合設定と、デバイスに関連付けられたリングバッファ内の
ディスクリプタの数を変更する必要があるという問題がありました。割り込み結合は、送信 (tx) および受信 (rx) パケット
処理の CPU 割り込みレートです。リングバッファは、CPU 割り込み間の処理のために rx パケットを保持します。
このレイヤの誤設定は、しばしばサイレントパケットロスを引き起こします。この層の診断では、システム管理者と
OS/ベンダーの介入が必要です。
NIC の送信 (tx) および受信 (rx) キューの長さ
説明: 不適切なサイズの NIC の tx/rx キューの長さは、キューがいっぱいになったときにパケットを破棄する可能性があります。
その結果、gc block loss やパケットの再送が増加し、インターコネクトのパフォーマンスが低下します。
アクション: パケットがカーネルネットワークサブシステムとネットワークインタフェースデバイスドライバとの間で移動すると、
パケットの転送と処理を管理するためにsend (tx) とreceive (rx) キューが実装されます。これらのキューのサイズは
構成可能です。これらのキューが構成されていないか、または生成されたネットワークトラフィックの量または MTU
サイズが構成されていない場合、完全なキューはオーバーフローとパケットロスを引き起こします。デバイスで収集
された統計情報とドライバの品質によっては、このパケットロスが検出されにくい場合があります。このレイヤの診断
では、システム管理者と OS/ベンダーの介入が必要です。(Linux の場合は if.extxtueue と netdev_max_backlog を
参照してください)
制限されたキャパシティと帯域幅の飽和
説明: オーバーサブスクライブされたネットワークの使用は、インターコネクトパフォーマンスの低下とパケットロスを招きます。
アクション: インターコネクトの配置のベストプラクティスは、インターコネクトの使用状況と帯域幅を把握することです。
これは定期的に監視して、使用傾向を一時的または定常的に特定する必要があります。インターコネクトに
対する要求が高まることは、アプリケーションの規模を拡大したり、不良な SQL や予期しないトラフィックの
歪みなどの異常な使用に起因する可能性があります。帯域幅飽和の原因を評価し、対処します。
オーバーサブスクライブされた CPU とスケジューリングの待ち時間
説明: 継続的な高負荷アベレージおよびネットワークスタックスケジューリングの待ち時間は、インターコネクトパケット処理に
悪影響を及ぼし、インターコネクトパフォーマンスの低下、パケットロス、gc block loss、および潜在的なノード停止の
原因となります。
アクション: システムのCPU使用率が高いときのスケジューリング遅延は、ネットワークパケット処理の遅延の原因となります。
過度の継続的な待ち時間は、パフォーマンスを著しく低下させ、クラスタノードの障害を引き起こす可能性があります。
継続的な高い CPU 使用率は調査することが重要です。uptime コマンドは、ほとんどのプラットフォームで負荷平均情報を
表示します。ネットワークスタック処理に関連する過度の CPU 割り込みは、NIC 割り込み結合および/または単一の CPU
へのネットワーク割り込みによって緩和される可能性があります。このタイプの最適化については、NIC ベンダと協力して
ください。レイテンシをスケジューリングすると、再アセンブリエラーが発生する可能性があります。上記の #2 を参照
してください。
スイッチ関連のパケット処理の問題
説明: スイッチのポート上でバッファがオーバーフローし、スイッチの混雑が発生し、MTU サイズ、アグリゲーション、Virtual
Land Definition (VLAN;仮想LAN定義) などのスイッチの設定ミスがパケット処理の効率を低下させ、パフォーマンスの低下や
クラスタノードの停止を招く可能性があります。
アクション: Oracle のインターコネクトは、スイッチドイーサネットネットワークが必要です。このスイッチは、インターコネクト
トラフィックのエンドツーエンドパケット通信における重要なコンポーネントです。ネットワークデバイスとして、スイッチは
インターコネクトのパフォーマンスと可用性に悪影響を与える可能性のある多くの要因または条件の影響を受ける可能性があります。
スイッチが異常なパケット処理イベント、一時的または持続的なトラフィック混雑および効率的なスループットを監視することが
重要です。スイッチ統計は、インターコネクトトラフィックの傾向を評価し、異常を特定するために定期的に評価する必要があります。
インターコネクトのパケット処理に悪影響を与える QoS
説明: インターコネクトトラフィックを共有するスイッチの Quality of Service 定義は、インターコネクト接続のネットワーク
処理に悪影響を及ぼし、深刻な性能の低下を招く可能性があります
アクション: インターコネクトが VLAN でセグメント化された共有スイッチに配置されている場合、サービスの優先順位付けが
インターコネクトパケット処理に悪影響を及ぼさないように、共有スイッチ上の QoS 定義を構成する必要があります。
配置と影響を評価する前に、すべての QoS 定義は評価する必要があります。
切換え中の一時的停止の測定
説明: イーサネットネットワークは、スパニングツリープロトコル (STP) を使用して、ホストへの冗長ルートが存在する
ループフリートポロジを保証します。STP トポロジに参加しているネットワークデバイスの停止は、ルートをホストに
再計算するトポロジの切替えの影響を受けます。STP が LAN で有効になっていて、誤って設定または最適化されていない
場合、ネットワーク切換えイベントは、再計算するまでに 1 分以上かかる場合があります (ネットワークおよび参加
デバイスのサイズによって異なります)。このような待ち時間は、インターコネクトの障害やクラスタ全体の停止を招く
可能性があります。
アクション: 多くのスイッチベンダーは STP に最適化された拡張機能を提供して、ネットワーク切換え時間を短縮します。
クラスタ全体の停止を避けるために、RSTP (Rapid Spanning Tree)、PVST (Per-VLAN Spanning Tree)、MSTP
(Multi-Spanning Tree) などの最適化を導入する必要があります。
STREAMS キューイングで sq_max_size が不十分
説明: AWR は、"gc cr block lost" および/または "gc current block lost" の待機をレポートします。
netstat の出力は、パケット処理エラーを表示しません。kstat -p -s '* nocanput * はゼロ以外の値を返します。
nocanput はストリーミングメッセージのキューがいっぱいで、パケットが破棄されることを示します。
お客様は、Solaris 環境の RAC で STREAMS を実行しています。
アクション: udp の最大バッファースペースを増やし、無制限の STREAMS キューイングを定義すると、問題が
緩和され、nocanputのロストメッセージが排除されます。これらの変更を行う Solaris コマンドは次の通りです:

`ndd -set /dev/udp udp_max_buf <NUMERIC VALUE>`
/etc/system 内に sq_max_size を 0 (無制限) に設定してください。デフォルトは 2 です。

udp_max_buf は、UDP ソケットの送信バッファと受信バッファ (バイト単位) の大きさを制御します。
デフォルト設定の 262,144 バイトは、STREAMS アプリケーションでは不十分です。 sq_max_size は、
メッセージキューの深さです。
AIX プラットフォームのみ。VIPA および DGD の設定が正しくない

AIX プラットフォームで cluster_interconnect に仮想 IP アドレス (VIPA) を使用する場合は、
UDP フェイルオーバーを可能にするために Dead Gateway Detection (DGD) を構成する必要があります。
デフォルトの 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-01.ibm.com/support/docview.wss?uid=tss1wp102177
Solaris + Veritas LLT 環境における誤ったスイッチの構成

VCS コマンド lltstat より確認される "Snd retransmit data" が増加する時は、gc block lost の
回数も増加します。
インターコネクトスイッチの速度を固定からオートネゴシエートに変更し、インターコネクトスイッチで
ケーブルを各モジュールに均等に分配することが、"gc blocks lost"を防止するのに役立ちます。
12.1.0.2 の場合、<Bug 20922010> FALSE 'GC BLOCKS LOST' REPORTED ON 12.1 AFTER UPGRADING FROM 11.2.0.3

これは 12.1.0.2.161018 及び 12.2.0.1 で修正されました。詳細は次のドキュメントを参照してください。
<Note 20922010.8> Bug 20922010 - False 'gc blocks lost' reported on 12.1 after upgrading from 11.2
<Note 2096299.1> False increase of 'Global Cache Blocks Lost' or 'gc blocks lost' after upgrade to 12c