1. データベース・パフォーマンス・チューニング・ガイド
  2. データベース・パフォーマンスの診断およびチューニング
  3. データベース・パフォーマンスの計測

5 データベース・パフォーマンスの計測

この章では、データベース統計を使用してOracle Databaseのパフォーマンスを計測する方法を説明します。

この章のトピックは、次のとおりです:

5.1 データベース統計について

データベース統計により、データベースへの負荷のタイプや、データベースで使用されるリソースに関する情報が提供されます。データベース・パフォーマンスを効果的に計測するには、統計が使用可能であることが必要です。

Oracle Databaseはシステム、セッション、セグメント、サービスおよび個別のSQL文の累積統計のタイプを生成します。統計の累積値には、通常、動的パフォーマンス・ビュー(V$ビュー)を使用してアクセスします。これらの範囲でのデータベース・パフォーマンスを分析する場合は、対象となる期間における統計の変化(デルタ値)を調べます。特に、期間開始時における統計の累積値と終了時における累積値の違いに注意してください。

この項では、Oracle Databaseのパフォーマンス計測に使用される、より重要なデータベース統計のいくつかを説明します。

関連項目:

オプティマイザ統計の詳細は、Oracle Database SQLチューニング・ガイドを参照してください

5.1.1 時間モデル統計

時間モデル統計では、ログオン操作や解析など、データベースで実行される特定アクションの影響を数値化して把握するために時間が使用されます。最も重要な時間モデル統計はデータベース時間(DB時間)です。この統計は、フォアグラウンド・セッションのデータベース・コールで経過した合計時間を表し、またインスタンスのワークロードの合計の指標にもなります。DB時間は、インスタンスの開始時から累計的に計測され、アイドル待機イベントを待機していないすべてのフォアグラウンド・セッション(アイドル状態でないユーザー・セッション)のCPU時間および待機時間を集計することで計算されます。

注意:

DB時間はアイドル状態でないすべてのユーザー・フォアグラウンド・セッションの時間を合計して計算されるため、DB時間がインスタンス起動後の実際の経過時間を超える可能性があります。たとえば、30分実行されているインスタンスに4つのアクティブ・ユーザー・セッションがあれば、その累積DBtimeは約120分になります。

Oracleデータベースをチューニングする場合は、コンポーネントごとに固有の統計セットがあります。システム全体を調べるには、共通の比較尺度が必要です。このため、Oracle Databaseの多くのアドバイザおよびレポートでは、統計が時間単位で記述されます。

最終的には、Oracleデータベースのチューニングは、データベースでアクションの実行にかかる時間を短縮すること、または単にDB時間を短縮することを目的としています。時間モデル統計には、V$SESS_TIME_MODELおよびV$SYS_TIME_MODELビューからアクセスできます。

関連項目:

V$SESS_TIME_MODELおよびV$SYS_TIME_MODELビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

5.1.2 アクティブ・セッション履歴の統計

データベースに接続中で、Idle待機クラスに属さないイベントを待機中のセッションは、アクティブ・セッションとみなされます。Oracle Databaseではアクティブ・セッションが毎秒サンプリングされ、サンプル・データが共有グローバル領域(SGA)の循環バッファに格納されます。

サンプリングされたセッション・アクティビティには、V$ACTIVE_SESSION_HISTORYビューを使用してアクセスできます。各セッションのサンプルには一連の行と、V$ACTIVE_SESSION_HISTORYビューが含まれ、最後のセッション・サンプルの行から順番に、各アクティブ・セッションに対してサンプルごとに1行が戻されます。アクティブ・セッションのサンプルはSGAの循環バッファに格納されるため、システム・アクティビティが多いほど、格納できるセッション・アクティビティの秒数は短くなります。これは、V$ビューに表示されるセッション・サンプルの期間が、データベース・アクティビティのレベルに完全に依存することを意味します。大規模なシステム・アクティビティ中は、このV$ビューの内容が極端に大きくなる可能性があるため、ディスクにはセッション・サンプルの一部のみが書き込まれます。

