| Oracle® Database Real Application Testingユーザーズ・ガイド 11gリリース2(11.2) B56321-06 |
|
 前 |
 次 |
SQLパフォーマンス・アナライザは、本番システムまたは本番システムによく似たテスト・システムで実行できます。SQLパフォーマンス・アナライザではテストするSQL文を実行する必要があるため、本番システムでシステム変更をテストすると、システムのスループットに影響します。パフォーマンスへの影響をテストするためにシステムで行うグローバル変更によって、システムのその他のユーザーが影響を受ける可能性もあります。システム変更が多数のセッションまたはSQL文に影響しない場合は、本番システムでSQLパフォーマンス・アナライザを実行できます。ただし、データベースのアップグレードなどのシステム全体の変更では本番システムを使用しないことをお薦めします。かわりに、本番システムに影響を与えずにシステム変更の影響をテストできるように、別のテスト・システムでSQLパフォーマンス・アナライザを実行することを検討してください。テスト・システムを使用すると、本番システムで実行されているその他のワークロードがSQLパフォーマンス・アナライザによって実行される分析に影響することもなくなります。推奨される方法はテスト・システムでSQLパフォーマンス・アナライザを実行する方法であり、その方法をここで説明します。本番システムでSQLパフォーマンス・アナライザを実行する場合は、適宜テスト・システムを本番システムに置き換えてください。
SQLパフォーマンス・アナライザを使用してシステム変更によるSQLパフォーマンスへの影響を分析する場合は、図2-1に示す手順を実行します。
分析対象のSQLワークロードを取得して、SQLチューニング・セットに格納します。詳細は、「SQLワークロードの取得」を参照してください。
本番システムとは切り離されたテスト・システムを使用する場合は、次の手順を実行します。
可能なかぎり本番環境と一致するようにテスト・システムを設定します。
SQLチューニング・セットをテスト・システムに転送します。
詳細は、「テスト・システムの設定」を選択してください。
テスト・システムで、SQLパフォーマンス・アナライザのタスクを作成します。詳細は、「SQLパフォーマンス・アナライザのタスクの作成」を参照してください。
SQLチューニング・セットに格納されているSQL文のテスト実行または実行計画の生成を行って、変更前のSQL試行を作成します。詳細は、「変更前のSQLパフォーマンスの測定」を参照してください。
システム変更を実行します。詳細は、「システム変更の実行」を参照してください。
変更後のテスト・システムでSQLチューニング・セット内のSQL文を再実行して、変更後のSQL試行を作成します。詳細は、「変更後のSQLパフォーマンスの測定」を参照してください。
変更前バージョンと変更後バージョンのパフォーマンス・データを比較および分析し、レポートを作成して、システム変更後にパフォーマンスが改善されたSQL文、パフォーマンスの変更がなかったSQL文またはパフォーマンスが低下したSQL文を特定します。詳細は、「パフォーマンス測定値の比較」を参照してください。
特定されたパフォーマンスが低下したSQL文をチューニングします。詳細は、「パフォーマンスが低下したSQL文の修正」を参照してください。
パフォーマンスの目標を達成するまで、手順6から8を繰り返し、チューニングしたSQL文のパフォーマンスが許容範囲内であることを確認します。
それぞれの比較において、以前のSQL試行を変更前のSQL試行として使用し、現在のSQL試行を変更後のSQL試行として使用できます。たとえば、最初のSQL試行を現在のSQL試行と比較して、すべての変更を評価したり、最新のSQL試行を現在のSQL試行と比較して、最新の変更のみを評価する場合があります。
SQLパフォーマンス・アナライザを実行する前に、分析対象のSQLワークロードを表すSQL文のセットを本番システムで取得します。
取得したSQL文には、次の情報が含まれています。
SQLテキスト
実行環境
SQL文を実行し、正確な実行統計を生成するために必要なバインド値であるSQLバインド
SQL文をコンパイルできる解析スキーマ
SQL文が実行される、初期化パラメータが含まれているコンパイル環境
SQL文の実行回数
SQLワークロードの取得は、本番システムのパフォーマンスにごくわずかな影響を与えますが、スループットには影響を与えません。より多くのSQL文が含まれているSQLワークロードでは、アプリケーションまたはデータベースの状態がよりよく表示されます。これによって、システム変更がSQLワークロードに与える可能性がある影響をSQLパフォーマンス・アナライザでより正確に予測できるようになります。そのため、可能なかぎり多くのSQL文を取得する必要があります。アプリケーションでコールされているすべてのSQL文またはデータベースで実行されているすべてのSQL文のいずれかを取得することをお薦めします。
取得したSQL文をSQLチューニング・セットに格納し、SQLパフォーマンス・アナライザの入力ソースとして使用できます。SQLチューニング・セットは、1つ以上のSQL文がその実行統計および実行コンテキストとともに含まれているデータベース・オブジェクトです。SQL文は、カーソル・キャッシュ、自動ワークロード・リポジトリ(AWR)、既存のSQLチューニング・セットなどの様々なソースからSQLチューニング・セットにロードできます。SQLチューニング・セットを使用してSQLワークロードを取得すると、次のことができます。
単一の永続データベース・オブジェクトへのSQLテキストおよび必要な補助情報の格納
SQLチューニング・セット内の取得済SQL文の移入、更新、削除および選択
自動ワークロード・リポジトリ(AWR)やカーソル・キャッシュなどの様々なデータ・ソースからのコンテンツのロードおよびマージ
SQLワークロードを取得したシステムからのSQLチューニング・セットのエクスポート、および別のシステムへのSQLチューニング・セットのインポート
SQLチューニング・アドバイザやSQLアクセス・ アドバイザなどの他のアドバイザへの入力ソースとしてのSQLワークロードの再使用
|
関連項目:
|
本番システムでSQLチューニング・セットにSQLワークロードを取得したら、ワークロードを取得したデータベースと同じデータベースまたは異なるデータベースでSQLパフォーマンス・アナライザの分析を実行できます。分析ではリソースが多く消費されるため、本番データベースでワークロードを取得して、分析を実行できる別のテスト・データベースに転送することをお薦めします。これを行うには、SQLチューニング・セットを本番システムからエクスポートし、システム変更をテストする別のシステムにインポートします。
テスト・データベースを作成する方法はいくつもあります。たとえば、Recovery Manager(RMAN)のDUPLICATEコマンド、Oracle Data Pumpまたはトランスポータブル表領域を使用できます。RMANではテスト・データベースを既存のバックアップまたはアクティブな本番データ・ファイルから作成できるため、RMANを使用することをお薦めします。本番データベースとテスト・データベースは、同じホストまたは異なるホストのいずれにも存在できます。
可能なかぎり本番システムのデータベース環境と一致するようにテスト・データベース環境を構成する必要があります。これによって、システム変更がSQLパフォーマンスに与える影響をSQLパフォーマンス・アナライザでより正確に予測できるようになります。
テスト・システムを適切に構成したら、SQLチューニング・セットを本番システムからステージング表にエクスポートし、次にステージング表からテスト・システムにインポートします。
|
関連項目:
|
SQLワークロードを取得してテスト・システムに転送し、初期化データベース環境を適切に構成したら、SQLパフォーマンス・アナライザを実行して、システム変更がSQLパフォーマンスに与える影響を分析できます。
SQLパフォーマンス・アナライザを実行するには、まずSQLパフォーマンス・アナライザのタスクを作成する必要があります。タスクは、SQLパフォーマンス・アナライザの完全な分析に関するすべてのデータがカプセル化されているコンテナです。SQLパフォーマンス・アナライザの分析は、2つ以上のSQL試行と1つの比較で構成されています。SQL試行で、特定の環境条件下でのSQLチューニング・セットの実行パフォーマンスがカプセル化されます。SQLパフォーマンス・アナライザのタスクを作成する場合は、入力ソースとしてSQLチューニング・セットを選択する必要があります。テスト実行または実行計画の方法でSQL試行を構築する場合、SQL文のソースとしてSQLチューニング・セットが使用されます。SQLパフォーマンス・アナライザは、2つの試行間での環境の相違による影響を表示します。
システム変更を行う前に、変更前のSQL試行を作成します。SQLパフォーマンス・アナライザでのSQL試行に必要なパフォーマンス・データは、次に示す方法で生成できます。
テスト実行
この方法では、SQLパフォーマンス・アナライザを介してSQL文をテスト実行します。SPAパフォーマンス・アナライザを実行しているデータベースまたはリモート・データベースで実行できます。
実行計画
この方法では、SQLパフォーマンス・アナライザを介してSQL文に対してのみ実行計画を生成します。SPAパフォーマンス・アナライザを実行しているデータベースまたはリモート・データベースで実行できます。EXPLAIN PLAN文と異なり、実行計画の方法を使用するSQL試行ではバインド値が考慮され、実際の実行計画が生成されます。
SQLチューニング・セットの変換
この方法では、SQLチューニング・セットに格納されている実行統計と計画を変換します。この方法はAPIでのみサポートされています。
テスト実行の方法では、ワークロードに含まれている各SQL文が完了するまで実行されます。実行中、SQLパフォーマンス・アナライザによってワークロードのSQL文ごとに実行計画が生成され、実行統計が計算されます。SQLチューニング・セット内の各SQL文は、SQL文の初期の実行順序または同時実行性を維持せずに、その他のSQL文とは別に実行されます。これは、実行タイムアウトが発生するまで可能なかぎり多く(最大10回)、SQL文ごとに2回以上実行されます。最初の実行は、バッファ・キャッシュの準備のために使用されます。以降のすべての実行は、平均に基づいてSQL文の実行時の実行統計を計算するために使用されます。SQL文が実行される実際の回数は、SQL文の実行時間の長さによって異なります。実行時間が長いSQL文は2回だけ実行され、この実行から得られた実行統計が使用されます。その他の(比較的時間の短い)SQL文は複数回実行され、これらの実行から実行統計の平均が計算されます(最初の実行で得られた統計は計算に使用されません)。複数の実行の統計の平均を求めることで、SQLパフォーマンス・アナライザは各SQL文の実行統計をより正確に計算できます。データベースが受ける可能性がある影響を回避するために、DDLはサポートされていません。デフォルトでは、DMLの問合せ部分のみが実行されます。APIを使用する場合は、EXECUTE_FULLDMLタスク・パラメータを使用することでDML全体を実行できます。パラレルDMLはサポートされておらず、パラレル・ヒントが削除されないかぎり、その問合せ部分は実行されません。
サイズによっては、SQLワークロードの実行に時間およびリソースが大量に消費される可能性があります。実行計画の方法では、実行統計を収集せずに、実行計画のみの生成を選択することができます。この方法によって、試行を実行する時間が短縮され、システム・リソースへの影響が減少しますが、分析時に使用できるのは実行計画のみのため、包括的なパフォーマンスの分析は実行できません。ただし、EXPLAIN PLANコマンドで計画を生成した場合とは異なり、SQLパフォーマンス・アナライザから、実行計画の生成時にオプティマイザにバインド値が提供されるため、SQL文の実行時に計画の結果に関してより信頼性の高い予測が得られます。
どちらの場合も、データベース・リンクを使用して、別のデータベースでSQLワークロードをリモートで実行することができます。SQLパフォーマンス・アナライザによって、データベース・リンクを介してリモート・データベースへの接続が確立され、そのデータベースでSQL文が実行され、SQL文ごとの実行計画およびランタイム統計が収集されて、ローカル・データベースのSQL試行に以降の分析で使用可能な結果が格納されます。この方法は、次の操作を行う場合に有効です。
データベースのアップグレードのテスト
別のバージョンのOracle Databaseが実行されているシステムでのSQLワークロードの実行
別のテスト・システムへのSQLパフォーマンス・アナライザの分析結果の格納
ハードウェア構成が異なる複数のシステムでのテストの実行
本番システムで古いバージョンのOracle Databaseを使用している場合のSQLパフォーマンス・アナライザの最新機能の使用
SQLワークロードを実行すると、生成された実行計画およびランタイム統計がSQL試行に格納されます。
SQLチューニング・セットに格納されている実行統計および計画を使用して、SQL試行を作成することもできます。この方法は、APIでのみサポートされていますが、ワークロードを実行する別の方法(データベース・リプレイまたは別のアプリケーション・テスト・ツール)があり、テスト・システムでワークロードを実行するためにSQLパフォーマンス・アナライザが必要ない場合に有効なことがあります。このような場合でも、テストの実行中にSQLチューニング・セットを取得すると、SQLパフォーマンス・アナライザを使用してこれらのSQLチューニング・セットからSQL試行を作成し、より包括的な分析レポートを表示することができます。標準のSQLパフォーマンス・アナライザ・レポート(各試行内の実行計画は1つのみで、1セットのバインドでSQL文を実行して生成される実行統計は1セット)とは異なり、SQLチューニング・セットから作成したSQL試行を比較するレポートを生成して、複数の実行にわたって潜在的に多数の異なるバインド・セットが存在する2つの試行からすべての実行計画を表示することができます。
|
関連項目:
|
測定対象のSQLパフォーマンスにかかわる変更を行います。SQLパフォーマンス・アナライザでは、様々なタイプのシステム変更による影響を分析できます。たとえば、データベースのアップグレード、新しい索引の作成、初期化パラメータの変更、オプティマイザ統計のリフレッシュなどをテストできます。本番システムでSQLパフォーマンス・アナライザを実行する場合は、残りのシステムへの影響を回避するためにプライベート・セッションを使用して変更を行うことを検討してください。
システム変更の実行後、変更後のSQL試行を作成します。変更後のSQL試行は、変更前のSQL試行と同じ方法を使用して作成することを強くお薦めします。作成すると、変更後のSQL試行に新しいパフォーマンス・データセットが生成され、変更前のバージョンと比較可能になります。この結果は、新しいSQL試行または変更後のSQL試行に保存されます。
SQLパフォーマンス・アナライザでは、変更前と変更後のSQL文のパフォーマンスが比較され、SQL文の実行計画またはパフォーマンスでの変更を特定するレポートが生成されます。
SQLパフォーマンス・アナライザは、SQLワークロード全体の実行時間とワークロード内の個々のSQL文のレスポンス時間について、システム変更による影響を測定します。デフォルトでは、SQLパフォーマンス・アナライザは、比較のメトリックに経過時間を使用します。また、次のSQL実行統計の中から比較のメトリックを選択できます。
CPU時間
ユーザーI/O時間
バッファ読取り
「物理I/O」
オプティマイザ・コスト
I/Oインターコネクト・バイト
式形式でのこれらメトリックの組合せ
SQL試行で実行計画のみを生成する場合、SQLパフォーマンス・アナライザではSQL実行計画に格納されているオプティマイザ・コストが使用されます。
比較が完了すると、変更前と変更後のSQLパフォーマンスを比較するSQLパフォーマンス・アナライザ・レポートに結果のデータが生成されます。SQLパフォーマンス・アナライザ・レポートは、HTML、テキストまたはアクティブ・レポートとして表示できます。アクティブ・レポートには、インタラクティブなユーザー・インタフェースを使用するきめ細かなレポート機能が用意されており、データベースやOracle Enterprise Managerに接続されていないときでも詳細な分析を実行できます。
