2 Oracle Databaseのパフォーマンス・メソッド

パフォーマンスの改善は反復プロセスです。1つ目のボトルネック(リソースの競合が最も激しいポイント)を解消してもすぐにパフォーマンスの向上につながらず、他のボトルネックがシステムに対してさらに大きな影響を与えていることが発見される場合があります。変更によってパフォーマンスを改善するには、その最初の手順としてパフォーマンスの問題を正確に診断する必要があります。

一般的にパフォーマンスの問題は、スループット(指定された時間内に完了できる作業量)の不足、またはユーザーやジョブのレスポンス時間(指定されたワークロードを完了するまでの時間)、あるいはその両方によって生じます。問題の原因は特定のアプリケーションのモジュールである場合も、システム全体である場合もあります。

データベースまたはオペレーティング・システムの統計を確認する前に、システム・ユーザーおよびアプリケーションの担当者からフィードバックを収集することが不可欠です。このフィードバックは、パフォーマンス目標の決定に役立ちます。パフォーマンスの改善状況は、システムの統計によってではなく、ビジネス目標の観点で測定されます。

Oracleパフォーマンス・メソッドは、パフォーマンスの目標が達成されるか達成不可能と判断されるまで適用できます。このプロセスは反復的なため、調査の中にはシステム・パフォーマンスにほとんど影響しないものもあります。重大なボトルネックを迅速に正確に特定するには、時間と経験が必要です。自動データベース診断モニター(ADDM)ではOracleパフォーマンス・メソッドを実装して統計を分析し、パフォーマンス上の重大な問題が自動で診断されます。ADDMを使用すると、システムのパフォーマンスの向上に必要な時間が大幅に短縮されるため、このガイドでもこの方法を利用します。

この章ではOracle Databaseパフォーマンス・メソッドを説明しています。次の項で構成されています。

• 自動ワークロード・リポジトリを使用したデータベース統計の収集

• Oracleパフォーマンス・メソッドの使用

• データベースで検出されるパフォーマンスにおける一般的な問題

2.1 自動ワークロード・リポジトリを使用したデータベース統計の収集

データベース統計ではデータベースの負荷のタイプ、およびデータベースで使用する内部および外部リソースに関する情報が提供されます。ADDMを使用したデータベースでパフォーマンスの問題を正確に診断するには、統計が使用可能である必要があります。

累積統計は、ブロック読取り数などの数です。Oracle Databaseはシステム、セッションおよび個別のSQL文の累積統計のタイプを生成します。Oracle Databaseはセグメントおよびサービスについての累積統計の追跡もします。自動ワークロード・リポジトリ(AWR)では、データベースの問題検出および自己チューニングのために、パフォーマンス統計の収集、処理および保持によりデータベースの統計採取が自動的に行われます。

デフォルトでは、データベースが1時間ごとに統計を採取してAWRスナップショットを作成します。AWRスナップショットは、パフォーマンス比較に使用される特定の時間に関するデータのセットです。スナップショットで取得したデルタ値は、時間ごとの各統計に対する変更を示します。AWRで採取した統計はメモリーから問い合せます。採取したデータは、レポートおよびビューで表示できます。

AWRでは次の初期化パラメータを使用できます。

• STATISTICS_LEVEL

  AWRによる統計の収集を有効にするには、このパラメータをTYPICAL(デフォルト)またはALLに設定します。STATISTICS_LEVELをBASICに設定すると、AWRを含む多くのデータベース機能が無効化されるため、この方法はお薦めしません。

• CONTROL_MANAGEMENT_PACK_ACCESS

  自動データベース診断監視を有効にするには、DIAGNOSTIC+TUNING(デフォルト)またはDIAGNOSTICに設定します。CONTROL_MANAGEMENT_PACK_ACCESSをNONEに設定すると、ADDMを含む多くのデータベース機能が無効化されるため、この方法はお薦めしません。

参照:

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

• CONTROL_MANAGEMENT_PACK_ACCESS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

AWRで収集および処理されるデータベース統計には、次のものがあります。

• 時間モデル統計

• 待機イベント統計

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

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

• 高負荷SQL統計

2.1.1 時間モデル統計

時間モデル統計はデータベース内での操作タイプによる経過時間を測定します。最も重要な時間モデル統計はデータベース時間(DB時間)です。DB時間は、フォアグラウンド・セッションによってデータベース・コール内で経過した合計時間を表し、またインスタンスのワークロードの合計の指標にもなります。図2-1で説明されているように、データベース時間はアプリケーションのユーザー・レスポンス時間全体の一部を構成します。

図2-1 すべてのユーザー・レスポンス時間のDB時間

「図2-1 すべてのユーザー・レスポンス時間のDB時間」の説明

セッションは、データベースに対する現在のユーザー・ログインの状況を示す、データベース・インスタンス・メモリー内の論理エンティティです。データベース時間は、CPU時間とすべてのアクティブ・セッション(アイドル状態ではないセッション)の待機時間を集計することで算出されます。データベース要求については、CPU時間は要求の処理にかかった合計時間を示し、待機時間は様々なデータベース・インスタンス・リソースの合計待機時間を示します。DB時間には、クライアント・プロセスにかかった時間のみが含まれ、PMONなどのバックグラウンド・プロセスにかかった時間は含まれません。

たとえば、ユーザー・セッションには、オンライン書店で実行されるオンライン・トランザクション(図2-2に示すアクションで構成される)などがあります。

図2-2 ユーザー・トランザクションのDB時間

「図2-2 ユーザー・トランザクションのDB時間」の説明

1. 作者別の書籍の問合せ

   ユーザーは特定の作者の書籍の検索を実行します。このアクションでは、アプリケーションにより、作者別の書籍のデータベースに対して問合せが実行されます。

2. 問合せの結果を参照

   ユーザーは、戻された作者別の書籍のリストを参照し、ユーザー・レビューおよび在庫状況などの詳細にアクセスします。このアクションでは、アプリケーションにより追加のデータベース問合せが実行されます。

3. カートにアイテムを追加

   書籍の詳細を参照した後、ユーザーは書籍の1つをショッピング・カートに追加することを決定します。このアクションでは、アプリケーションによりデータベースが呼び出され、ショッピング・カートが更新されます。

4. チェックアウト

   以前に商品を購入したときに書店のWebサイトに保存されていた、住所および支払い情報をユーザーが確認し、取引を完了します。このアクションによってアプリケーションは様々なデータベース操作を行い、ユーザー情報の取得、新しい注文の追加、在庫情報の更新、および電子メールの認証を実行します。

これらの各先行アクションでは、ユーザーは図2-2の下矢印で示されているとおりにデータベースに対し要求を行います。データベースが要求を処理するためにかかるCPU時間およびデータベースの待機にかかる待機時間はDB時間と呼ばれます(色付きの部分)。要求が完了すると、上矢印で示されているとおりに、結果がユーザーに戻されます。上矢印および下矢印の間の領域は要求を処理するための合計ユーザー・レスポンス時間を表し、図2-1で示されるようにDB時間以外のその他のコンポーネントが含まれます。

注意:

DB時間は、インスタンスの開始時から累積的に測定されます。DB時間ではアイドル状態でないすべてのユーザー・セッションの時間が集計されるため、DB時間がインスタンス開始後の経過時間を超える場合があります。たとえば、5分間実行されたインスタンスについて4つのアクティブ・セッションがあると、累積DB時間は20分になります。

データベースのチューニングの目的は、DB時間を短縮することです。チューニングすることにより、アプリケーションでのユーザーのトランザクションの全体のレスポンス時間が向上します。

2.1.2 待機イベント統計

セッションがあるイベントの完了を待機してから処理を続行する必要があったことを示すため、待機イベントはセッションによって増分されます。ユーザー要求を処理している間にセッションが待機する必要がある場合、データベースは事前定義された待機イベントのセットの1つを使用して、その待機を記録します。次に、このイベントは、「ユーザーI/O」および「ネットワーク」などの待機クラスに分類されます。待機イベント・データにより、ラッチ、バッファ、I/Oの競合など、パフォーマンスへ悪影響を与える可能性のある症状が明らかになります。

参照:

• 『Oracle Databaseパフォーマンス・チューニング・ガイド』

• 『Oracle Databaseリファレンス』

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

データベースの多数の累積統計はシステムおよびセッション・レベルで使用可能です。これらの統計の一部はAWRで収集されます。

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

アクティブ・セッション履歴(ASH)統計はデータベースのセッション・アクティビティのサンプルです。データベースは毎秒サンプリングされ、システム・グローバル領域(SGA)の循環バッファに格納されます。データベースに接続してCPUを使用しているセッションまたはアイドル待機クラスに属していないイベントを待っているセッションは、アクティブ・セッションと認識されます。アクティブ・セッションのみ取得すると、管理可能なデータのセットが示されます。データのサイズは、データベースで実行可能なセッション数ではなく、実行中の作業に直接関連します。

「時間モデル統計」で説明したDB時間の例を使用すると、書店のWebサイトで行ったオンライン・トランザクションからセッション・アクティビティのサンプルが収集されます。これは、図2-3の横矢印の下の縦線で示されています。

図2-3 アクティブ・セッション履歴

「図2-3 アクティブ・セッション履歴」の説明

細い縦線は、ASH統計に取得されない非アクティブ・セッション・アクティビティのサンプルを表しています。太い縦線は次の時点で取得されたアクティブ・セッションのサンプルを表しています。

• 7:38、作者別の書籍を問合せ中

• 7:42、ユーザーが問合せ結果を参照中

• 7:50、書籍の1つをショッピング・カートに追加

• 7:52、チェックアウト処理中

表2-1に、サンプリングされるセッションID(SID)、モジュール、SQL ID、セッション状態、および待機イベントの例とともに、アクティブ・セッションに対して収集されたASH統計を示します。

表2-1 アクティブ・セッション履歴

時間	SID	モジュール	SQL ID	状態	イベント
7:38	213	作者別の書籍	qa324jffritcf	待機中	db file順次読取り
7:42	213	レビューIDの取得	aferv5desfzs5	CPU	N/A
7:50	213	カートにアイテムを追加	hk32pekfcbdfr	待機中	バッファ・ビジー待機
7:52	213	チェックアウト	abngldf95f4de	待機中	ログ・ファイルの同期化

2.1.5 高負荷SQL統計

経過時間およびCPU時間などのリソースの大部分を消費するSQL文は、システムにとって非常に大きな負荷となります。

2.2 Oracleパフォーマンス・メソッドの使用

Oracleのパフォーマンス・メソッドを使用したパフォーマンス・チューニングは、データベースのボトルネックの識別と解消、および効率的なSQL文の開発によって行われます。データベースのチューニングは、事前および事後の2つのフェーズで構成されます。

事前チューニングのフェーズで、ADDM分析および検出結果の確認、リアルタイムでのデータベースのパフォーマンスの監視、およびアラートへの対応などのチューニング・タスクを、データベースのメンテナンス・ルーチンの一部として日常的に実行する必要があります。

短期的に発生するパフォーマンスの問題、または時間の経過によるデータベースのパフォーマンスの低下などの問題がユーザーから報告された場合は、事後チューニングのフェーズで対応する必要があります。

SQLチューニングは、高負荷SQL文の効率を識別、チューニングおよび向上させる反復プロセスです。

Oracleパフォーマンス・メソッドの適用には、次の操作が含まれます。

• 事前チューニングの準備の実行(「データベースのチューニング準備」を参照)

• データベースの定期的な事前チューニング(「データベースの事前のチューニング」を参照)

• パフォーマンスの問題がユーザーによってレポートされた場合のデータベースの事後チューニング(「データベースの事後チューニング」を参照)

• 高負荷のSQL文の識別、チューニングおよび最適化(「SQL文のチューニング」を参照)

データベースのパフォーマンスを改善するために、これらの原則を繰り返して適用する必要があります。

2.2.1 データベースのチューニング準備

この項ではデータベースのチューニング前に行う必要のある手順をリストして説明します。

チューニングのためにデータベースを準備する手順::

1. ユーザーからフィードバックを取得します。

   パフォーマンス・プロジェクトの有効範囲、最終的なパフォーマンスの目標、および将来のパフォーマンス目標を決定します。このプロセスは今後の容量計画にとって重要です。

