| Oracle® Real Application Clusters管理およびデプロイメント・ガイド 11g リリース2 (11.2) B56290-06 |
|
 前 |
 次 |
この章では、Oracle Real Application Clusters(Oracle RAC)のパフォーマンスを監視およびチューニングする方法について説明します。
内容は次のとおりです。
この項の内容は次のとおりです。
|
関連項目:
|
Oracle RACおよびOracle Clusterwareの監視には、Oracle Enterprise Managerを使用することをお薦めします。Oracle Enterprise Managerは、コンピューティング環境を監視および管理するためのOracleのWebベースの統合管理ソリューションです。Webブラウザを使用できる場所であれば、どこからでも、OracleのRACデータベース、アプリケーション・サーバー、ホスト・コンピュータおよびWebアプリケーションと、それらに関連するハードウェアやソフトウェアを管理できます。たとえば、Webブラウザが使用可能であれば、オフィス、自宅またはリモート環境からOracle RACデータベースのパフォーマンスを管理できます。
Oracle Enterprise Manager Database ControlとOracle Enterprise Manager Grid Controlはいずれも、クラスタを認識し、クラスタ・データベースを集中管理するためのコンソールを提供します。クラスタ・データベースの「ホーム」ページから、次のすべての操作を実行できます。
システム全体のステータス(クラスタ内のノードの数、各ノードの現在のステータスなど)の表示。この高度なビュー機能を使用すると、包括的な集計情報のみを確認する場合に、各データベース・インスタンスの詳細情報にアクセスする必要がなくなります。
いずれかのインスタンスで発生したすべてのアラート・メッセージの表示および各アラート・メッセージの原因のリスト。アラート・メッセージは、特定のメトリック条件が発生したことを示します。メトリックは、システムの状態をレポートするために使用される測定単位です。
クラスタ全体および個々のインスタンスに影響している問題の確認。
処理傾向を識別し、Oracle RAC環境のパフォーマンスを最適化するために役立つ、クラスタ・キャッシュ一貫性の統計の監視。キャッシュ一貫性の統計では、複数のインスタンスのキャッシュ内データがどの程度同期化されているかが測定されます。データ・キャッシュが相互に完全に同期化されている場合、どのインスタンスのキャッシュからメモリーの場所を読み取っても、その場所に対して任意のインスタンスのキャッシュから書き込まれた最新のデータが戻されます。
Oracle Enterprise Managerは、特定期間のデータ(収集ベース・データという)を累積します。また、Oracle Enterprise Managerは、現在のデータ(リアルタイム・データ)も提供します。
『Oracle Database 2日でReal Application Clustersガイド』では、Oracle Enterprise Managerを使用したパフォーマンスの監視について詳細に説明しています。
Automatic Database Diagnostic MonitorおよびOracle RACのパフォーマンス
クライアントのブラウザを使用してOracle Enterprise Managerにログインすると、クラスタ・データベースの「ホーム」ページが表示され、ここで、Oracle ClusterwareおよびOracle RAC環境の両方のステータスを監視できます。監視には次の内容が含まれます。
VIPの再配置が発生した場合の通知
クラスタ検証ユーティリティ(cluvfy)で取得した情報を使用している各クラスタ・ノードのOracle Clusterwareのステータス
ノード・アプリケーション(nodeapps)が起動または停止した場合の通知
Oracle ClusterwareのOCR用アラート・ログに記録された問題、投票ディスクの問題(ある場合)およびノード削除の通知
クラスタ・データベースの「ホーム」ページは、非クラスタ・データベースの「ホーム」ページと似ています。ただし、クラスタ・データベースの「ホーム」ページには、Oracle Enterprise Managerによって、システムの状態と可用性が表示されます。これには、アラート・メッセージおよびジョブ・アクティビティのサマリーと、全データベースに対するリンクおよびOracle Automatic Storage Management(Oracle ASM)のインスタンスが含まれています。たとえば、サービスがどの優先インスタンスでも実行されていない、サービス応答時間のしきい値が満たされていないなど、クラスタのサービスで発生する問題を追跡できます。
Oracle Enterprise Managerの「インターコネクト」ページを使用して、Oracle Clusterware環境を監視できます。「インターコネクト」ページには、次のような、クラスタのパブリック・インタフェースおよびプライベート・インタフェースや、インターコネクトのデータベース・インスタンスによるロードが表示されます。
プライベート・インターコネクト間の全体スループット
設定の問題が原因で、データベース・インスタンスがパブリック・インタフェースを使用している場合の通知
インターコネクトのスループットおよびエラー(ある場合)
インターコネクトの個々のインスタンスによるスループット
この情報はすべて、履歴ビューを持つコレクションとしても使用可能です。このことは、クラスタの待機イベント関連の問題を診断する場合などに、クラスタ・キャッシュ一貫性と併用すると有効です。クラスタ・データベースの「ホーム」ページで「InterConnect」タブをクリックするか、またはOracle RACデータベースの「ホーム」ページで診断結果の「インターコネクト・アラート」リンクをクリックすると、「インターコネクト」ページにアクセスできます。
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、同時実行性、アプリケーション、コミット、構成、管理、ネットワーク、クラスタおよびその他)で表示されます。表示されたデータは、実行中のすべてのインスタンスからロールアップされます。
すべてのアクティビティ・データが、サービスごとにロールアップされます。この方法でアクティビティ・データを表示すると、最もアクティブなサービスおよび詳細な分析が必要なサービスを簡単に特定できます。
同様の結果として、サービスが対象のサービスでない場合、アクティビティ・データはインスタンスごとにロールアップされます。
集計はアクティビティ・データが表示されているページ(「データベース・パフォーマンス」ページ、「トップ・アクティビティ」ページ、「待機の詳細」ページ、「サービスの詳細」ページなど)に表示されます。
|
関連項目: 『Oracle Database 2日でReal Application Clustersガイド』 |
非クラスタのOracle Databaseのすべてのチューニング方法は、Oracle RACデータベースに適用されます。したがって、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』の説明に従って、非クラスタのチューニング方法を実施してください。
インターコネクトとノード間通信のプロトコルは、キャッシュ・フュージョンのパフォーマンスに影響を与える場合があります。さらに、インターコネクトの帯域幅、その待機時間およびIPCプロトコルの効率によって、キャッシュ・フュージョンがブロック転送を処理する速度が決まります。
接続したOracle RACデータベース・インスタンスのインターコネクト設定を検証するには、V$CLUSTER_INTERCONNECTSおよびV$CONFIGURED_INTERCONNECTSビューを問い合せます。次に例を示します。
例13-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ビューを問い合せて、クラスタ内のすべてのインスタンスのエントリを表示できます。 |
一度インターコネクトが動作可能になると、インターコネクトのパフォーマンスを大きく変更することはできません。ただし、プロセス間通信(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アドレスを割り当てることができます。 |
|
関連項目: CLUSTER_INTERCONNECTSパラメータの詳細は、『Oracle Databaseリファレンス』 |
各インスタンスには、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;
|
関連項目: GV$ビューの詳細は、『Oracle Databaseリファレンス』 |
Oracle RACデータベースの作成にDatabase Configuration Assistant(DBCA)を使用しなかった場合は、CATCLUST.SQLスクリプトを実行してOracle RAC関連のビューと表を作成する必要があります。このスクリプトの実行には、SYSDBA権限が必要です。
|
関連項目: Oracle RACデータベースの作成の詳細は、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。 |
Oracle RACの統計は、メッセージ要求カウンタまたは定期的な統計として表示されます。メッセージ要求カウンタには、特定のタイプのブロック・モード変換の数を示す統計が含まれます。定期的な統計は、特定のタイプの操作での読取りおよび書込みI/Oに対する、合計または平均の待機時間を示します。
自動ワークロード・リポジトリ(AWR)を使用して、Oracle RACデータベースに関連するパフォーマンスの統計を監視できます。AWRでは、パフォーマンス・データのスナップショットを1時間ごとに自動生成し、統計をワークロード・リポジトリに収集します。Oracle RAC環境では、AWRの各スナップショットがクラスタ内のすべてのアクティブなインスタンスからデータを取得します。取得される各スナップショット・セットのデータは、同じ時点のものです。AWRでは、すべてのインスタンスのスナップショット・データが同じ表に格納され、データはインスタンス修飾子で識別されます。たとえば、BUFFER_BUSY_WAIT統計では、各インスタンスのバッファ待機の数が示されます。AWRでは、クラスタ全体から集計されるデータは格納されません。つまり、データは各インスタンスごとに個別に格納されます。
Automatic Database Diagnostic Monitor(ADDM)を使用すると、Oracle Databaseにおいて考えられるパフォーマンス上の問題がないか、AWRで収集された情報を分析できます。ADDMでは、クラスタ全体の観点からパフォーマンス・データを表示するため、全体的なパフォーマンス分析が可能です。Oracle RAC環境では、ADDMは、すべてのインスタンスから収集されたデータを使用してパフォーマンスを分析し、次のような様々なレベルの粒度で表示できます。
クラスタ全体の分析
特定のデータベース・インスタンスの分析
データベース・インスタンスのサブセットの分析
これらの分析を行うには、ADDMアドバイザをOracle RACのADDMのモードで実行してクラスタ全体の分析を行うか、ローカルADDMのモードで個々のインスタンスのパフォーマンスを分析するか、または部分ADDMモードでインスタンスのサブセットを分析します。Oracle Enterprise Managerのアドバイザ・セントラルまたはDBMS_ADVISORパッケージおよびDBMS_ADDM PL/SQLパッケージを介したアドバイザ・フレームワークを使用して、ADDM分析をアクティブ化します。
|
関連項目:
|
この項では、Oracle RACのアクティブ・セッション履歴(ASH)レポートについて説明します。内容は次のとおりです。
|
関連項目: ASHレポートの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
ASHはOracle Databaseの自己管理フレームワークにとって不可欠な部分であり、Oracle RAC環境のパフォーマンスの問題の診断に役立ちます。ASHレポート統計は、Oracle Databaseのセッション・アクティビティに関する詳細を示します。Oracle Databaseでは、Oracle RACのすべてのアクティブ・インスタンスのアクティブ・セッションに関する情報を記録して、このデータをシステム・グローバル領域(SGA)に格納します。データベースに接続してCPUを使用しているすべてのセッションが、アクティブ・セッションとみなされます。ただし、アイドル状態の待機クラスに属するイベントを待機しているセッションは例外です。
ASHレポートは、アクティブ・セッションの情報のみを取り込むことによって、管理可能なデータのセットを表示します。データの量は、システムで許可されているセッションの数ではなく、実行されている作業に直接関連します。
指定した期間中に収集されたASH統計をASHレポートに含めることができます。各ASHレポートは、ADDM分析には表示されない短時間のパフォーマンスの問題を特定できるように、複数のセクションに分割されています。Oracle RAC固有の2つのASHレポート・セクションは、次の2つの項で説明するとおり、トップ・クラスタ・イベントとトップ・リモート・インスタンスです。
ASHレポートのトップ・クラスタ・イベント・セクションは、Oracle RAC固有のトップ・イベント・レポートの一部です。トップ・クラスタ・イベント・レポートでは、クラスタ待機クラスのイベントのうちセッション・アクティビティの割合が最も高いイベントと、影響を受けるインスタンスのインスタンス番号が表示されます。この情報を使用して、クラスタ待機イベントの割合を上げているイベントおよびインスタンスを特定できます。
この項では、Oracle RAC固有の待機イベントおよび統計を説明し、自動ワークロード・リポジトリ(AWR)、Statspackまたは動的パフォーマンス・ビューの非定型問合せによって生成されたパフォーマンス・データを評価する場合の、待機イベントおよび統計の解析方法も説明します。
この項の内容は次のとおりです。
|
関連項目: 待機イベントの分析の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。Statspackユーティリティの詳細は、spdoc.txtファイルを参照してください。 |
AWRおよびStatspackによって生成された統計スナップショットは、サマリー・データ(定期的な統計に基づくロード・プロファイルおよびクラスタ・プロファイル、インスタンスごとに収集された待機イベントなど)を表示するレポートを作成して評価します。
ほとんどの関連データは、Oracle RACの「統計」ページに集約されます。集約される情報は、次のとおりです。
レポートの後半には、次の追加の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)で使用されます。
インスタンス間のメッセージ交換および競合に関連する作業量およびコストを判断するために、次の項の説明に従って、ブロック転送率、各トランザクションで発生したリモート要求、グローバル・キャッシュ・イベントの待機数および待機時間を調べます。
グローバル・キャッシュ内のブロックへのアクセス、および一貫性を保持した場合の効果は、次の情報で示されます。
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は発生しません。
この項では、すべてのインスタンスによる使用頻度の高い(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での待機時間が最も長いクラスタも特定されます。
この項では、読込みおよび変更頻度の高いオブジェクトおよびリモート・アクセスにより発生するサービス時間を識別して、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を特定します。
AWRおよびStatspackレポートまたは動的パフォーマンス・ビューで高い合計時間が示されるほとんどのグローバル・キャッシュ待機イベントは正常で、実際に問題があるのではなく、データベース時間の上位の使用者として表示されることがあります。この項では、パフォーマンス・データを解析する際に注意が必要な、発生頻度の高い待機イベントについて説明します。
ユーザーの応答時間が長くなり、グローバル・キャッシュでの待機時間の比率が高い場合は、その原因を特定する必要があります。ほとんどのレポートには、合計時間に対する待機時間の割合の順で待機イベントが表示されます。
最初に、定期的に収集されるパフォーマンス統計の影響と、待機時間のほとんどを占めるオブジェクトおよびSQLを特定するADDMレポートを分析します。その後、AWRおよびStatspackにより生成される詳細なレポートを分析することをお薦めします。
Oracle RACの待機イベントは、次のカテゴリに分類されます。
gc current block 2-way
gc current block 3-way
gc cr block 2-way
gc cr block 3-way
ブロック関連待機イベント統計は、ブロックが2方向または3方向メッセージの結果として受信されたことを示します。つまり、1メッセージおよび1転送を必要とするリソース・マスターから、ブロックが送信されたか、または2メッセージおよび1ブロック転送を必要とする別のノード(送信元)へブロックが転送されたことを示します。
gc current grant 2-way
gc cr grant 2-way
メッセージ関連待機イベント統計は、インスタンスにブロックがキャッシュされなかったために、ブロックが受信されなかったことを示します。かわりに、要求側インスタンスがディスクからのブロックを読み取ったり、ブロックを変更できるグローバルな権限が付与されます。
これらのイベントの処理時間が長い場合は、使用頻度の高いSQLによるディスクI/O回数の増加(cr grantの場合)、またはワークロードによって大量のデータが挿入されたため、頻繁に新しいブロックを検索しフォーマットする必要があると(current grantの場合)考えられます。
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が根本的な原因と考えられます。
