日本語PDF

14 パフォーマンスの監視

この章では、Oracle Real Application Clusters(Oracle RAC)のパフォーマンスを監視およびチューニングする方法について説明します。

この章の内容は次のとおりです。

• Oracle RACデータベースの監視およびチューニングの概要

• Oracle RACのインターコネクト設定の検証

• インターコネクト処理への影響

• Oracle RACのパフォーマンス・ビュー

• CATCLUST.SQLによるOracle RACのデータ・ディクショナリ・ビューの作成

• Oracle RACのパフォーマンス統計

• Oracle RAC環境における自動ワークロード・リポジトリ

• Oracle RACのアクティブ・セッション履歴レポート

• Oracle RACの統計および待機イベントの監視

Oracle RACデータベースの監視およびチューニングの概要

この項には次のトピックが含まれます:

• Oracle RACおよびOracle Clusterwareの監視

• Oracle RACデータベースのチューニング

• データベース信頼性フレームワーク

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 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 RACデータベースのチューニング

非クラスタのOracle Databaseのすべてのチューニング方法は、Oracle RACデータベースに適用されます。

データベース信頼性フレームワーク

データベース信頼性フレームワーク(DRF)は、プロアクティブで自動的な監視および修正のフレームワークです。

データベース信頼性フレームワークは、サービスの中断が発生する前に問題を検出するために、データベースの様々な階層で各種のメトリックを継続的に監視します。DRFは、データベースの重要なイベントを監視し、それらの重要なイベントが特定のしきい値を超えた場合に修正アクションを取ることによって、データベースの可用性を向上させます。

問題が特定されると、アクションが自動的に実装されます。識別された問題に応じて、内部メモリー構造のサイズ変更、Oracle RACプロセスの優先度の変更などのアクションがあります。たとえば、一定の期間に収集されたメトリックに基づくとI/Oの競合はないがredo waitsが高いシステムについて考えてみます。使用可能なCPUリソースが十分にある場合は、redo waitsを減らすためのアクション計画として、LGWRプロセスの優先度を高くして十分なCPUが確保されるようにすることが考えられます。DRFでは、すべてのメトリックを慎重に検討した後に、この処理が行われます。これにより、時間の経過に従って問題が悪化してデータベースの可用性に影響を与える前に、最小限のサービス中断で問題が解決されます。

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

インターコネクト処理への影響

インターコネクトが動作可能になると、そのパフォーマンスに大きな影響を与えることはできません。ただし、プロセス間通信(IPC) のバッファ・サイズを調整することで、インターコネクト・プロトコルの効率を変更できます。

Oracle Clusterwareでは、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アドレスまたはプライベートIPアドレスを割り当てることができます。
• Oracle Clusterware 12cリリース2 (12.2)以降のOracle Clusterwareリリースでは、IPv4アドレスまたはIPv6アドレスを複数のプライベート・ネットワークに割り当てることができます。ただし、いずれか一方のプロトコルを選択し、クラスタ内のすべてのプライベート・ネットワークでそのプロトコルを使用する必要があります。

Oracle RACのパフォーマンス・ビュー

Oracle Real Application Clusters (Oracle RAC)データベースに関するパフォーマンス情報を取得するには、インスタンス固有のビューを問い合せるか、クラスタ全体の動的パフォーマンス・ビューを問い合せることができます。

Oracle Real Application Clusters (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;

CATCLUST.SQLによるOracle RACのデータ・ディクショナリ・ビューの作成

Oracle RACデータベースの作成にOracle DBCAを使用しなかった場合は、CATCLUST.SQLスクリプトを実行してOracle RAC関連のビューおよび表を作成する必要があります。

Oracle Database Configuration Assistant (Oracle DBCA)を使用してOracle Real Application Clusters (Oracle RAC)データベースを作成しなかった場合、Oracle RACのデータ・ディクショナリの設定は完了していません。Oracle RACに関連するビューおよび表を作成するには、CATCLUST.SQLスクリプトを実行する必要があります。CATCLUST.SQLスクリプトを実行するには、使用するユーザー・アカウントにSYSDBA権限を付与する必要があります。

Oracle RACのパフォーマンス統計

Oracle Real Application Clusters (Oracle RAC)の統計は、メッセージ・リクエスト・カウンタまたは定期的な統計として表示されます。

メッセージ要求カウンタには、特定のタイプのブロック・モード変換の数を示す統計が含まれます。定期的な統計は、特定のタイプの操作での読取りおよび書込みI/Oに対する、合計または平均の待機時間を示します。

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分析をアクティブ化します。

Oracle RACのアクティブ・セッション履歴レポート

この項では、Oracle RACのアクティブ・セッション履歴(ASH)レポートについて説明します。内容は次のとおりです。

• Oracle RACのASHレポートの概要

• Oracle RACのASHレポート: トップ・クラスタ・イベント

• Oracle RACのASHレポート: トップ・リモート・インスタンス

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つの項で説明するとおり、トップ・クラスタ・イベントとトップ・リモート・インスタンスです。

Oracle RACのASHレポート: トップ・クラスタ・イベント

ASHレポートのトップ・クラスタ・イベント・セクションは、Oracle RAC固有のトップ・イベント・レポートの一部です。トップ・クラスタ・イベント・レポートでは、クラスタ待機クラスのイベントのうちセッション・アクティビティの割合が最も高いイベントと、影響を受けるインスタンスのインスタンス番号が表示されます。この情報を使用して、クラスタ待機イベントの割合を上げているイベントおよびインスタンスを特定できます。

Oracle RACのASHレポート: トップ・リモート・インスタンス

ASHレポートのトップ・リモート・インスタンス・セクションは、Oracle RAC固有のトップ・ロード・プロファイル・レポートの一部です。トップ・リモート・インスタンス・レポートでは、クラスタ待機イベントと、セッション・アクティビティの割合が最も高いインスタンスのインスタンス番号が表示されます。この情報を使用して、クラスタ待機期間を長くしているインスタンスを特定できます。

Oracle RACの統計および待機イベントの監視

この項では、Oracle RAC固有の待機イベントおよび統計を説明し、自動ワークロード・リポジトリ(AWR)、Statspackまたは動的パフォーマンス・ビューの非定型問合せによって生成されたパフォーマンス・データを評価する場合の、待機イベントおよび統計の解析方法も説明します。

この項には次のトピックが含まれます:

• AWRおよびStatspackレポートでのOracle RAC統計およびイベント

• Oracle RACの待機イベント

• GCS統計とGES統計の分析によるパフォーマンス監視

• GCS統計を使用したキャッシュ・フュージョンによる転送の影響の分析

• 待機イベントに基づく応答時間の分析

AWRおよびStatspackレポートでのOracle RAC統計およびイベント

AWRおよびStatspackによって生成された統計スナップショットは、サマリー・データ(定期的な統計に基づくロード・プロファイルおよびクラスタ・プロファイル、インスタンスごとに収集された待機イベントなど)を表示するレポートを作成して評価します。

ほとんどの関連データは、Oracle RACの「統計」ページに集約されます。次のような情報があります。

• グローバル・キャッシュのロード・プロファイル

• グローバル・キャッシュの効率(パーセント)—ワークロード特性

• グローバル・キャッシュおよびエンキュー・サービス(GES)—メッセージ機能の統計

レポートの後半には、次の追加のOracle RACセクションが表示されます。

• グローバル・エンキュー統計

• グローバルCR統計

• 実行済のグローバルCURRENT統計

• グローバル・キャッシュの送信統計。

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

• すべてのディスク読取りが優先される場合の複数ブロック読取りリクエスト・イベント。たとえば:

  • gc cr multi block grant
  • gc cr multi block mixed

つまり、Oracle RACの待機イベントは、パフォーマンス分析にとって重要な情報を伝達します。これらのイベントは、キャッシュ・フュージョンの影響を正確に診断するために、Automatic Database Diagnostic Monitor(ADDM)で使用されます。

GCS統計とGES統計の分析によるパフォーマンス監視

インスタンス間のメッセージ交換および競合に関連する作業量およびコストを判断するには、次の項の説明に従って、ブロック転送率、各トランザクションで発生したリモート要求、グローバル・キャッシュ・イベントの待機数および待機時間を調べます。

• キャッシュ・フュージョンがOracle RACに与える影響の分析

• GCS統計とGES統計を使用したパフォーマンス分析

キャッシュ・フュージョンが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は発生しません。

GCS統計とGES統計を使用したパフォーマンス分析

すべてのインスタンスによる使用頻度の高い(ホットな)データ・ブロックとオブジェクトを識別して、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統計を使用したキャッシュ・フュージョンによる転送の影響の分析

読込み頻度と変更頻度の高いオブジェクトおよびリモート・アクセスにより発生するサービス時間を識別して、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が根本的な原因と考えられます。

ロード関連の待機イベント

ロード関連待機の主な待機イベントは、次のとおりです。

• gc current block congested

• gc cr block congested

ロード関連待機イベントは、GCSで処理遅延が発生したことを示します。通常、その原因となるのは、高負荷、飽和状態のCPUです。この問題は、CPUの追加、ロード・バランシング、別のラウンドトリップ時間帯または新しいクラスタ・ノードへの処理のオフロード処理によって解決できます。前述のイベントについての待機時間には、セッションが開始し、ブロック要求開始後、ブロックの到着を待機するまでのラウンドトリップ全体が含まれます。