プライマリ・コンテンツに移動
Oracle® Database Testingガイド
12cリリース1 (12.1)
B71349-07
目次へ移動
目次
索引へ移動
索引

前
次

2.4 変更前のSQLパフォーマンスの測定

システム変更を行う前に、変更前のSQL試行を作成します。SQLパフォーマンス・アナライザでのSQL試行に必要なパフォーマンス・データは、次に示す方法で生成できます。

テスト実行の方法では、ワークロードに含まれている各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試行に以降の分析で使用可能な結果が格納されます。この方法は、次の操作を行う場合に有効です。

SQLワークロードを実行すると、生成された実行計画およびランタイム統計がSQL試行に格納されます。

SQLチューニング・セットに格納されている実行統計および計画を使用して、SQL試行を作成することもできます。この方法は、APIでのみサポートされていますが、ワークロードを実行する別の方法(データベース・リプレイまたは別のアプリケーション・テスト・ツール)があり、テスト・システムでワークロードを実行するためにSQLパフォーマンス・アナライザが必要ない場合に有効なことがあります。このような場合でも、テストの実行中にSQLチューニング・セットを取得すると、SQLパフォーマンス・アナライザを使用してこれらのSQLチューニング・セットからSQL試行を作成し、より包括的な分析レポートを表示することができます。標準のSQLパフォーマンス・アナライザ・レポート(各試行内の実行計画は1つのみで、1セットのバインドでSQL文を実行して生成される実行統計は1セット)とは異なり、SQLチューニング・セットから作成したSQL試行を比較するレポートを生成して、複数の実行にわたって潜在的に多数の異なるバインド・セットが存在する2つの試行からすべての実行計画を表示することができます。

関連項目: