1. Real Application Clusters管理およびデプロイメント・ガイド
  2. パフォーマンスの監視

14 パフォーマンスの監視

Oracle Real Application Clusters (Oracle RAC)データベースのパフォーマンスの監視およびチューニング方法について説明します。

注意:

マルチテナント・コンテナ・データベースは、Oracle Database 20cで唯一サポートされているアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、"データベース"と"非CDB"は、文脈に応じてCDBまたはPDBを指しています。アップグレードなどでは、"非CDB"が以前のリリースの非CDBを指している場合もあります。

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

Oracle Real Application Clusters (Oracle RAC)データベースの監視およびチューニングと、これらのタスクを支援するデータベース信頼性フレームワークの使用方法について説明します。

  • Oracle RACおよびOracle Clusterwareの監視の概要
    クラスタ・データベースの「ホーム」ページ、「インターコネクト」ページ、クラスタ・データベースの「パフォーマンス」ページなど、Oracle Enterprise Managerの監視機能について説明します。
  • Oracle RACデータベースのチューニング
    Oracle Databaseの非クラスタのチューニング・プラクティスはすべて、Oracle Real Application Clusters (Oracle RAC)データベースにも適用されます。
  • データベース信頼性フレームワーク
    データベース信頼性フレームワーク(DRF)は、Oracle Real Application Clusters (Oracle RAC)データベースのプロアクティブで自動的な監視および修正のフレームワークです。

親トピック: パフォーマンスの監視

14.1.1 Oracle RACおよびOracle Clusterwareの監視の概要

クラスタ・データベースの「ホーム」ページ、「インターコネクト」ページ、クラスタ・データベースの「パフォーマンス」ページなど、Oracle Enterprise Managerの監視機能について説明します。

親トピック: Oracle RACデータベースの監視およびチューニング

14.1.1.1 Oracle Enterprise ManagerによるOracle RACおよびOracle Clusterwareの監視

Oracle Real Application Clusters (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は、現在のデータ(リアルタイム・データ)も提供します。

14.1.1.2 クラスタ・データベースの「ホーム」ページ

Oracle Enterprise Managerのクラスタ・データベースの「ホーム」ページを使用すると、クライアント・ブラウザを使用して、Oracle Clusterware環境とOracle Real Application Clusters (Oracle RAC)環境の両方のステータスを監視できます。

Oracle Enterprise Managerのクラスタ・データベースの「ホーム」ページでは、クラスタ環境全体を監視します。監視には次のタスクが含まれます。

  • VIPの再配置が行われた場合の通知
  • クラスタ検証ユーティリティ(cluvfy)により取得した情報を使用する、クラスタの各ノードのOracle Clusterwareのステータス
  • ノード・アプリケーション(nodeapps)が起動または停止した場合の通知
  • Oracle ClusterwareのOCR用アラート・ログに記録された問題、投票ディスクの問題(ある場合)およびノード削除の通知

クラスタ・データベースの「ホーム」ページは、非クラスタ・データベースの「ホーム」ページと似ています。ただし、クラスタ・データベースの「ホーム」ページには、Oracle Enterprise Managerにより、システムの状態と可用性が表示されます。システムの状態には、アラート・メッセージおよびジョブ・アクティビティのサマリーと、すべてのデータベースおよびOracle Automatic Storage Management (Oracle ASM)インスタンスへのリンクが含まれます。たとえば、すべての優先インスタンスでサービスが実行されていない場合、またはサービスの応答時間のしきい値条件が満たされていない場合などに、クラスタでのサービスに関する問題を追跡できます。

14.1.1.3 「インターコネクト」ページ

Oracle Enterprise Managerの「インターコネクト」ページを使用すると、クライアント・ブラウザを使用してプライベート・ネットワークのステータスを監視し、クラスタ待機イベントのトラブルシューティングを行うことができます。

Oracle Enterprise Managerの「インターコネクト」ページを使用して、Oracle Clusterware環境を監視できます。「インターコネクト」ページには、次のような、クラスタのパブリック・インタフェースおよびプライベート・インタフェースや、インターコネクトのデータベース・インスタンスによるロードが表示されます。

  • プライベート・インターコネクトでの全体的なスループット
  • 構成ミスのためデータベース・インスタンスがパブリック・インタフェースを使用している場合の通知
  • インターコネクトのスループットおよびエラー(発生した場合)
  • インスタンスごとのインターコネクトのスループット

これらの情報はすべて、履歴表示を含む収集としても使用することができ、このことは、クラスタの待機イベント関連の問題を診断する場合などに、クラスタ・キャッシュ一貫性と併用すると有効です。クラスタ・データベースの「ホーム」ページで「InterConnect」タブをクリックするか、またはOracle RACデータベースの「ホーム」ページで「診断の結果」の「インターコネクト・アラート」リンクをクリックすると、「インターコネクト」ページにアクセスできます。

14.1.1.4 「クラスタ・データベース」の「パフォーマンス」ページ

Oracle Enterprise Managerのクラスタ・データベースの「パフォーマンス」ページには、Oracle Real Application Clusters (Oracle RAC)データベースのパフォーマンス統計が簡易表示されます。

統計は、グラフにあるクラスタ・データベース内のすべてのインスタンス間でロールアップされます。グラフの横のリンクを使用すると、より詳細な情報を取得したり、次のタスクを実行することができます。

  • パフォーマンスの問題の原因の特定。
  • リソースを追加または再分散する必要があるかどうかの判別。
  • 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.1.2 Oracle RACデータベースのチューニング

Oracle Databaseの非クラスタのチューニング・プラクティスはすべて、Oracle Real Application Clusters (Oracle RAC)データベースにも適用されます。

関連項目

親トピック: Oracle RACデータベースの監視およびチューニング

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

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

データベース信頼性フレームワーク(DRF)は、サービスの中断が発生する前に問題を検出するために、データベースの様々なレイヤーで各種のメトリックを継続的に監視します。DRFでは、クラスタ内のすべてのデータベース・インスタンスでクリティカル・イベントを監視して根本原因を特定することにより、データベースの可用性を向上させます。これにより、これらのクリティカル・イベントが特定のしきい値に達したときに、修正措置を講じることができます。

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

親トピック: Oracle RACデータベースの監視およびチューニング

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

Oracle Real Application Clusters (Oracle RAC)のインターコネクト設定を検証するには、SQL文を使用します。

インターコネクトとノード間通信のプロトコルは、キャッシュ・フュージョンのパフォーマンスに影響を与える場合があります。さらに、インターコネクトの帯域幅、その待機時間および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 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アドレスを複数のプライベート・ネットワークに割り当てることができます。ただし、いずれか一方のプロトコルを選択し、クラスタ内のすべてのプライベート・ネットワークでそのプロトコルを使用する必要があります。

関連項目

親トピック: パフォーマンスの監視

14.4 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;

関連項目

親トピック: パフォーマンスの監視

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

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

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

関連項目

親トピック: パフォーマンスの監視

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

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

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

親トピック: パフォーマンスの監視

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のアクティブ・セッション履歴レポート

アクティブ・セッション履歴(ASH)レポートを使用してOracle Real Application Clusters (Oracle RAC)データベースのステータスを確認する方法について説明します。

  • Oracle RACのASHレポートの概要
    パフォーマンスの問題を診断するために、アクティブ・セッション履歴(ASH)レポートにはOracle Real Application Clusters (Oracle RAC)データベース内のすべてのアクティブ・セッションに関する情報が示されます。
  • Oracle RACのASHレポート: トップ・クラスタ・イベント
    クラスタ待機イベントの割合が高い原因となるイベントおよびインスタンスを特定するには、アクティブ・セッション履歴(ASH)のトップ・クラスタ・イベント・レポートを使用します。
  • Oracle RACのASHレポート: トップ・リモート・インスタンス
    クラスタ待機期間が長くなる原因となる特定のインスタンスを特定するには、アクティブ・セッション履歴(ASH)のトップ・リモート・インスタンス・レポートを使用します。

親トピック: パフォーマンスの監視

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

パフォーマンスの問題を診断するために、アクティブ・セッション履歴(ASH)レポートにはOracle Real Application Clusters (Oracle RAC)データベース内のすべてのアクティブ・セッションに関する情報が示されます。

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のアクティブ・セッション履歴レポート

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

クラスタ待機イベントの割合が高い原因となるイベントおよびインスタンスを特定するには、アクティブ・セッション履歴(ASH)のトップ・クラスタ・イベント・レポートを使用します。

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

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

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

クラスタ待機期間が長くなる原因となる特定のインスタンスを特定するには、アクティブ・セッション履歴(ASH)のトップ・リモート・インスタンス・レポートを使用します。

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

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

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

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

親トピック: パフォーマンスの監視

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

AWRおよびStatspackによって生成された統計スナップショットを評価するには、サマリー・データ・レポートを生成します。

自動ワークロード・リポジトリ(AWR)とSQL、PL/SQLおよびSQL*PlusスクリプトのStatspackパッケージ・セットによって生成された統計スナップショットは、サマリー・データを表示するレポートを作成することで評価できます。たとえば、通常の統計に基づいたロードおよびクラスタ・プロファイルなどのデータや、各インスタンスで収集された待機イベントを示すサマリー・レポートを作成できます。

ほとんどの関連データは、Oracle Real Application Clusters (Oracle RAC)の「統計」ページにまとめられます。次のような情報があります。

  • グローバル・キャッシュのロード・プロファイル
  • グローバル・キャッシュの効率(パーセント): ワークロード特性
  • グローバル・キャッシュおよびエンキュー・サービス(GES): メッセージ機能の統計

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

  • グローバル・エンキュー統計
  • グローバルCR統計
  • 実行済のグローバルCURRENT統計
  • グローバル・キャッシュの送信統計。

関連項目

親トピック: 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)で使用されます。

親トピック: Oracle RACの統計および待機イベントの監視

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

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

親トピック: Oracle RACの統計および待機イベントの監視

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

