| Oracle® Database 2日でパフォーマンス・チューニング・ガイド 11gリリース2(11.2) B56313-03 |
|
 前 |
 次 |
パフォーマンスの改善は反復プロセスです。1つ目のボトルネック(リソースの競合が最も激しいポイント)を解消してもすぐにパフォーマンスの向上につながらず、他のボトルネックがシステムに対してさらに大きな影響を与えていることが発見される場合があります。このため、Oracleのパフォーマンス・メソッドは反復的です。変更によってパフォーマンスを改善するには、その最初の手順としてパフォーマンスの問題を正確に診断する必要があります。
一般的にパフォーマンスの問題は、スループット(指定された時間内に完了できる作業量)の不足、またはユーザーやジョブのレスポンス時間(指定されたワークロードを完了するまでの時間)の異常、あるいはその両方によって生じます。問題の原因は特定のアプリケーションのモジュールである場合も、システム全体である場合もあります。
データベースまたはオペレーティング・システムの統計を確認する前に、システムおよびアプリケーションのユーザーからフィードバックを収集することが不可欠です。このフィードバックは、パフォーマンス目標の決定に役立ちます。パフォーマンスの改善状況は、システムの統計によってではなく、ビジネス目標の観点で測定されます。
Oracleパフォーマンス・メソッドは、パフォーマンスの目標が達成されるか達成不可能と判断されるまで適用できます。このプロセスは反復的なため、調査の中にはシステム・パフォーマンスにほとんど影響しないものもあります。重大なボトルネックを迅速に正確に特定するには、時間と経験が必要です。自動データベース診断モニター(ADDM)ではOracleパフォーマンス・メソッドを実装して統計を分析し、パフォーマンス上の重大な問題が自動で診断されます。ADDMを使用すると、システムのパフォーマンスの向上に必要な時間が大幅に短縮されるため、このガイドでもこの方法を利用します。
この章ではOracle Databaseパフォーマンス・メソッドを説明しています。次の項で構成されています。
データベース統計ではデータベースの負荷のタイプ、およびデータベースで使用する内部および外部リソースに関する情報が提供されます。ADDMを使用したデータベースでパフォーマンスの問題を正確に診断するには、統計が使用可能である必要があります。
累積統計は、ブロック読取り数などの数です。Oracle Databaseはシステム、セッションおよび個別のSQL文の累積統計のタイプを生成します。Oracle Databaseはセグメントおよびサービスについての累積統計の追跡もします。自動ワークロード・リポジトリ(AWR)では、データベースの問題検出および自己チューニングのために、パフォーマンス統計の収集、処理および保持によりデータベースの統計採取が自動的に行われます。
デフォルトでは、データベースが1時間ごとに統計を採取してAWRスナップショットを作成します。AWRスナップショットは、パフォーマンス比較に使用される特定の時間に関するデータのセットです。スナップショットで取得したデルタ値は、時間ごとの各統計に対する変更を示します。AWRで採取した統計はメモリーから問い合せます。採取したデータは、レポートおよびビューで表示できます。
AWRでは次の初期化パラメータを使用できます。
STATISTICS_LEVEL
AWRによる統計の収集を有効にするには、このパラメータをTYPICAL(デフォルト)またはALLに設定します。STATISTICS_LEVELをBASICに設定すると、AWRを含む多くのデータベース機能が無効化されるため、この方法はお薦めしません。この初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
CONTROL_MANAGEMENT_PACK_ACCESS
自動データベース診断監視を有効にするには、DIAGNOSTIC+TUNING(デフォルト)またはDIAGNOSTICに設定します。CONTROL_MANAGEMENT_PACK_ACCESSをNONEに設定すると、ADDMを含む多くのデータベース機能が無効化されるため、この方法はお薦めしません。この初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
AWRで収集および処理されるデータベース統計には、次のものがあります。
時間モデル統計はデータベース内での操作タイプによる経過時間を測定します。最も重要な時間モデル統計はデータベース時間(DB時間)です。データベース時間は、フォアグラウンド・セッションによってデータベース・コール内で経過した合計時間を表し、またインスタンスのワークロードの合計の指標にもなります。図2-1で説明されているように、データベース時間はアプリケーションのユーザー・レスポンス時間全体の一部を構成します。
セッションは、データベース・インスタンス・メモリー内の論理的なエンティティで、データベースに対する現在のユーザー・ログインの状態を表します。データベース時間は、CPU時間とすべてのアクティブ・セッション(アイドル状態ではないセッション)の待機時間を集計することで算出されます。データベース要求については、CPU時間は要求の処理にかかった合計時間を示し、待機時間は様々なデータベース・インスタンス・リソースの合計待機時間を示します。DB時間には、クライアント・プロセスにかかった時間のみが含まれ、PMONなどのバックグラウンド・プロセスにかかった時間は含まれません。
たとえば、ユーザー・セッションには、オンライン書店で実行されるオンライン・トランザクション(図2-2に示すアクションで構成される)などがあります。
作者別の書籍の問合せ
ユーザーは特定の作者の書籍の検索を実行します。このアクションでは、アプリケーションにより、作者別の書籍のデータベースに対して問合せが実行されます。
問合せの結果を参照
ユーザーは、戻された作者別の書籍のリストを参照し、ユーザー・レビューおよび在庫状況などの詳細にアクセスします。このアクションでは、アプリケーションにより追加のデータベース問合せが実行されます。
カートにアイテムを追加
書籍の詳細を参照した後、ユーザーは書籍の1つをショッピング・カートに追加することを決定します。このアクションでは、アプリケーションによりデータベースが呼び出され、ショッピング・カートが更新されます。
チェックアウト
以前に商品を購入したときに書店のWebサイトに保存されていた、住所および支払い情報をユーザーが確認し、取引を完了します。このアクションでは、アプリケーションにより様々なデータベース操作が行われ、ユーザー情報の取得、新しい注文の追加、在庫情報の更新および電子メールの認証が実行されます。
これらの各先行アクションでは、ユーザーは図2-2の下矢印で示されているとおりにデータベースに対し要求を行います。データベースが要求を処理するためにかかるCPU時間およびデータベースの待機にかかる待機時間はDB時間と呼ばれます(色付きの部分)。要求が完了すると、上矢印で示されているとおりに、結果がユーザーに戻されます。上矢印および下矢印の間の領域は要求を処理するための合計ユーザー・レスポンス時間を表し、図2-1で示されるようにDB時間以外のその他のコンポーネントが含まれます。
|
注意: DB時間は、インスタンスの開始時から累積的に測定されます。DB時間ではアイドル状態でないすべてのユーザー・セッションの時間が集計されるため、DB時間がインスタンス開始後の経過時間を超える場合があります。たとえば、5分間実行されたインスタンスについて4つのアクティブ・セッションがあると、累積DB時間は20分になります。 |
データベースのチューニングの目的は、データベース時間を短縮することです。チューニングすることにより、アプリケーションでのユーザーのトランザクションの全体のレスポンス時間が向上します。
セッションがあるイベントの完了を待機してから処理を続行する必要があったことを示すため、待機イベントはセッションによって増分されます。ユーザー要求を処理している間にセッションが待機する必要がある場合、データベースは事前定義された待機イベントのセットの1つを使用して、その待機を記録します。次に、このイベントは、「ユーザーI/O」および「ネットワーク」などの待機クラスに分類されます。待機イベント・データにより、ラッチ、バッファ、I/Oの競合など、パフォーマンスへ悪影響を与える可能性のある症状が明らかになります。
|
参照:
|
アクティブ・セッション履歴(ASH)統計はデータベースのセッション・アクティビティのサンプルです。データベースは毎秒サンプリングされ、システム・グローバル領域(SGA)の循環バッファに格納されます。データベースに接続してCPUを使用しているセッションまたはアイドル待機クラスに属していないイベントを待っているセッションは、アクティブ・セッションと認識されます。アクティブ・セッションのみ取得すると、管理可能なデータのセットが示されます。データのサイズは、データベースで実行可能なセッション数ではなく、実行中の作業に直接関連します。
「時間モデル統計」で説明したDB時間の例を使用すると、書店のWebサイトで行ったオンライン・トランザクションからセッション・アクティビティのサンプルが収集されます。これは、図2-3の横矢印の下の縦線で示されています。
細い縦線は、ASH統計に取得されない非アクティブ・セッション・アクティビティのサンプルを表しています。太い縦線は次の時点で取得されたアクティブ・セッションのサンプルを表しています。
7:38、作者別の書籍を問合せ中
7:42、ユーザーが問合せ結果を参照中
7:50、書籍の1つをショッピング・カートに追加
7:52、チェックアウト処理中
表2-1に、サンプリングされるセッションID(SID)、モジュール、SQL ID、セッション状態、および待機イベントの例とともに、アクティブ・セッションに対して収集されたASH統計を示します。
Oracleのパフォーマンス・メソッドを使用したパフォーマンス・チューニングは、データベースのボトルネックの識別と解消、および効率的なSQL文の開発によって行われます。データベースのチューニングは、事前および事後の2つのフェーズで構成されます。
事前チューニングのフェーズで、ADDM分析および検出結果の確認、リアルタイムでのデータベースのパフォーマンスの監視、およびアラートへの対応などのチューニング・タスクを、データベースのメンテナンス・ルーチンの一部として日常的に実行する必要があります。
短期的に発生するパフォーマンスの問題、または時間の経過によるデータベースのパフォーマンスの低下などの問題がユーザーから報告された場合は、事後チューニングのフェーズで対応する必要があります。
SQLチューニングは、高負荷SQL文の効率を識別、チューニングおよび向上させる反復プロセスです。
Oracleパフォーマンス・メソッドの適用には、次の操作が含まれます。
事前チューニングの準備の実行(「データベースのチューニング準備」を参照)
データベースの定期的な事前チューニングの実行(「データベースの事前のチューニング」を参照)
パフォーマンスの問題がユーザーによってレポートされた場合のデータベースの事後チューニングの実行(「データベースの事後チューニング」を参照)
高負荷のSQL文の識別、チューニングおよび最適化(「SQL文のチューニング」を参照)
データベースのパフォーマンスを改善するために、これらの原則を繰り返して適用する必要があります。
この項ではデータベースのチューニング前に行う必要のある手順をリストして説明します。
ユーザーからフィードバックを取得します。
パフォーマンス・プロジェクトの有効範囲、最終的なパフォーマンスの目標、および将来のパフォーマンス目標を決定します。このプロセスは今後の容量計画にとって重要です。
ユーザーのパフォーマンスに影響するすべてのシステムのオペレーティング・システムをチェックします。
ハードウェアまたはオペレーティング・システム・リソースが完全に使用されていることを確認します。発生する可能性のある問題として超過したリソースをリストし、後で分析します。さらに、すべてのハードウェアが正常に機能していることを確認します。
Oracle Databaseの自動パフォーマンス・チューニング機能(AWR、ADDMなど)が有効になるようにSTATISTICS_LEVEL初期化パラメータがTYPICAL(デフォルト)またはALLに設定されていることを確認します。
CONTROL_MANAGEMENT_PACK_ACCESS初期化パラメータをDIAGNOSTIC+TUNING(デフォルト)またはDIAGNOSTICに設定し、ADDMを有効にします。
この項ではデータベースの定期的なチューニングに必要な事前の手順をリストして説明します。これらの手順は、Oracle Databaseの日常的なメンテナンスの一部として実行してください。チューニング・プロセスは、パフォーマンスの目標に達するか、他の制約により不可能になるまで繰り返します。
ADDMの結果を確認します(第3章「データベースのパフォーマンスの自動監視」を参照)。
ADDMは、「Oracle Databaseで検出されるパフォーマンスにおける一般的な問題」のほとんどが含まれるデータベースに関するパフォーマンスの問題を自動的に検出し、報告します。この結果は、Oracle Enterprise Manager(Enterprise Manager)のデータベースのホームページでADDMの結果として表示されます。これらの結果を確認することにより、注意が必要なパフォーマンスの問題を迅速に識別することが可能となります。
ADDMの推奨事項を実装します(第3章「データベースのパフォーマンスの自動監視」を参照)。
ADDMの結果により、パフォーマンスの問題の影響を軽減する推奨事項のリストが得られます。推奨事項の実装により、推奨された変更が適用されデータベースのパフォーマンスが改善されます。
データベースのパフォーマンスの問題をリアルタイムで監視します(第4章「リアルタイムなデータベースのパフォーマンスの監視」を参照)。
Enterprise Managerの「パフォーマンス」ページでは、リアルタイムのパフォーマンスの問題を識別し、対応できます。適切なページにドリルダウンすると、次のADDM分析の実行を待つことなく、リアルタイムでデータベースのパフォーマンスの問題を識別および解決できます。
パフォーマンス関連のアラートに対応します(第5章「パフォーマンス・アラートの監視」を参照)。
Enterprise Managerのデータベースのホームページでは、データベースによって生成されたパフォーマンス関連のアラートが表示されます。通常は、これらのアラートが示す問題を解決することで、データベースのパフォーマンスが向上します。
行った変更によって期待した結果が得られたことを検証します。また、ユーザーに対するデータベースのパフォーマンスが向上したかどうかを確認します。
この項では、ユーザー・フィードバックに基づいたデータベースのチューニングに必要な手順をリストして説明します。このチューニングの手順は事後と考えられます。ユーザーによりパフォーマンスの問題がレポートされたときに、この手順を定期的に実行します。
パフォーマンスの問題がユーザーによってレポートされた場合、ADDMを手動で実行して現在のデータベースのパフォーマンスおよびデータベースのパフォーマンスの履歴を診断します(第6章「データベースのパフォーマンスの手動監視」を参照)。
この方法で、次のADDM分析の前に現在のデータベースのパフォーマンスを分析したり、システムの定期的な監視を行っていないときに過去のデータベースのパフォーマンスを分析することができます。
一時的なパフォーマンスの問題を解決します(第7章「一時的なパフォーマンスの問題の解決」を参照)。
アクティブ・セッション履歴(ASH)レポートでは、短期間でADDM分析に表示されないデータベースの一時的なパフォーマンスの問題を分析できます。
時間の経過によるパフォーマンスの低下を解決します(第8章「時間の経過によるパフォーマンス低下の解決」を参照)。
自動ワークロード・リポジトリ(AWR)期間の比較レポートで、2つの期間のデータベースのパフォーマンスを比較でき、特定の期間から他の期間にかけて発生するパフォーマンスの低下を解決します。
行った変更によって期待した結果が得られたことを検証します。また、ユーザーに対するデータベースのパフォーマンスが向上したかどうかを確認します。
パフォーマンスの目標に達するか、他の制約により不可能になるまでこれらの手順を繰り返します。
この項では高負荷SQL文の識別、チューニングおよび最適化に必要な手順をリストして説明します。
高負荷のSQL文を識別します(第9章「高負荷のSQL文の識別」を参照)。
ADDMの検出結果および上位SQLセクションを使用して、最大の競合の原因となる高負荷SQL文を識別します。
高負荷のSQL文をチューニングします(第10章「SQL文のチューニング」を参照)。
SQLチューニング・アドバイザを使用して高負荷SQL文の効率を向上できます。
データ・アクセス・パスを最適化します(第11章「データ・アクセス・パスの最適化」を参照)。
マテリアライズド・ビュー、マテリアライズド・ビュー・ログ、およびSQLアクセス・アドバイザを使用した特定のワークロードに対する索引の該当セットを作成して、データ・アクセス・パスのパフォーマンスを最適化できます。
SQLパフォーマンス・アナライザを使用して、SQLチューニングおよびその他のシステム変更に対するSQLパフォーマンスの影響を分析します。
SQLパフォーマンス・アナライザの使用方法は、『Oracle Database Real Application Testingユーザーズ・ガイド』を参照してください。
すべての高負荷SQL文の効率が最大化されるまでこれらの手順を繰り返してチューニングを行います。
この項ではOracle Database内で検出された共通のパフォーマンスの問題をリストして説明します。Oracleパフォーマンス・メソッドに従うと、これらの問題を回避できます。問題がある場合は、「Oracleパフォーマンス・メソッドの使用」で説明されているように、Oracleパフォーマンス・メソッドの手順を繰り返すか、またはこれらの問題に対処する項を参照してください。
CPUのボトルネック
CPUの限界のためにアプリケーションのパフォーマンスが低下していますか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、CPUがボトルネックとなって発生するパフォーマンスの問題は、ADDMにより診断されます。また、「CPU使用率の監視」で説明されているように、Enterprise Managerの「パフォーマンス」ページを使用してCPUのボトルネックを識別できます。
メモリー構造のサイズ不足
システム・グローバル領域(SGA)、プログラム・グローバル領域(PGA)、バッファ・キャッシュなどのOracleのメモリー構造は適切なサイズですか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、メモリー構造のサイズが小さいことにより発生するパフォーマンスの問題は、ADDMにより診断されます。また、「メモリー使用率の監視」で説明されているように、Enterprise Managerの「パフォーマンス」ページを使用してメモリー使用率の問題を識別できます。
I/O容量の問題
I/Oサブシステムは正常に動作していますか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、I/Oの能力の問題によるパフォーマンスの問題は、ADDMにより診断されます。また、「ディスクI/O使用率の監視」で説明されているように、Oracle Enterprise Managerの「パフォーマンス」ページを使用してディスクI/Oの問題を識別できます。
アプリケーションによるOracle Databaseの非効率的な使用
アプリケーションが非効率的にOracle Databaseを使用していますか。データベースへの新規接続を何度も行ったり、SQL解析を過度に行ったり、少量のデータで過度の競合が発生(アプリケーション・レベルのブロック競合とも呼ばれます)したりすると、アプリケーションのパフォーマンスが大幅に低下します。第3章「データベースのパフォーマンスの自動監視」で説明されているように、アプリケーションによるOracle Databaseの使用が非効率的なために発生したパフォーマンスの問題は、ADDMにより診断されます。また、「ユーザー・アクティビティの監視」で説明されているように、Enterprise Managerの「パフォーマンス」ページを使用して、SQL、セッション、サービス、モジュールおよびアクションなどの様々なディメンションでトップ・アクティビティを監視できます。
同時実行の問題
同時アクティビティが多数発生し、データベースのパフォーマンスが低下していますか。同時アクティビティが多数発生すると、ロックまたはバッファ・キャッシュの待機の形で明示される共有リソースの競合が起こります。第3章「データベースのパフォーマンスの自動監視」で説明されているように、同時実行によるパフォーマンスの問題は、ADDMにより診断されます。また、「上位セッションの監視」で説明されているように、Enterprise Managerの「上位セッション」を使用して同時実行による問題を識別できます。
データベース構成の問題
理想的なパフォーマンス・レベルになるようにデータベースが最適な構成になっていますか。たとえば、ログ・ファイルのサイズ設定の異常、アーカイブの問題、過度のチェックポイント、非効率的なパラメータ設定などの徴候はありませんか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、データベースの構成の問題が原因となっているパフォーマンスの問題は、ADDMにより診断されます。
短期間のパフォーマンスの問題
短期間または断続的に発生するパフォーマンスの問題に関してユーザーが不満を持っていませんか。AWRによって作成されるスナップショットの間隔によって、短期間のパフォーマンスの問題がADDMで取得されない可能性があります。第7章「一時的なパフォーマンスの問題の解決」で説明されているように、短期間のパフォーマンスの問題は、アクティブ・セッション履歴レポートを使用して識別できます。
時間の経過によるデータベースのパフォーマンスの低下
時間が経過するにつれてデータベースのパフォーマンスが低下している徴候はありませんか。たとえば、データベースの動作が6か月前と異なるとユーザーが感じていませんか。AWR期間比較レポートを生成して、構成設定、ワークロード・プロファイルおよび統計の差を、パフォーマンスが安定していた期間とパフォーマンスが低下していた期間で比較して識別します。第8章「時間の経過によるパフォーマンスの低下」で説明されているように、この操作によりパフォーマンスの低下の原因を識別できます。
非効率的SQL文または高負荷SQL文
システムに影響を与える過度のシステム・リソースを使用するSQL文はありませんか。第3章「データベースのパフォーマンスの自動監視」および「ADDMの検出結果に基づく高負荷SQL文の識別」で説明されているように、高負荷SQL文によって発生するパフォーマンスの問題は、ADDMにより診断されます。また、「上位SQLに基づく高負荷SQL文の識別」で説明されているように、Enterprise Managerの上位SQLを使用することで高負荷SQL文を識別できます。これらを識別すると、第10章「SQL文のチューニング」で説明されているように、SQLチューニング・アドバイザを使用して高負荷SQL文をチューニングできます。
オブジェクト接続
連続してアクセスされるためボトルネックの原因になっているデータベース・オブジェクトはありませんか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、オブジェクトの競合によって発生するパフォーマンスの問題は、ADDMにより診断されます。また、第11章「データ・アクセス・パスの最適化」で説明されているように、SQLアクセス・アドバイザを使用してこれらのオブジェクトへのデータ・アクセス・パスを最適化できます。
SQL文チューニングの後の予期しないパフォーマンス低下
チューニング後に、SQL文のパフォーマンスが低下していませんか。SQL文をチューニングすると、SQL文の実行計画の変更の原因となり、SQLのパフォーマンスに大きく影響します。変更はSQLパフォーマンスの向上につながる場合もあります。場合によっては、システム変更によってSQL文が低下し、SQLパフォーマンスが低下することがあります。
本番システムで変更する前に、SQLパフォーマンス・アナライザを使用して、テスト・システムでチューニングしたSQLの影響を分析できます。この機能によって、次によるSQLワークロードへのシステム変更の影響を予想できます。
変更前後のパフォーマンスの測定
パフォーマンスの変更を説明するレポートの生成
低下または向上するSQL文の識別
低下するSQL文ごとのチューニング推奨の提供
適切な場合のチューニング推奨の実装
SQLパフォーマンス・アナライザの使用方法は、『Oracle Database Real Application Testingユーザーズ・ガイド』を参照してください。
