| Oracle Real Application Clusters管理およびデプロイメント・ガイド 11gリリース1（11.1） E05738-05 |
|
 戻る |
 次へ |
この章では、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ガイド』
Automatic Database Diagnostic MonitorおよびOracle RACのパフォーマンス
クライアントのブラウザを使用してOracle Enterprise Managerにログインすると、クラスタ・データベースの「ホーム」ページが表示され、ここで、Oracle ClusterwareおよびOracle RAC環境の両方のステータスを監視できます。監視には次の内容が含まれます。
VIPの再配置が発生した場合の通知
クラスタ検証ユーティリティ（cluvfy）で取得した情報を使用している各クラスタ・ノードのOracle Clusterwareのステータス
ノード・アプリケーション（nodeapps）が起動または停止した場合の通知
Oracle ClusterwareのOCR用アラート・ログに記録された問題、投票ディスクの問題（ある場合）およびノード削除の通知
クラスタ・データベースの「ホーム」ページは、シングル・インスタンスのデータベースの「ホーム」ページと似ています。ただし、クラスタ・データベースの「ホーム」ページには、Oracle Enterprise Managerによって、システムの状態と可用性が表示されます。これには、アラート・メッセージおよびジョブ・アクティビティのサマリーと、全データベースに対するリンクおよび自動ストレージ管理（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トランザクション当たり」ビューには、1トランザクション当たりの物理読取り量とREDOサイズの比較が表示されます。ログオンは、データベースにログオンしているユーザーの数です。
さらに、クラスタ・データベースの「パフォーマンス」ページにある「トップ・アクティビティ」ドリルダウン・メニューでは、待機イベント、サービスおよびインスタンス単位でアクティビティを表示できます。また、グラフのスライダを使用して以前の時点に移動することによって、SQL/セッションの詳細を表示できます。
たとえば、クラスタ・データベースの「パフォーマンス」ページには、Oracle RACデータベースのパフォーマンス統計のサマリーが表示されます。ユーザーがすべてのインスタンスを調べなくてもパフォーマンスの問題を特定できるように、統計はクラスタ・データベース内のすべてのインスタンス間でロールアップされます。サービスに関連したパフォーマンスの問題の優先順位を決定しやすくするために、Oracle Enterprise Managerでは次のレベルでアクティビティ・データを集計します。
すべてのアクティビティ・データが12のカテゴリ（CPU、スケジューラ、ユーザーI/O、システムI/O、同時実行性、アプリケーション、コミット、構成、管理、ネットワーク、クラスタおよびその他）で表示されます。表示されたデータは、実行中のすべてのインスタンスからロールアップされます。
すべてのアクティビティ・データが、サービスごとにロールアップされます。この方法でアクティビティ・データを表示すると、最もアクティブなサービスおよび詳細な分析が必要なサービスを簡単に特定できます。
同様の結果として、サービスが対象のサービスでない場合、アクティビティ・データはインスタンスごとにロールアップされます。
集計はアクティビティ・データが表示されているページ（「データベース・パフォーマンス」ページ、「トップ・アクティビティ」ページ、「待機の詳細」ページ、「サービスの詳細」ページなど）に表示されます。
|
関連項目: 『Oracle Database 2日でReal Application Clustersガイド』 |
インターコネクトとノード間通信のプロトコルは、キャッシュ・フュージョンのパフォーマンスに影響を与える場合があります。さらに、インターコネクトの帯域幅、その待機時間およびIPCプロトコルの効率によって、キャッシュ・フュージョンがブロック転送を処理する速度が決まります。
インターコネクト設定を検証するには、V$CLUSTER_INTERCONNECTSおよびV$CONFIGURED_INTERCONNECTSを問い合せます。次に例を示します。
例12-1 V$CLUSTER_INTERCONNECTSを使用したインターコネクト設定の検証
SQL> SELECT * FROM V$CLUSTER_INTERCONNECTS; NAME IP_ADDRESS IS_ SOURCE --------------- ---------------- --- ------------------------------- eth2 10.137.20.181 NO Oracle Cluster Repository
例12-2 V$CONFIGURED_INTERCONNECTSを使用したインターコネクト設定の検証
SQL> SELECT * FROM V$CONFIGURED_INTERCONNECTS; NAME IP_ADDRESS IS_ SOURCE --------------- ---------------- --- ------------------------------- eth2 10.137.20.181 NO Oracle Cluster Repository eth0 10.137.8.225 YES Oracle Cluster Repository SQL> DESC V$CONFIGURED_INTERCONNECTS Name Null? Type ----------------------------------------- -------- ---------------------------- NAME VARCHAR2(15) IP_ADDRESS VARCHAR2(16) IS_PUBLIC VARCHAR2(3) SOURCE VARCHAR2(31)
一度インターコネクトが動作可能になると、インターコネクトのパフォーマンスを大きく変更することはできません。ただし、IPCのバッファ・サイズを調整することで、インターコネクト・プロトコルの効率を変更できます。
Oracle Cluster Registry（OCR）には、システムのインターコネクト情報が格納されます。oifcfg getifコマンドまたはOCRDUMPユーティリティを使用すると、使用しているインターコネクトを特定できます。その後、oifcfgコマンドを実行して、使用しているインターコネクトを変更できます。
|
関連項目: IPCバッファ・サイズの調整の詳細は、ベンダー固有のインターコネクトのドキュメントを参照してください。 |
ほとんどの場合、CLUSTER_INTERCONNECTSパラメータを設定する必要はありませんが、次の例に示すように、このパラメータを使用すると、プライベート・ネットワークIPアドレスまたはNICを割り当てることができます。
CLUSTER_INTERCONNECTS=10.0.0.1
オペレーティング・システム固有のベンダーIPCプロトコルを使用している場合は、トレース情報からIPアドレスが判明しない場合があります。
|
注意: 『Oracle Clusterware管理およびデプロイメント・ガイド』で説明するoifcfgコマンドを使用しても、CVUを有効化および使用してプライベート・ネットワークIPアドレスまたはプライベート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のインストレーション・ガイドを参照してください。 |
この項では、V$ビューとGV$ビューの概要を説明します。この2つのビューからは、クラスタ内のブロック転送の評価に使用できる統計が得られます。これらの統計を使用して、インターコネクトのブロック転送率やOracle RACデータベース全体のパフォーマンスを分析します。
Oracle RACの統計は、メッセージ要求カウンタまたは定期的な統計として表示されます。メッセージ要求カウンタには、特定のタイプのブロック・モード変換の数を示す統計が含まれます。定期的な統計は、特定のタイプの操作での読取りおよび書込みI/Oに対する、合計または平均の待機時間を示します。
自動ワークロード・リポジトリを使用して、Oracle RACデータベース関連のパフォーマンス統計を監視できます。AWRでは、1時間ごとに自動的にパフォーマンス・データのスナップショットを生成して、ワークロード・リポジトリ内の統計を収集します。Oracle RAC環境では、AWRの各スナップショットで、クラスタ内のすべてのアクティブ・インスタンスからデータが取り込まれます。各スナップショット・セットのデータは、同一時点で取り込まれます。AWRでは、すべてのインスタンスのスナップショット・データを同じ表に格納します。データはインスタンス修飾子で識別されます。たとえば、BUFFER_BUSY_WAITという統計は、各インスタンスのバッファ待機数を示します。AWRには、クラスタ全体から集約されたデータは格納されません。データはインスタンスごとに格納されます。
Automatic Database Diagnostic Monitor（ADDM）を使用すると、AWRで収集した情報を分析して、Oracle Databaseで発生している可能性のあるパフォーマンスの問題を確認できます。ADDMでは、クラスタ全体の観点からパフォーマンス・データを提供します。そのため、全体的なパフォーマンス分析が可能です。Oracle RAC環境のADDMでは、すべてのインスタンスから収集したデータを使用して、次のような詳細なレベルでパフォーマンスを分析し、表示します。
クラスタ全体の分析
特定のデータベース・インスタンスの分析
データベース・インスタンスのサブセットの分析
これらの分析を実行するには、それぞれのモードでADDMアドバイザを実行します。すなわち、クラスタ全体を分析するにはOracle Real Application ClustersのADDMモード、個々のインスタンスのパフォーマンスを分析するにはローカルADDMモード、インスタンスのサブセットを分析するには部分ADDMモードで、ADDMアドバイザを実行します。ADDM分析は、Oracle Enterprise Managerのアドバイザ・セントラル、またはDBMS_ADVISORおよびDBMS_ADDM PL/SQLパッケージを介したアドバイザ・フレームワークでアクティブ化できます。
|
関連項目:
|
この項では、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つの項で説明するとおり、トップ・クラスタ・イベントとトップ・リモート・インスタンスです。
ASHレポートのトップ・クラスタ・イベントセクションは、Oracle RAC固有のトップ・イベント・レポートの一部です。トップ・クラスタ・イベント・レポートでは、クラスタ待機クラスのイベントのうちセッション・アクティビティの割合が最も高いイベントと、影響を受けるインスタンスのインスタンス番号が表示されます。この情報を使用して、クラスタ待機イベントの割合を上げているイベントおよびインスタンスを特定できます。
ASHレポートのトップ・リモート・インスタンスセクションは、Oracle RAC固有のトップ・ロード・プロファイル・レポートの一部です。トップ・リモート・インスタンス・レポートでは、クラスタ待機イベントと、セッション・アクティビティの割合が最も高いインスタンスのインスタンス番号が表示されます。この情報を使用して、クラスタ待機期間を長くしているインスタンスを特定できます。
|
関連項目: ASHレポートの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
この項では、Oracle RAC固有の待機イベントおよび統計を説明します。また、自動ワークロード・リポジトリ、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などのカレント・ブロックおよび読取り一貫性ブロックについてのグローバル・キャッシュ・サービス統計
gc current block 3-way、gc cr grant 2-wayなどのグローバル・キャッシュ・サービスの待機イベント
キャッシュ・フュージョンによる転送の応答時間は、物理的なインターコネクト・コンポーネント、IPCプロトコルおよびGCSプロトコルの制限が適用されるメッセージングおよび処理時間によって決まります。この応答時間は、不定期のログ書込み以外のディスクI/O要因による影響は受けません。キャッシュ・フュージョン・プロトコルの場合は、キャッシュ一貫性を保証するためのデータ・ファイルへのI/Oを行う必要はありません。基本的にOracle RACでは、非クラスタ・インスタンスより多くのディスクI/Oが発生しません。
この項では、すべてのインスタンスでの使用頻度が高いホット・データ・ブロックおよびホット・オブジェクトを識別して、グローバル・キャッシュ・サービスのパフォーマンスを監視する方法を説明します。並行処理回数の多いブロックは、グローバル・キャッシュ・サービスの待機イベントおよび待機数によって特定できます。
gc current block busyの待機イベントは、リモート・キャッシュまたはローカル・キャッシュがビジーなため、キャッシュ・データ・ブロックへのアクセスが遅延状態であることを示します。これは、セッションによるブロックの確保や保留、またはリモート・インスタンス側のログ書込みによるブロック遅延が発生しているか、または同一インスタンス上のセッションが、インスタンス間を移動中のブロックにアクセスしているため、現行のセッションが待機状態（gc current block busyなど）になっていることを示します。
V$SESSION_WAITビューは競合するオブジェクトおよびデータ・ブロックを識別します。グローバル・キャッシュの待機イベントのP1列およびP2列には、それぞれブロック要求のファイル番号およびブロック番号が指定されています。
前述のV$SESSION_WAITへの問合せなしで、「ビジー」オブジェクトを迅速に判別するために、セグメント統計gc buffer busyが追加されています。
AWRインフラストラクチャは、アクティブ・セッション履歴のビューを提供します。このビューは、最近の待機イベントおよびその引数のトレースにも使用できます。そのため、ホット・ブロック分析に有効です。AWRおよびStatspackで使用されるほとんどのレポート機能に、オブジェクト統計およびクラスタ待機クラスのカテゴリが含まれています。そのため、前述のビューのサンプリングが必要になることはほとんどありません。
AWRインフラストラクチャで収集されたスナップショット・データに対してADDMを実行し、グローバル・キャッシュが与える影響の全体的な評価を取得することをお薦めします。この評価では、ビジー・オブジェクトおよびSQLでの待機時間が最も長いクラスタも特定されます。
この項では、読込みおよび変更頻度の高いオブジェクトおよびリモート・アクセスにより発生するサービス時間を識別して、グローバル・キャッシュ・サービスのパフォーマンスを監視する方法を説明します。ほとんどの場合、ディスク・アクセス待機時間よりもキャッシュ・フュージョンによる転送時間の方が短いという事実はあるものの、ディスクからの読取りによってブロック・アクセス遅延が増加する場合と同様に、ブロックの到着待ちが応答時間のほとんどを占める場合があります。
次の待機イベントは、ブロックの待機、確保またはログ・フラッシュなしでリモート・キャッシュ・ブロックがローカル・インスタンスへ送信されたことを示します。
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を特定します。
|
注意: ADDMおよびAWRを使用することをお薦めします。ただし、Statspackには下位互換性があります。Statspackには、レポート機能のみが用意されています。ブロック競合およびセグメント・ブロックの待機に関連する統計を収集するには、Statspackをレベル7で実行する必要があります。 |
AWRおよびStatspackレポートまたは動的パフォーマンス・ビューに合計時間の高い値が示される場合でも、ほとんどのグローバル・キャッシュ待機イベントは正常です。通常は、これらのイベントがデータベースを長時間使用していることを示しており、実際には問題ありません。この項では、パフォーマンス・データを解析する際に注意が必要な、発生頻度の高い重要な待機イベントを説明します。
ユーザーの応答時間が長くなり、グローバル・キャッシュ（gc）での待機時間の比率が高い場合は、その原因を特定する必要があります。ほとんどのレポートには、合計時間に対する待機時間の割合の順で待機イベントが表示されます。
最初に、定期的に収集されるパフォーマンス統計の影響と、待機時間のほとんどを占めるオブジェクトおよび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
メッセージ指向型
gc current grant 2-way
gc cr grant 2-way
競合指向型
gc current block busy
gc cr block busy
gc buffer busy acquire/release
ロード指向型
gc current block congested
gc cr block congested
ブロック指向型待機イベント統計は、ブロックが2方向または3方向メッセージの結果として受信されたことを示します。つまり、1メッセージおよび1転送を必要とするリソース・マスターから、ブロックが送信されたか、または2メッセージおよび1ブロック転送を必要とする別のノード（送信元）へブロックが転送されたことを示します。
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が根本的な原因と考えられます。
メッセージ指向型待機イベント統計は、インスタンスにブロックがキャッシュされなかったために、ブロックが受信されなかったことを示します。かわりに、要求側インスタンスがディスクからのブロックを読み取ったり、ブロックを変更できるグローバルな権限が付与されます。
これらのイベントの処理時間が長い場合は、使用頻度の高いSQLによるディスクI/O回数の増加（cr grantの場合）、またはワークロードによって大量のデータが挿入されたため、頻繁に新しいブロックを検索しフォーマットする必要があると（current grantの場合）考えられます。
競合指向型待機イベント統計は、別のノードのセッションによって確保されたブロックが受信されたが、ディスクへの変更のフラッシュが完了していないため、または並列性が高いために保留され、すぐに送信できない状態になっていることを示します。セッションがキャッシュ・フュージョン操作をすでに開始している場合は、バッファは、ローカルでもビジーになる可能性があります。また、同一ノード上の別のセッションが、同一データの読取りまたは変更を行う場合、バッファはそれが完了するまで待機します。グローバル・キャッシュ内でやり取りされるブロックのサービス時間が長くなると、競合状態が悪化する可能性があります。これは、同一データに対して頻繁に行われる同時読取りおよび書込みアクセスが原因の可能性もあります。
ロード指向型待機イベントは、GCSで処理遅延が発生したことを示します。通常、その原因となるのは、高負荷、飽和状態のCPUです。この問題は、CPUの追加、ロード・バランシング、別のラウンドトリップ時間帯または新しいクラスタ・ノードへの処理のオフロード処理によって解決できます。前述のイベントについての待機時間には、セッションが開始し、ブロック要求開始後、ブロックの到着を待機するまでのラウンドトリップ全体が含まれます。
