この項では、読込みおよび変更頻度の高いオブジェクトおよびリモート・アクセスにより発生するサービス時間を識別して、GCSのパフォーマンスを監視する方法を説明します。ディスク・アクセス待機時間よりもキャッシュ・フュージョンによる転送時間の方が通常は短いという事実はあるものの、ディスクからの読取りによってブロック・アクセス遅延が増加する場合と同様に、ブロックの到着待ちが応答時間のほとんどを占める場合があります。
次の待機イベントは、ブロックの待機、確保またはログ・フラッシュなしでリモート・キャッシュ・ブロックがローカル・インスタンスへ送信されたことを示します。
gc current block 2-way
gc current block 3-way
gc cr block 2-way
gc cr block 3-way
gc current blocks received
およびgc cr blocks received
についてのオブジェクト統計により、アクティブ・インスタンスで共有される索引および表が簡単に特定できます。前述のとおり、通常は、ADDMによる分析を行うと、インスタンス間の競合によって影響を受けるSQL文およびデータベース・オブジェクトが特定されます。
前述のイベントの平均待機時間を増加させる原因は、次のとおりです。
高負荷: CPUの容量不足、長い実行キュー、スケジュールの遅延
設定の問題: メッセージおよびブロック通信量にプライベート・インターコネクトではなくパブリック・インターコネクトを使用している
平均待機時間は適切で、インターコネクトまたは負荷には問題がないと診断された場合は、SQL文が累計待機時間の原因になっている可能性があります。アクセスするブロック数を最小にするために、SQL文をチューニングする必要があります。
V$SQLAREA
のCLUSTER_WAIT_TIME
列は、グローバル・キャッシュ・イベントの個々のSQL文によって発生する待機時間を表し、チューニングを必要とするSQLを特定します。