アクティブ・セッションのみを取得することで、システム上で許可されるセッション数ではなく、実行される作業に直接関連するサイズで管理可能なデータ・セットが取得されます。アクティブ・セッション履歴(ASH)を使用すると、V$ACTIVE_SESSION_HISTORYビューの現行データとDBA_HIST_ACTIVE_SESS_HISTORYビューの履歴データの両方を検査して詳細な分析を実行でき、通常、ワークロードを再現して追加のパフォーマンス情報をトレースする必要がありません。ASHには、取得されたSQL文ごとの実行計画情報も含まれます。この情報を使用することで、SQLの経過時間に多くの影響を与えているSQL実行部分を特定できます。ASHに存在するデータは、次のように、取得する各種ディメンションでロール・アップできます。

  • SQL文のSQL識別子

  • SQL文の実行に使用されるSQL計画のSQL計画識別子およびハッシュ値

  • SQL実行計画情報

  • オブジェクト数、ファイル数およびブロック数

  • 待機イベント識別子およびパラメータ

  • セッション識別子およびセッション・シリアル番号

  • モジュールおよびアクション名

  • セッションのクライアント識別子

  • サービス・ハッシュ識別子

  • コンシューマ・グループ識別子

指定した期間のこの情報は、ASHレポートに収集できます。

アクティブ・セッション履歴は、Active Data Guardフィジカル・スタンバイ・インスタンスおよびOracle Automatic Storage Management(Oracle ASM)インスタンスでも使用できます。これらのインスタンスでは、現在のセッションのアクティビティが収集されてV$ACTIVE_SESSION_HISTORYビューに表示されますが、ディスクへの書込みは行われません。

関連項目:

  • ASHレポートの詳細は、「サンプル・データの分析」を参照してください

  • Active Data Guardのフィジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください

  • Oracle ASMインスタンスの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

5.1.3 待機イベント統計

待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示すために、サーバー・プロセスまたはスレッドによって増やされる統計です。待機イベント・データにより、ラッチ、バッファおよびI/Oの競合など、パフォーマンスへ悪影響を与える可能性のある症状が明らかになります。

待機イベントに関する高水準の分析を容易にするために、Oracle Databaseでは、イベントが次のクラスにグループ化されます。

  • 管理

  • アプリケーション

  • クラスタ

  • コミット

  • 同時実行性

  • 構成

  • アイドル

  • ネットワーク

  • その他

  • スケジューラ

  • システムI/O

  • ユーザーI/O

待機クラスは、一般に特定待機イベントで問題を解決するために適用される共通の解決策に基づきます。たとえば、排他TXロックは通常はアプリケーション・レベルの問題であり、HWロックは通常は構成の問題です。次のリストに、一部の待機クラスでの一般的な待機イベントの例を示します。

  • Application: 行レベル・ロックまたは明示的ロック・コマンドが原因のロック待機。

  • Commit: コミット後のREDOログ書込み確認の待機。

  • Idle: SQL*Net message from clientなど、セッションが非アクティブであることを示す待機イベント

  • Network: ネットワーク上でのデータ送信の待機。

  • User I/O: ディスクからのブロック読取りの待機。

データベース・インスタンスの待機イベント統計には、バックグラウンド・プロセスとフォアグラウンド・プロセスの両方の統計が含まれます。通常、チューニングは、フォアグラウンド・アクティビティが中心となるため、データベース・インスタンス・アクティビティ全体は、チューニングに役立つように、関連するV$ビュー内でフォアグラウンドとバックグラウンドの統計に分類されます。

V$SYSTEM_EVENTビューには、データベース・インスタンスのフォアグラウンド・アクティビティの待機イベント統計と、データベース・インスタンスの待機イベント統計が表示されます。V$SYSTEM_WAIT_CLASSビューには、待機クラスへの集計後に、これらのフォアグラウンドおよびインスタンス・レベルの待機イベント統計が表示されます。V$SESSION_EVENTおよびV$SESSION_WAIT_CLASSには、セッション・レベルでの待機イベント統計と待機クラス統計が表示されます。

関連項目:

待機イベントの詳細は、『Oracle Databaseリファレンス』を参照してください

5.1.4 セッションおよびシステム統計

V$SYSSTATおよびV$SESSTATビューを使用すると、システム・レベルとセッション・レベルの多数の累積データベース統計にアクセスできます。

関連項目:

V$SYSSTATおよびV$SESSTATビューの詳細は、『Oracle Databaseリファレンス』を参照してください

5.2 データベース統計の解釈

最初にパフォーマンス・データを調査するときは、データベース統計を調べることによって、データについての可能性のある解釈を考察できます。正しい解釈であることを確認するために、別のデータでクロスチェックし、統計またはイベントが本当に関連しているかどうかを確定してください。フォアグラウンド・アクティビティはチューニング可能であるため、バックグラウンド・アクティビティの統計を分析する前に、フォアグラウンド・アクティビティの統計を先に分析することをお薦めします。