2. ユーザーのパフォーマンスに影響するすべてのシステムのオペレーティング・システムをチェックします。

   ハードウェアまたはオペレーティング・システム・リソースが完全に使用されていることを確認します。発生する可能性のある問題として超過したリソースをリストし、後で分析します。さらに、すべてのハードウェアが正常に機能していることを確認します。

3. STATISTICS_LEVEL初期化パラメータがTYPICAL(デフォルト)またはALLに設定されていることを確認し、AWRおよびADDMを含むOracle Databaseの自動パフォーマンス・チューニング機能を有効にします。

4. CONTROL_MANAGEMENT_PACK_ACCESS初期化パラメータをDIAGNOSTIC+TUNING(デフォルト)またはDIAGNOSTICに設定し、ADDMを有効にします。

参照:

• AWRの構成方法については、「自動ワークロード・リポジトリを使用したデータベース統計の収集」を参照してください。

• 「自動データベース診断モニターの構成」

2.2.2 データベースの事前のチューニング

この項ではデータベースの定期的なチューニングに必要な事前の手順をリストして説明します。これらの手順は、Oracle Databaseの日常的なメンテナンスの一部として実行してください。チューニング・プロセスは、パフォーマンスの目標に達するか、他の制約により不可能になるまで繰り返します。

データベースの事前チューニング手順:

1. 「データベースのパフォーマンスの自動監視」の説明に従って、ADDMの検出結果を確認します。

   ADDMは、「データベースで検出されるパフォーマンスにおける一般的な問題」のほとんどが含まれるデータベースに関するパフォーマンスの問題を自動的に検出し、報告します。結果は、Oracle Enterprise Manager Cloud Control (Cloud Control)のデータベースのホームページにADDMの検出結果として表示されます。これらの結果を確認することにより、注意が必要なパフォーマンスの問題を迅速に識別することが可能となります。

2. 「データベースのパフォーマンスの自動監視」の説明に従って、ADDMの検出結果を確認します。

   ADDMの結果により、パフォーマンスの問題の影響を軽減する推奨事項のリストが得られます。推奨事項の実装により、推奨された変更が適用されデータベースのパフォーマンスが改善されます。

3. 「データベースのパフォーマンスのリアルタイムの監視」の説明に従って、データベースのパフォーマンスの問題をリアルタイムで監視します。

   Cloud Controlのパフォーマンス・ページでは、リアルタイムのパフォーマンスの問題を識別し、対応できます。適切なページにドリルダウンすると、次のADDM分析の実行を待つことなく、リアルタイムでデータベースのパフォーマンスの問題を識別および解決できます。

4. 「パフォーマンス・アラートの監視」の説明に従って、パフォーマンスに関連するアラートに対応します。

   Cloud Controlのデータベースのホームページでは、データベースによって生成されたパフォーマンス関連のアラートが表示されます。通常は、これらのアラートが示す問題を解決することで、データベースのパフォーマンスが向上します。

5. 変更によって期待した結果が得られたことを検証します。また、ユーザーに対するデータベースのパフォーマンスが向上したかどうかを確認します。

2.2.3 データベースの事後チューニング

この項では、ユーザー・フィードバックに基づいたデータベースのチューニングに必要な手順をリストして説明します。このチューニングの手順は事後と考えられます。ユーザーによりパフォーマンスの問題がレポートされたときに、この手順を定期的に実行します。

データベースの事後チューニング手順:

1. パフォーマンスの問題がユーザーから報告された場合、「データベースのパフォーマンスの手動監視」の説明に従ってADDMを手動で実行し、現在のデータベースのパフォーマンスおよびパフォーマンスの履歴を診断します。

   この方法で、次のADDM分析の前に現在のデータベースのパフォーマンスを分析したり、システムの定期的な監視を行っていないときに過去のデータベースのパフォーマンスを分析することができます。

2. 「一時的なパフォーマンスの問題の解決」の説明に従って、一時的なパフォーマンスの問題を解決します。

   アクティブ・セッション履歴(ASH)レポートでは、短期間でADDM分析に表示されないデータベースの一時的なパフォーマンスの問題を分析できます。

3. 「時間の経過によるパフォーマンスの低下」の説明に従って、時間が経つにつれパフォーマンスが低下する問題を解決します。

   自動ワークロード・リポジトリ(AWR)期間の比較レポートで、2つの期間のデータベースのパフォーマンスを比較でき、特定の期間から他の期間にかけて発生するパフォーマンスの低下を解決します。

