14 パフォーマンスの監視
この章では、Oracle Real Application Clusters(Oracle RAC)のパフォーマンスを監視およびチューニングする方法について説明します。
この章の内容は次のとおりです。
14.1 Oracle RACデータベースの監視およびチューニングの概要
この項には次のトピックが含まれます:
14.1.1 Oracle RACおよびOracle Clusterwareの監視
Oracle RACおよびOracle Clusterwareの監視には、Oracle Enterprise Managerを使用することをお薦めします。Oracle Enterprise Managerは、コンピューティング環境を監視および管理するためのOracleのWebベースの統合管理ソリューションです。Webブラウザを使用できる場所であれば、どこからでも、OracleのRACデータベース、アプリケーション・サーバー、ホスト・コンピュータおよびWebアプリケーションと、それらに関連するハードウェアやソフトウェアを管理できます。たとえば、Webブラウザが使用可能な場合、オフィス、自宅またはリモート環境からOracle RACデータベースのパフォーマンスを監視できます。
Oracle Enterprise Manager Cloud Controlはクラスタ対応で、クラスタ・データベースを管理するセントラル・コンソールを用意しています。クラスタ・データベースの「ホーム」ページから、次のすべての操作を実行できます。
-
クラスタ内にあるノードの数や現在のステータスなど、全体的なシステム・ステータスの表示。この高レベルの表示機能を利用することで、包括的で集計的な情報のみを確認する場合に、個々のデータベース・インスタンスにアクセスして詳細を確認する必要がなくなります。
-
すべてのインスタンスから集計されたアラート・メッセージと各アラート・メッセージのソースのリストの表示。アラート・メッセージとは、特定のメトリックの条件に一致したことを表すインジケータです。メトリックとは、システムの状態の報告に使用される測定の単位です。
-
クラスタ全体に影響している問題および個々のインスタンスに影響している問題を確認します。
-
クラスタ・キャッシュ一貫性の統計を監視して、処理の傾向の識別やOracle RAC環境のパフォーマンスの最適化に役立てます。キャッシュ一貫性の統計によって、複数のインスタンスのキャッシュ内にあるデータがどの程度適切に同期化されているかが測定されます。データ・キャッシュが相互に完全に同期化されている場合、どのインスタンスのキャッシュからメモリーの場所を読み取っても、その場所に対して任意のインスタンスのキャッシュから書き込まれた最新のデータが戻されます。
Oracle Enterprise Managerは、特定期間のデータ(収集ベース・データという)を累積します。また、Oracle Enterprise Managerは、現在のデータ(リアルタイム・データ)も提供します。
『Oracle Database 2日でReal Application Clustersガイド』では、Oracle Enterprise Managerを使用したパフォーマンスの監視について詳細に説明しています。
-
Automatic Database Diagnostic MonitorおよびOracle RACのパフォーマンス
14.1.1.1 クラスタ・データベースの「ホーム」ページ
クライアント・ブラウザでOracle Enterprise Managerを使用して、Oracle ClusterwareおよびOracle RACの両方の環境を監視できます。監視には次のタスクが含まれます。
-
VIPの再配置が行われた場合の通知
-
クラスタ検証ユーティリティ(
cluvfy
)により取得した情報を使用する、クラスタの各ノードのOracle Clusterwareのステータス -
ノード・アプリケーション(
nodeapps
)が起動または停止した場合の通知 -
Oracle ClusterwareのOCR用アラート・ログに記録された問題、投票ディスクの問題(ある場合)およびノード削除の通知
クラスタ・データベースの「ホーム」ページは、非クラスタ・データベースの「ホーム」ページと似ています。ただし、クラスタ・データベースの「ホーム」ページには、Oracle Enterprise Managerにより、システムの状態と可用性が表示されます。これには、アラート・メッセージおよびジョブ・アクティビティのサマリーと、すべてのデータベースおよびOracle Automatic Storage Management (Oracle ASM)インスタンスへのリンクも含まれます。たとえば、すべての優先インスタンスでサービスが実行されていない場合、またはサービスの応答時間のしきい値条件が満たされていない場合などに、クラスタでのサービスに関する問題を追跡できます。
14.1.1.2 「インターコネクト」ページ
Oracle Enterprise Managerの「インターコネクト」ページを使用して、Oracle Clusterware環境を監視できます。「インターコネクト」ページには、次のような、クラスタのパブリック・インタフェースおよびプライベート・インタフェースや、インターコネクトのデータベース・インスタンスによるロードが表示されます。
-
プライベート・インターコネクトでの全体的なスループット
-
構成ミスのためデータベース・インスタンスがパブリック・インタフェースを使用している場合の通知
-
インターコネクトのスループットおよびエラー(発生した場合)
-
インスタンスごとのインターコネクトのスループット
これらの情報はすべて、履歴表示を含む収集としても使用することができ、このことは、クラスタの待機イベント関連の問題を診断する場合などに、クラスタ・キャッシュ一貫性と併用すると有効です。クラスタ・データベースの「ホーム」ページで「InterConnect」タブをクリックするか、またはOracle RACデータベースの「ホーム」ページで診断結果の「インターコネクト・アラート」リンクをクリックすると、「インターコネクト」ページにアクセスできます。
14.1.1.3 「クラスタ・データベース」の「パフォーマンス」ページ
Oracle Enterprise Managerクラスタ・データベースの「パフォーマンス」ページには、データベースのパフォーマンス統計のサマリーが表示されます。
統計は、グラフにあるクラスタ・データベース内のすべてのインスタンス間でロールアップされます。グラフの横のリンクを使用すると、より詳細な情報を取得したり、次のタスクを実行することができます。
-
パフォーマンスの問題の原因の特定。
-
リソースを追加または再分散する必要があるかどうかの判別。
-
SQL計画およびスキーマのチューニングによる最適化。
-
パフォーマンスの問題の解決
クラスタ・データベースの「パフォーマンス」ページには、次のグラフが含まれます。
-
「クラスタ・ホストのロード平均」グラフ: クラスタ・データベースの「パフォーマンス」ページの「クラスタ・ホストのロード平均」グラフには、データベース外部で発生する可能性がある問題が表示されます。このグラフには、クラスタ内で使用可能なノードについて、過去1時間のロードの最大値、平均値および最小値が表示されます。
-
「グローバル・キャッシュ・ブロックのアクセス待機時間」グラフ: 各クラスタ・データベース・インスタンスのシステム・グローバル領域(SGA)には、独自のバッファ・キャッシュが存在します。キャッシュ・フュージョンの使用によって、Oracle RAC環境で各インスタンスのバッファ・キャッシュが論理的に結合され、論理的に結合された単一のキャッシュにデータが存在する場合と同様に、データベース・インスタンスでデータを処理できます。
-
「平均アクティブ・セッション」グラフ: クラスタ・データベースの「パフォーマンス」ページの「平均アクティブ・セッション」グラフには、データベース内で発生する可能性がある問題が表示されます。「カテゴリ」は待機クラスとも呼ばれ、データベース内でCPUやディスクI/Oなどのリソースを使用している部分が表示されます。CPU時間を待機時間と比較すると、レスポンス時間のうちどれくらいの時間が、他のプロセスに保持されている可能性のあるリソースの待機ではなく有効な作業に消費されているかを確認できます。
-
「データベース・スループット」グラフ: 「データベース・スループット」グラフは、「平均アクティブ・セッション」グラフに表示される任意のリソース競合を要約する他、ユーザーやアプリケーションのためにデータベースが実行中の作業の量を示します。「1秒当たり」ビューは、1秒当たりのログオン数に対するトランザクションの数、REDOサイズに対する物理読取りの量を示します。「1トランザクション当たり」ビューは、トランザクション当たりのREDOサイズに対する物理読取りの量を示します。「ログオン」は、データベースにログオンしているユーザー数を示します。
さらに、クラスタ・データベースの「パフォーマンス」ページにある「トップ・アクティビティ」ドリルダウン・メニューでは、待機イベント、サービスおよびインスタンス単位でアクティビティを表示できます。また、グラフのスライダを使用して以前の時点に移動することによって、SQL/セッションの詳細を表示できます。
クラスタ・データベースの「パフォーマンス」ページには、Oracle RACデータベースのパフォーマンス統計のサマリーが表示されます。ユーザーがすべてのインスタンスを調べなくてもパフォーマンスの問題を特定できるように、統計はクラスタ・データベース内のすべてのインスタンス間でロールアップされます。サービスに関連したパフォーマンスの問題の優先順位を決定しやすくするために、Oracle Enterprise Managerでは次のレベルでアクティビティ・データを集計します。
-
待機単位の集計
すべてのアクティビティ・データが12のカテゴリ(CPU、スケジューラ、ユーザーI/O、システムI/O、同時実行性、アプリケーション、コミット、構成、管理、ネットワーク、クラスタおよびその他)で表示されます。表示されたデータは、実行中のすべてのインスタンスからロールアップされます。
-
サービス単位の集計
すべてのアクティビティ・データが、サービスごとにロールアップされます。この方法でアクティビティ・データを表示すると、最もアクティブなサービスおよび詳細な分析が必要なサービスを簡単に特定できます。
-
インスタンス単位の集計
同様の結果として、サービスが対象のサービスでない場合、アクティビティ・データはインスタンスごとにロールアップされます。
集計はアクティビティ・データが表示されているページ(「データベース・パフォーマンス」ページ、「トップ・アクティビティ」ページ、「待機の詳細」ページ、「サービスの詳細」ページなど)に表示されます。
14.2 Oracle RACのインターコネクト設定の検証
SQL文を使用して、Oracle RACのインターコネクト設定を検証します。
インターコネクトとノード間通信のプロトコルは、キャッシュ・フュージョンのパフォーマンスに影響を与える場合があります。さらに、インターコネクトの帯域幅、その待機時間およびIPCプロトコルの効率によって、キャッシュ・フュージョンがブロック転送を処理する速度が決まります。
接続したOracle RACデータベース・インスタンスのインターコネクト設定を検証するには、V$CLUSTER_INTERCONNECTS
およびV$CONFIGURED_INTERCONNECTS
ビューを問い合せます。次に例を示します。
例14-1 V$CLUSTER_INTERCONNECTSを使用したインターコネクト設定の検証
SQL> SELECT * FROM V$CLUSTER_INTERCONNECTS;
NAME IP_ADDRESS IS_PUBLIC SOURCE
--------------- -------------- --- -------------------------------
eth2 10.137.20.181 NO Oracle Cluster Repository
注意:
GV$CLUSTER_INTERCONNECTS
ビューを問い合せて、クラスタ内のすべてのインスタンスのエントリを表示できます。
例14-2 V$CONFIGURED_INTERCONNECTSを使用したインターコネクト設定の検証
SQL> SELECT * FROM V$CONFIGURED_INTERCONNECTS;
NAME IP_ADDRESS IS_PUBLIC SOURCE
--------------- --------------- --- -------------------------------
eth2 10.137.20.181 NO Oracle Cluster Repository
eth0 10.137.8.225 YES Oracle Cluster Repository
14.3 インターコネクト処理への影響
一度インターコネクトが動作可能になると、インターコネクトのパフォーマンスを大きく変更することはできません。ただし、プロセス間通信(IPC) のバッファ・サイズを調整することで、インターコネクト・プロトコルの効率を変更できます。
Oracle Cluster Registry(OCR)には、システムのインターコネクト情報が格納されます。Oracle Interface Configuration(OIFCFG)コマンドライン・ユーティリティoifcfg getif
コマンドまたはOCRDUMPユーティリティを使用して、使用しているインターコネクトを特定します。その後、OIFCFGコマンドを実行して、使用しているインターコネクトを変更できます。
CLUSTER_INTERCONNECTSパラメータを設定する必要はほとんどありません
が、次の例に示すように、このパラメータを使用して、プライベート・ネットワークIPアドレスまたはNICを割り当てることができます。
CLUSTER_INTERCONNECTS=10.0.0.1
オペレーティング・システム固有のベンダーIPCプロトコルを使用している場合は、トレース情報からIPアドレスが判明しない場合があります。
注意:
-
OIFCFGコマンドを使用しても、プライベート・ネットワークまたはプライベートIPアドレスを割り当てることができます。
-
クラスタにOracle Clusterware 12cリリース2 (12.2)以上がインストールされている場合は、IPv4またはIPv6アドレスを複数のプライベート・ネットワークに割り当てることができます。いずれかのプロトコルを選択し、クラスタ内のすべてのプライベート・ネットワークでそのプロトコルを使用する必要があります。
14.4 Oracle RACのパフォーマンス・ビュー
各インスタンスには、V$
という接頭辞が付く、それぞれ一連のインスタンス固有のビューがあります。
グローバル動的パフォーマンス・ビューに問い合せて、すべてのインスタンスからパフォーマンス情報を取り出すことができます。グローバル動的パフォーマンス・ビュー名には、GV$
という接頭辞が付きます。
GV$
ビューを問い合せると、すべてのインスタンスからV$
ビュー情報が取り出されます。V$
情報に加えて、各GV$
ビューには、NUMBER
データ型のINST_ID
という追加の列が含まれています。INST_ID
列には、関連するV$
ビュー情報の取得元のインスタンス番号が表示されます。
フィルタとしてINST_ID
列を使用すると、使用可能なインスタンスのサブセットからV$
情報を取り出せます。たとえば、次の問合せでは、インスタンス2および5のV$LOCK
ビューから情報を取り出します。
SQL> SELECT * FROM GV$LOCK WHERE INST_ID = 2 OR INST_ID = 5;
14.5 CATCLUST.SQLによるOracle RACのデータ・ディクショナリ・ビューの作成
Oracle RACデータベースの作成にDatabase Configuration Assistant(DBCA)を使用しなかった場合は、CATCLUST.SQL
スクリプトを実行してOracle RAC関連のビューと表を作成する必要があります。このスクリプトの実行には、SYSDBA
権限が必要です。
14.7 Oracle RAC環境における自動ワークロード・リポジトリ
自動ワークロード・リポジトリを使用して、Oracle RACデータベースに関連するパフォーマンスの統計を監視できます。
自動ワークロード・リポジトリ(AWR)では、パフォーマンス・データのスナップショットを1時間ごとに自動生成し、統計をワークロード・リポジトリに収集します。Oracle RAC環境では、AWRの各スナップショットが、クラスタ内のすべてのアクティブなインスタンスからのデータを取得します。取得される各スナップショット・セットのデータは、同じ時点のものです。AWRでは、すべてのインスタンスのスナップショット・データが同じ表に格納され、データはインスタンス修飾子で識別されます。たとえば、BUFFER_BUSY_WAIT
統計では、各インスタンスのバッファ待機の数が示されます。AWRでは、クラスタ全体から集計されるデータは格納されません。つまり、データは各インスタンスごとに個別に格納されます。
自動データベース診断モニター(ADDM)を使用すると、Oracle Databaseについて考えられるパフォーマンス上の問題がないか、AWRで収集された情報を分析できます。ADDMでは、クラスタ全体の観点からパフォーマンス・データを表示するため、全体的なパフォーマンス分析が可能です。Oracle RAC環境では、ADDMは、すべてのインスタンスから収集されたデータを使用してパフォーマンスを分析し、次のような様々なレベルの粒度で表示できます。
-
クラスタ全体の分析
-
特定のデータベース・インスタンスの分析
-
データベース・インスタンスのサブセットの分析
これらの分析を行うには、ADDMアドバイザをOracle RACのADDMのモードで実行してクラスタ全体の分析を行うか、ローカルADDMのモードで個々のインスタンスのパフォーマンスを分析するか、または部分ADDMモードでインスタンスのサブセットを分析します。Oracle Enterprise Managerのアドバイザ・セントラルまたはDBMS_ADVISOR
パッケージおよびDBMS_ADDM
PL/SQLパッケージを介したアドバイザ・フレームワークを使用して、ADDM分析をアクティブ化します。
14.8 Oracle RACのアクティブ・セッション履歴レポート
この項では、Oracle RACのアクティブ・セッション履歴(ASH)レポートについて説明します。内容は次のとおりです。
14.8.1 Oracle RACのASHレポートの概要
ASHはOracle Databaseの自己管理フレームワークにとって不可欠な部分であり、Oracle RAC環境のパフォーマンスの問題の診断に役立ちます。ASHレポート統計は、Oracle Databaseのセッション・アクティビティに関する詳細を示します。Oracle Databaseでは、Oracle RACのすべてのアクティブ・インスタンスのアクティブ・セッションに関する情報を記録して、このデータをシステム・グローバル領域(SGA)に格納します。データベースに接続してCPUを使用しているすべてのセッションが、アクティブ・セッションとみなされます。ただし、アイドル状態の待機クラスに属するイベントを待機しているセッションは例外です。
ASHレポートは、アクティブ・セッションの情報のみを取り込むことによって、管理可能なデータのセットを表示します。データの量は、システムで許可されているセッションの数ではなく、実行されている作業に直接関連します。
指定した期間中に収集されたASH統計をASHレポートに含めることができます。各ASHレポートは、ADDM分析には表示されない短時間のパフォーマンスの問題を特定できるように、複数のセクションに分割されています。Oracle RAC固有の2つのASHレポート・セクションは、次の2つの項で説明するとおり、トップ・クラスタ・イベントとトップ・リモート・インスタンスです。
14.9 Oracle RACの統計および待機イベントの監視
この項では、Oracle RAC固有の待機イベントおよび統計を説明し、自動ワークロード・リポジトリ(AWR)、Statspackまたは動的パフォーマンス・ビューの非定型問合せによって生成されたパフォーマンス・データを評価する場合の、待機イベントおよび統計の解析方法も説明します。
この項には次のトピックが含まれます:
14.9.1 AWRおよびStatspackレポートでのOracle RAC統計およびイベント
14.9.2 Oracle RACの待機イベント
待機状態のセッションの分析および解析は、時間がかかっている場所を判別するための重要な手段です。
Oracle RACの場合、要求の結果を正確に反映するイベントにより待機時間が発生します。たとえば、インスタンスのセッションがグローバル・キャッシュ内のブロックを検索している場合、このセッションは、別のインスタンスがキャッシュしたデータを受け取るかどうか、ディスクから読み込むためのメッセージを受け取るかどうかは判別できません。グローバル・キャッシュに関する待機イベントは正確な情報を伝達し、グローバル・キャッシュのブロックまたはメッセージを待機中のイベントは次の状態になります。
-
クラスタ待機クラスと呼ばれる広範囲のカテゴリに集約されます。
-
ブロック待機中にアクティブになるプレースホルダ・イベントによって一時的に表されます。次に例を示します。
-
gc current block request
-
gc cr block request
-
-
要求の結果がわかっている場合は、正確なイベントを提供します。次に例を示します。
-
gc current block 3-way
-
gc current block busy
-
gc cr block grant 2-way
-
つまり、Oracle RACの待機イベントは、パフォーマンス分析にとって重要な情報を伝達します。これらのイベントは、キャッシュ・フュージョンの影響を正確に診断するために、Automatic Database Diagnostic Monitor(ADDM)で使用されます。
14.9.3 GCS統計とGES統計の分析によるパフォーマンス監視
インスタンス間のメッセージ交換および競合に関連する作業量およびコストを判断するには、次の項の説明に従って、ブロック転送率、各トランザクションで発生したリモート要求、グローバル・キャッシュ・イベントの待機数および待機時間を調べます。
14.9.3.1 キャッシュ・フュージョンがOracle RACに与える影響の分析
グローバル・キャッシュ内のブロックへのアクセス、および一貫性を保持した場合の効果は、次の情報で示されます。
-
gc current blocks received
、gc cr blocks received
などのcurrent
およびcr
ブロックのグローバル・キャッシュ・サービス(GCS)統計 -
gc current block 3-way
、gc cr grant 2-way
などのGCS待機イベント
キャッシュ・フュージョンによる転送の応答期間は、物理的なインターコネクト・コンポーネント、IPCプロトコルおよびGCSプロトコルの制限が適用されるメッセージングおよび処理時間によって決まります。不定期に発生するログ書込み以外のディスクI/O要因による影響は受けません。キャッシュ・フュージョン・プロトコルの場合、キャッシュ一貫性 を保証するためのデータファイルへのI/Oを行う必要はなく、基本的にOracle RACでは、非クラスタ・インスタンスよりも多くのディスクI/Oは発生しません。
14.9.3.2 GCS統計とGES統計を使用したパフォーマンス分析
すべてのインスタンスによる使用頻度の高い(hot)データ・ブロックとオブジェクトを識別して、GCSのパフォーマンスを監視できます。
並行処理回数の多いブロックは、GCSの待機イベントおよび待機数によって特定できます。
gc current block busy
の待機イベントは、リモート・キャッシュまたはローカル・キャッシュがビジーなため、キャッシュ・データ・ブロックへのアクセスが遅延状態であることを示します。この原因として、次のいずれかが考えられます。
-
ブロックが確保されている
-
ブロックがセッションによって保留されている
-
ブロックがリモート・インスタンス側のログ書込みにより遅延されている
-
同一インスタンス上のセッションが、インスタンス間を移動中のブロックにアクセスしているため、現行のセッションが待機状態(
gc current block busy
など)になっている
V$SESSION_WAIT
ビューを使用して、競合するオブジェクトおよびデータ・ブロックを識別します。GCS待機イベントには、p1およびp2のブロック・リクエストのファイルおよびブロック番号がそれぞれ含まれています。
前述のV$SESSION_WAIT
への問合せなしで、ビジー・オブジェクトを迅速に判別するために、セグメント統計gc buffer busy
が追加されています。
AWRインフラストラクチャは、最近の待機イベントおよびその引数のトレースにも使用できるアクティブ・セッション履歴のビューを提供します。そのため、ホット・ブロック分析に有効です。AWRおよびStatspackで使用されるほとんどのレポート機能に、オブジェクト統計およびクラスタ待機クラスのカテゴリが含まれるため、前述のビューのサンプリングが必要になることはほとんどありません。
注意:
ADDMおよびAWRを使用することをお薦めします。ただし、Statspackには下位互換性があります。Statspackには、レポート機能のみが用意されています。ブロック競合およびセグメント・ブロックの待機に関連する統計を収集するには、Statspackをレベル7で実行する必要があります。
AWRインフラストラクチャで収集されたスナップショット・データに対してADDMを実行し、グローバル・キャッシュが与える影響の全体的な評価を取得することをお薦めします。この評価では、ビジー・オブジェクトおよびSQLでの待機時間が最も長いクラスタも特定されます。
14.9.4 GCS統計を使用したキャッシュ・フュージョンによる転送の影響の分析
読込み頻度と変更頻度の高いオブジェクトおよびリモート・アクセスにより発生するサービス時間を識別して、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を特定します。
14.9.5 待機イベントに基づく応答時間の分析
AWRおよびStatspackレポートまたは動的パフォーマンス・ビューで高い合計時間が示されるほとんどのグローバル・キャッシュ待機イベントは正常で、実際に問題があるのではなく、データベース時間の上位の使用者として表示されることがあります。
この項では、パフォーマンス・データを解析する際に注意が必要な、発生頻度の高い待機イベントについて説明します。
ユーザーの応答時間が長くなり、グローバル・キャッシュでの待機時間の比率が高い場合は、その原因を特定する必要があります。ほとんどのレポートには、合計時間に対する待機時間の割合の順で待機イベントが表示されます。
最初に、定期的に収集されるパフォーマンス統計の影響と、待機時間のほとんどを占めるオブジェクトおよびSQLを特定するADDMレポートを分析します。その後、AWRおよびStatspackにより生成される詳細なレポートを分析することをお薦めします。
Oracle RACの待機イベントは、次のカテゴリに分類されます。
14.9.5.2 メッセージ関連の待機イベント
-
gc current grant 2-way
-
gc cr grant 2-way
メッセージ関連待機イベント統計は、インスタンスにブロックがキャッシュされなかったために、ブロックが受信されなかったことを示します。かわりに、要求側インスタンスがディスクからのブロックを読み取ったり、ブロックを変更できるグローバルな権限が付与されます。
これらのイベントの処理時間が長い場合は、使用頻度の高いSQLによるディスクI/O回数の増加(cr grant
の場合)、またはワークロードによって大量のデータが挿入されたため、頻繁に新しいブロックを検索しフォーマットする必要があると(current grantの場合)考えられます。
14.9.5.3 競合関連の待機イベント
-
gc current block busy
-
gc cr block busy
-
gc buffer busy acquire/release
競合関連の待機イベント統計は、別のノードのセッションによって確保されたブロックが受信されたものの、ディスクへの変更のフラッシュが完了していないため、または並行性が高いために保留され、すぐに送信できない状態になっていることを示します。セッションがキャッシュ・フュージョン操作をすでに開始している場合は、バッファは、ローカルでもビジーになる可能性があり、同一ノード上の別のセッションが、同一データの読取りまたは変更を行う場合、バッファはそれが完了するまで待機します。グローバル・キャッシュ内でやり取りされるブロックのサービス時間が長くなると、競合状態が悪化する可能性がありますが、これは、同一データに対して頻繁に行われる同時読取りおよび書込みアクセスが原因の可能性もあります。
gc current block busy
およびgc cr block busy
の待機イベントは、要求を作成しているローカル・インスタンスが、カレント・ブロックまたはCRブロックをすぐに受信しなかったことを示します。これらのイベント名にあるbusyという用語は、リモート・インスタンスでブロックの送信が遅延状態であったことを示します。たとえば、ブロックの変更のREDOがOracle Databaseによってまだログ・ファイルに書き込まれていない場合は、ブロックをすぐに送信することはできません。
block busy
待機イベントと比較した場合、gc buffer busy
イベントには、Oracle Databaseではローカル・バッファ・キャッシュに格納されているデータへのアクセス権をすぐに付与できないことが示されています。これは、バッファに対するグローバル操作が保留中で、操作がまだ完了していないためです。つまり、バッファはビジー状態であり、ローカル・バッファにアクセスしようとしている他のすべてのプロセスで完了を待機する必要があります。
また、gc buffer busy
イベントの存在は、ブロック競合が存在し、結果としてローカル・ブロックに対する複数のアクセス要求が発生していることも意味します。Oracle Databaseはこれらの要求をキューに入れる必要があります。Oracle Databaseによるキューの処理に必要な時間の長さは、ブロックの残りのサービス時間に依存します。サービス時間は、ネットワーク待機時間によって加算される処理時間、リモートおよびローカル・インスタンスの処理時間および待機キューの長さによって影響を受けます。
これらの待機による影響が大きく、パフォーマンスに問題が発生するというアラートを受けた場合は、平均待機時間および合計待機時間を検討する必要があります。通常は、インターコネクトかロードの問題、または大きい共有作業セットに対して実行されるSQLが根本的な原因と考えられます。