次の各項では、データベース・パフォーマンスを計測するために、様々なタイプのデータベース統計を解釈するヒントを説明します。

5.2.1 ヒット率の使用

チューニングを行う場合は、問題の有無を判断するために、比率を計算することが一般的です。そのような率には、バッファ・キャッシュ・ヒット率、ソフト解析率およびラッチ・ヒット率があります。これらの率を、パフォーマンス・ボトルネックがあるかどうかを厳密に判断する識別子として使用しないでください。かわりに、インジケータとして使用します。パフォーマンス・ボトルネックがあるかどうかを識別するには、他の関連するパフォーマンス・データを調べます。バッファ・キャッシュ・ヒット率の計算方法の詳細は、「バッファ・キャッシュ・ヒット率の計算」を参照してください。

5.2.2 時間統計のある待機イベントの使用

インスタンス・レベルでTIMED_STATISTICSをTRUEに設定すると、使用可能な待機カウントの他にイベントの待機時間も収集されます。このデータは、イベントの合計待機時間とデータ収集間の総経過時間を比較する場合に役立ちます。たとえば、待機イベントが2時間の期間のうちのわずか30秒であれば、このイベントが待機時間別に順序付けされるときに最高ランクの待機イベントであったとしても、このイベントを調べることで改善されるパフォーマンスはごくわずかです。ただし、イベントが45分間のうちの30分であれば、そのイベントは調べる価値があります。待機イベントの詳細は、「待機イベント統計」を参照してください。

注意:

初期化パラメータSTATISTICS_LEVELがTYPICALまたはALLに設定されている場合、データベースの時間統計は自動的に収集されます。STATISTICS_LEVELをBASICに設定した場合、時間統計の収集を有効にするには、TIMED_STATISTICSをTRUEに設定する必要があります。STATISTICS_LEVELをBASICに設定すると、多くの自動機能が無効になることに注意してください。この設定はお薦めしません。

DB_CACHE_ADVICE、TIMED_STATISTICSまたはTIMED_OS_STATISTICSを、初期化パラメータ・ファイルか、ALTER_SYSTEMまたはALTER SESSIONを使用して明示的に設定した場合、その値はSTATISTICS_LEVELから導出された値を上書きします。

関連項目:

STATISTICS_LEVEL初期化パラメータについては、『Oracle Databaseリファレンス』を参照してください。

5.2.3 時間統計のない待機イベントの使用

TIMED_STATISTICSがFALSEに設定されている場合、イベントの待機に費やされた時間の長さは使用できません。したがって、各イベントを待機した回数で待機イベントを順序付けることのみ可能です。最大待機回数を持つイベントが潜在的なボトルネックを示すことがありますが、主要なボトルネックとは言えません。この状況は、イベントを何度も待機する場合に発生する可能性がありますが、そのイベントを待機する合計時間は短時間です。逆に、待機回数が少ないイベントは、待機時間が合計待機時間の大きな割合を占めている場合には、大きなボトルネックであることがあります。比較のために使用する待機時間がなければ、調査する価値がある待機イベントかどうかの判断は困難です。

5.2.4 アイドル待機イベントの使用

Oracle Databaseでは、いくつかの待機イベントを使用して、Oracleサーバー・プロセスがアイドル状態であるかどうかを示します。一般に、これらのイベントはパフォーマンスの問題を調べるときは有効でなく、待機イベントを調べるときは無視する必要があります。

5.2.5 データベース統計とその他の要因の比較

統計を検証する場合、統計に価値があるかどうかに影響を与える他の要因を考慮することが重要です。そのような要因には、ユーザー負荷やハードウェア能力があります。45分間のうちの30分間が待機時間であったイベントでも、システム上に2000人のユーザーがいて、ホスト・ハードウェアが64ノード・コンピュータであった場合はパフォーマンスの問題とはみなされないことがあります。

5.2.6 計算済統計の使用

計算済統計(割合、トランザクションについて正規化された統計、比率など)を解釈する場合は、計算済統計を実際の統計カウントで検証することが重要です。通常、統計カウントが少ないと異常な比率は軽減して考慮されるため、この比較により、導出された割合が実際に重要かどうかを確認できます。たとえば、最初の調査で、ソフト解析率50%は一般に潜在的なチューニング領域を示します。ただし、データ収集期間にハード解析が1つとソフト解析が1つのみあった場合、パフォーマンスに影響していないことを統計カウントが示していても、ソフト解析率は50%になります。この場合、生の統計カウントが低いため、比率は重要ではありません。