Global Cache Service (GCS)統計、GCS待機イベント、およびOracle Real Application Clusters (Oracle RAC)データベースのキャッシュ・フュージョンとの関係について説明します。

グローバル・キャッシュ内のブロックへのアクセス、および一貫性を保持した場合の効果は、次の情報で示されます。

  • currentおよびcrブロックのグローバル・キャッシュ・サービス(GCS)統計。例: gc current blocks received、gc cr blocks receivedなど
  • 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統計を使用したパフォーマンス分析

すべてのインスタンスによる使用頻度の高い(ホットな)データ・ブロックとオブジェクトを識別して、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についてのオブジェクト統計により、アクティブ・インスタンスで共有される索引および表が簡単に特定できます。前述のとおり、通常は、Automatic Database Diagnostic Monitor (ADDM)による分析を行うと、インスタンス間の競合によって影響を受ける可能性があるSQL文およびデータベース・オブジェクトが示されます。

前述のリストで示したイベントの平均待機時間を増加させる原因は、次のとおりである可能性があります。

  • 高負荷: CPUの容量不足、長い実行キュー、スケジュールの遅延
  • 設定の問題: メッセージおよびブロック通信量にプライベート・インターコネクトではなくパブリック・インターコネクトを使用している

平均待機時間は許容範囲内で、インターコネクトまたはロードの問題を診断できない場合は、通常、アクセスされるブロック数が最小限になるようにチューニングする必要があるいくつかのSQL文が累計待機時間の原因になっている可能性があります。

V$SQLAREAのCLUSTER_WAIT_TIME列は、グローバル・キャッシュ・イベントの個々のSQL文によって発生する待機時間を表します。この列を確認することで、チューニングを必要とするSQLを特定できます。

親トピック: Oracle RACの統計および待機イベントの監視

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

実際に問題があるのではなく、データベース時間の上位コンシューマとして表示されることがあるグローバル・キャッシュ待機イベントを分析する方法について説明します。

親トピック: Oracle RACの統計および待機イベントの監視

14.9.5.1 通常および問題の待機イベント・レスポンス時間の理解

通常の待機イベントと問題を示す待機イベントを区別するには、定期的なパフォーマンス統計を確認し、パフォーマンス・データを解析するときに注意する必要のある頻繁な待機イベントを探します。

自動ワークロード・リポジトリ(AWR)レポートと、SQL、PL/SQLおよびSQL*PlusレポートのStatspackセットを確認するか、または動的パフォーマンス・ビューを確認すると、これらのレポートで合計時間が長いグローバル・キャッシュ待機イベントのほとんどは正常です。これらの正常な待機イベントは、実際に問題があるのではなく、データベース時間の上位コンシューマとして表示されることがあります。

ユーザーの応答時間が長くなり、グローバル・キャッシュでの待機時間の比率が高い場合は、その原因を特定する必要があります。ほとんどのレポートには、合計時間に対する待機時間の割合の順で待機イベントが表示されます。

自動データベース診断モニター(ADDM)レポートから始めると有益です。ADDMレポートでは、定期的に収集されるパフォーマンス統計をその影響に関して分析し、待機時間のほとんどを占めるオブジェクトおよびSQLを特定して、AWRおよびStatspackによって生成されるさらに詳細なレポートに移ります。

14.9.5.2 ブロック関連の待機イベント

ブロック関連待機に関連付けられた主な待機イベントについて説明します。

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

  • 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ブロック転送を必要とする別のノード(送信元)へブロックが転送されたことを示します。

14.9.5.3 メッセージ関連の待機イベント

メッセージ関連待機に関連付けられた主な待機イベントについて説明します。

メッセージ関連待機の主な待機イベントは、次のとおりです。

  • gc current grant 2-way
  • gc cr grant 2-way

メッセージ関連待機イベント統計は、インスタンスにブロックがキャッシュされなかったために、ブロックが受信されなかったことを示します。かわりに、リクエスト側インスタンスがディスクからのブロックを読み取ったり、ブロックを変更できるグローバルな権限が付与されました。

これらのイベントで消費される時間が長い場合は、頻繁に使用されるSQLによって大量のディスクI/Oが発生している(cr grantの場合)か、またはワークロードによって大量のデータが挿入されたために新しいブロックを頻繁に検索してフォーマットする必要がある(current grantの場合)と考えられます。

14.9.5.4 競合関連の待機イベント

競合関連待機に関連付けられた主な待機イベントについて説明します。

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

  • 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が根本的な原因と考えられます。

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

ロード関連待機に関連付けられた主な待機イベントについて説明します。

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

  • gc current block congested
  • gc cr block congested

ロード関連の待機イベントは、GCSで処理の遅延が発生したことを示しており、その原因は通常、高負荷またはCPUの飽和です。この種類の待機イベントを解決するには、CPUをさらに追加するか、ロード・バランシングを拡張するか、異なる時間または新しいクラスタ・ノードに処理をオフロードします。ここで説明した2つのイベントの場合、待機時間には、ブロック・リクエストを開始してからブロックが到着するまで、セッションが待機を開始した時間からのラウンド・トリップ全体が含まれます。