4. 行った変更によって期待した結果が得られたことを検証します。また、ユーザーに対するデータベースのパフォーマンスが向上したかどうかを確認します。

5. パフォーマンスの目標に達するか、他の制約により不可能になるまでこれらの手順を繰り返します。

2.2.4 SQL文のチューニング

この項では高負荷SQL文の識別、チューニングおよび最適化に必要な手順をリストして説明します。

SQL文のチューニング手順:

1. 「上位SQLに基づく高負荷SQL文の識別」の説明に従って高負荷SQL文を識別します。

   ADDMの検出結果および上位SQLセクションを使用して、最大の競合の原因となる高負荷SQL文を識別します。

2. 「SQL文のチューニング」の説明に従って、高負荷SQL文をチューニングします。

   SQLチューニング・アドバイザを使用して高負荷SQL文の効率を向上できます。

3. 「データ・アクセス・パスの最適化」の説明に従って、データ・アクセス・パスを最適化します。

   マテリアライズド・ビュー、マテリアライズド・ビュー・ログ、およびSQLアクセス・アドバイザを使用した特定のワークロードに対する索引の該当セットを作成して、データ・アクセス・パスのパフォーマンスを最適化できます。

4. SQLパフォーマンス・アナライザを使用して、SQLチューニングおよびその他のシステム変更に対するSQLパフォーマンスの影響を分析します。

   SQLパフォーマンス・アナライザの使用方法は、『Oracle Database Testingガイド』を参照してください。

5. すべての高負荷SQL文の効率が最大化されるまでこれらの手順を繰り返してチューニングを行います。

2.3 データベースで検出されるパフォーマンスにおける一般的な問題

この項ではデータベース内で検出された共通のパフォーマンスの問題をリストして説明します。Oracleパフォーマンス・メソッドに従うと、Oracle Databaseインスタンスでのこれらの問題を回避できます。問題がある場合は、「Oracleパフォーマンス・メソッドの使用」で説明されているように、Oracleパフォーマンス・メソッドの手順を繰り返すか、またはこれらの問題に対処する項を参照してください。

• CPUのボトルネック

  CPUの限界のためにアプリケーションのパフォーマンスが低下していますか。「データベースのパフォーマンスの自動監視」で説明されているように、CPUがボトルネックとなって発生するパフォーマンスの問題は、ADDMにより診断されます。また、「CPU使用率の監視」で説明されているように、Cloud Controlの「パフォーマンス」ページでもCPUのボトルネックを識別できます。

• メモリー構造のサイズ不足

  システム・グローバル領域(SGA)、プログラム・グローバル領域(PGA)、バッファ・キャッシュなどのOracleのメモリー構造は適切なサイズですか。メモリー構造のサイズが小さいことにより発生するパフォーマンスの問題は「データベースのパフォーマンスの自動監視」で説明されているようにADDMにより診断されます。また、「メモリー使用率の監視」で説明されているようにCloud Controlの「パフォーマンス」ページを使用してメモリー使用率の問題を識別できます。

• I/O容量の問題

  I/Oサブシステムは正常に動作していますか。「データベースのパフォーマンスの自動監視」で説明されているように、I/Oの能力の問題によるパフォーマンスの問題はADDMにより診断されます。また、「ディスクI/O使用率の監視」の説明に従って、Cloud Controlの「パフォーマンス」ページを使用してディスクI/Oの問題を識別することもできます。

• アプリケーションによるOracle Databaseの非効率的な使用

  アプリケーションが非効率的にOracle Databaseを使用していますか。データベースへの新規接続を何度も行ったり、SQL解析を過度に行ったり、少量のデータで過度の競合が発生(アプリケーション・レベルのブロック競合とも呼ばれます)したりすると、アプリケーションのパフォーマンスが大幅に低下します。「データベースのパフォーマンスの自動監視」で説明されているように、アプリケーションによるOracleデータベースの使用が非効率的なために発生したパフォーマンスの問題は、ADDMにより診断されます。また、「ユーザー・アクティビティの監視」の説明に従って、Cloud Controlの「パフォーマンス」ページを使用して、SQL、セッション、サービス、モジュールおよびアクションなどの様々なディメンションでトップ・アクティビティを監視できます。

