| Oracle Database Real Application Testingユーザーズ・ガイド 11gリリース1（11.1） B51856-01 |
|
 戻る |
 次へ |
SQLパフォーマンス・アナライザは、本番システムまたは本番システムによく似たテスト・システムで実行できます。 SQLパフォーマンス・アナライザではテストするSQL文を実行する必要があるため、本番システムでシステム変更をテストすると、システムのスループットに影響します。 パフォーマンスへの影響をテストするためにシステムで行うグローバル変更によって、システムのその他のユーザーが影響を受ける可能性もあります。 システム変更が多数のセッションまたはSQL文に影響しない場合は、本番システムでSQLパフォーマンス・アナライザを実行できます。 ただし、データベースのアップグレードなどのシステム全体の変更では本番システムを使用しないことをお薦めします。 かわりに、本番システムに影響を与えずにシステム変更の影響をテストできるように、別のテスト・システムでSQLパフォーマンス・アナライザを実行することを検討してください。 テスト・システムを使用すると、本番システムで実行されているその他のワークロードがSQLパフォーマンス・アナライザによって実行される分析に影響することもなくなります。 推奨される方法はテスト・システムでSQLパフォーマンス・アナライザを実行する方法であり、その方法をここで説明します。 本番システムでSQLパフォーマンス・アナライザを実行する場合は、適宜テスト・システムを本番システムに置き換えてください。
SQLパフォーマンス・アナライザを使用してシステム変更によるSQLパフォーマンスへの影響を分析する場合は、図7-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またはトランスポータブル表領域を使用できます。 Recovery Managerではテスト・データベースを既存のバックアップまたはアクティブな本番データ・ファイルから作成できるため、Recovery Managerを使用することをお薦めします。 本番データベースとテスト・データベースは、同じホストまたは異なるホストのいずれにも存在できます。
可能なかぎり本番システムのデータベース環境と一致するようにテスト・データベース環境を構成する必要があります。 これによって、システム変更がSQLパフォーマンスに与える影響をSQLパフォーマンス・アナライザでより正確に予測できるようになります。
テスト・システムを適切に構成したら、SQLチューニング・セットを本番システムからステージング表にエクスポートし、次にステージング表からテスト・システムにインポートします。
|
参照:
|
SQLワークロードを取得してテスト・システムに転送し、初期化データベース環境を適切に構成したら、SQLパフォーマンス・アナライザを実行して、システム変更がSQLパフォーマンスに与える影響を分析できます。
SQLパフォーマンス・アナライザを実行するには、まずSQLパフォーマンス・アナライザのタスクを作成する必要があります。 タスクは、SQLパフォーマンス・アナライザの完全な分析に関するすべてのデータがカプセル化されているコンテナです。 SQLパフォーマンス・アナライザの分析は、2つ以上のSQL試行と1つの比較で構成されています。 SQL試行では、特定の環境条件下でのSQLチューニング・セットの実行パフォーマンスがカプセル化され、システム変更のテスト時にSQLパフォーマンス・アナライザによって実行される特定のテスト実行および実行計画操作が示されます。 SQLパフォーマンス・アナライザのタスクを作成する場合は、入力ソースとしてSQLチューニング・セットを選択する必要があります。 SQLチューニング・セットは、SQLパフォーマンス・アナライザで維持され、各SQL試行時に個別に実行されます。 このため、試行間のパフォーマンスの相違は、環境の相違が原因となります。
システム変更を行う前に、SQLワークロードを実行して変更前のSQL試行を作成します。 SQLワークロードの実行では、ワークロードに含まれている各SQL文が完了するまで実行されます。 SQLチューニング・セット内の各SQL文は、SQL文の初期の実行順序または同時実行性を維持せずに、その他のSQL文とは別に1回（1つずつ）実行されます。 データベースが受ける可能性がある影響を回避するために、DDL文はサポートされておらず、DML文の問合せ部分のみが実行されます。 実行中、SQLパフォーマンス・アナライザによってワークロードのSQL文ごとに実行計画が生成され、実行統計が計算されます。
サイズによっては、SQLワークロードの実行に時間およびリソースが大量に消費される可能性があります。 SQLワークロードの実行時に、実行統計を収集せずに、実行計画のみを生成するように選択することができます。 この方法によって、実行時間が短縮され、システム・リソースへの影響が減少しますが、分析時に使用できるのは実行計画のみのため、包括的なパフォーマンスの分析は実行できません。
SQLワークロードを実行する方法としては、Oracle Database 11gが実行されているシステムでSQLパフォーマンス・アナライザを実行し、指定したデータベース・リンクを介して別のデータベースでSQL文をリモートで実行する方法もあります。 SQLパフォーマンス・アナライザによって、指定したデータベース・リンクを介してリモート・データベースへの接続が確立され、そのデータベースでSQL文が実行され、SQL文ごとの実行計画およびランタイム統計が収集されて、ローカル・データベースのSQL試行に以降の分析で使用可能な結果が格納されます。 この方法は、次の操作を行う場合に有効です。
データベースのアップグレードのテスト
別のバージョンのOracle Databaseが実行されているシステムでのSQLワークロードの実行
別のテスト・システムへのSQLパフォーマンス・アナライザの分析結果の格納
ハードウェア構成が異なる複数のシステムでのテストの実行
本番システムで古いバージョンのOracle Databaseを使用している場合のSQLパフォーマンス・アナライザの最新機能の使用
SQLワークロードを実行すると、生成された実行計画およびランタイム統計がSQL試行に格納されます。
|
参照:
|
測定対象のSQLパフォーマンスにかかわる変更を行います。 SQLパフォーマンス・アナライザでは、様々なタイプのシステム変更による影響を分析できます。 たとえば、データベースのアップグレード、新しい索引の作成、初期化パラメータの変更、オプティマイザ統計のリフレッシュなどをテストできます。 本番システムでSQLパフォーマンス・アナライザを実行する場合は、残りのシステムへの影響を回避するためにプライベート・セッションを使用して変更を行うことを検討してください。
システム変更を実行したら、SQLワークロードを再度実行して変更後のSQL試行を作成します。 SQLパフォーマンス・アナライザによって、ワークロードのSQL文ごとに実行計画が再度生成され、実行統計が計算されて、変更前のバージョンとの比較に使用可能な新しいパフォーマンス・データのセットが生成されます。 この結果は、新しいSQL試行または変更後のSQL試行に格納されます。
SQLパフォーマンス・アナライザでは、変更前と変更後のSQL文のパフォーマンスが比較され、SQL文の実行計画またはパフォーマンスでの変更を特定するレポートが生成されます。
SQLパフォーマンス・アナライザでは、SQLワークロードの全体的なレスポンス時間およびワークロード内の各SQL文の全体的なレスポンス時間の両方に対するシステム変更による影響が測定されます。 デフォルトでは、SQLパフォーマンス・アナライザでは比較用メトリックとして経過時間が使用されます。 また、様々な利用可能なSQLランタイム統計から比較用のメトリックを選択することができます。次のメトリックが含まれます。
CPU時間
バッファ読取り
ディスク読取り
ディスク書込み
式形式でのこれらメトリックの組合せ
SQL試行で実行計画のみを生成する場合、SQLパフォーマンス・アナライザではSQL実行計画に格納されているオプティマイザ・コストが使用されます。