• 同時実行による問題

  同時アクティビティが多数発生し、データベースのパフォーマンスが低下していますか。同時アクティビティが多数発生すると、ロックまたはバッファ・キャッシュの待機の形で明示される共有リソースの競合が起こります。「データベースのパフォーマンスの自動監視」で説明されているように、同時実行によるパフォーマンスの問題はADDMにより診断されます。また、「上位セッションの監視」の説明に従って、同時実行による問題をCloud Controlの「上位セッション」を使用して識別することもできます。

• データベース構成の問題

  理想的なパフォーマンス・レベルになるようにデータベースが最適な構成になっていますか。たとえば、ログ・ファイルのサイズ設定の異常、アーカイブの問題、過度のチェックポイント、非効率的なパラメータ設定などの徴候はありませんか。「データベースのパフォーマンスの自動監視」で説明されているように、データベースの構成の問題が原因となっているパフォーマンスの問題は、ADDMにより診断されます。

• 短期間のパフォーマンスの問題

  短期間または断続的に発生するパフォーマンスの問題に関してユーザーが不満を持っていませんか。AWRによって作成されるスナップショットの間隔によって、短期間のパフォーマンスの問題がADDMで取得されない可能性があります。短期間のパフォーマンスの問題は、「一時的なパフォーマンスの問題の解決」の説明に従って、アクティブ・セッション履歴レポートを使用して識別できます。

• 時間の経過によるデータベースのパフォーマンスの低下

  時間が経過するにつれてデータベースのパフォーマンスが低下している徴候はありませんか。たとえば、データベースの動作が6か月前と異なるとユーザーが感じていませんか。AWR期間比較レポートを生成して、構成設定、ワークロード・プロファイルおよび統計の差を、パフォーマンスが安定していた期間とパフォーマンスが低下していた期間で比較して識別します。「時間の経過によるパフォーマンスの低下」で説明されているように、この操作によりパフォーマンスの低下の原因を識別できます。

• 効率の悪いまたは負荷が大きいSQL文

  システムに影響を与える過度のシステム・リソースを使用するSQL文はありませんか。高負荷SQL文によって発生するパフォーマンスの問題は、データベースのパフォーマンスの自動監視およびADDMの検出結果に基づく高負荷SQL文の識別で説明されているようにADDMにより診断されます。また、「上位SQLに基づく高負荷SQL文の識別」で説明されているように、Cloud Controlの上位SQLを使用することで高負荷SQL文を識別できます。これらを識別すると、「SQL文のチューニング」で説明されているように、SQLチューニング・アドバイザを使用して高負荷SQL文をチューニングできます。

• オブジェクト競合

  連続してアクセスされるためボトルネックの原因になっているデータベース・オブジェクトはありませんか。オブジェクト競合によって発生するパフォーマンスの問題は「データベースのパフォーマンスの自動監視」で説明されているようにADDMによって診断されます。また、「データ・アクセス・パスの最適化」の説明に従って、SQLアクセス・アドバイザを使用してこれらのオブジェクトへのデータ・アクセス・パスを最適化できます。

• SQL文のチューニング後の予期しないパフォーマンスの低下

  チューニング後に、SQL文のパフォーマンスが低下していませんか。SQL文をチューニングすると、SQL文の実行計画の変更の原因となり、SQLのパフォーマンスに大きく影響します。変更はSQLパフォーマンスの向上につながる場合もあります。場合によっては、システム変更によってSQL文が低下し、SQLパフォーマンスが低下することがあります。

  本番システムで変更する前に、SQLパフォーマンス・アナライザを使用して、テスト・システムでチューニングしたSQLの影響を分析できます。この機能によって、次によるSQLワークロードへのシステム変更の影響を予想できます。

  • 変更前後のパフォーマンスの測定

  • パフォーマンスの変更を説明するレポートの生成

  • 低下または向上するSQL文の識別

  • 低下するSQL文ごとのチューニング推奨の提供

  • 適切な場合のチューニング推奨の実装

  参照:

  SQLパフォーマンス・アナライザの使用方法の詳細は、『Oracle Database Testingガイド』を参照してください