ヘッダーをスキップ
Oracle® Database Real Application Testingユーザーズ・ガイド
11gリリース2(11.2)
B56321-06
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

7 データベースのアップグレードのテスト

SQLパフォーマンス・アラナイザは、Oracle9i以降のリリースからOracle Database 10gリリース2以降へのデータベース・アップグレードのテストをサポートしています。Oracle9i DatabaseおよびOracle Database 10gリリース1からのデータベース・アップグレードのテストに使用する方法は、Oracle Database 10gリリース2以降からのデータベース・アップグレードのテストに使用する方法とわずかに異なるので、ここでは両方の方法を説明します。

この章では、データベースのアップグレードにSQLパフォーマンス・アナライザを使用する方法について説明します。内容は次のとおりです。


注意:

その他の場合のSQLパフォーマンス・アナライザの使用については、「SQLパフォーマンス・アナライザ」を参照してください。

7.1 Oracle9i DatabaseおよびOracle Database 10gリリース1からのアップグレード

図7-1に示すように、SQLパフォーマンス・アナライザでは、本番システムで取得されたSQLトレース・ファイルからSQLチューニング・セットを作成し、アップグレードしたデータベースでデータベース・リンクを介してSQLチューニング・セットをリモート実行し、その結果を本番システムで取得した情報と比較することによって、Oracle9i DatabaseおよびOracle Database 10gリリース1から、Oracle Database 10gリリース2以上のリリースへのデータベースのアップグレードのテストがサポートされています。SQLパフォーマンス・アナライザではSQLチューニング・セットに格納されているSQL文のセットのみが入力ソースとして受け入れられ、Oracle9i DatabaseではSQLチューニング・セットがサポートされていないため、Oracle9i Databaseからアップグレードする場合は、SQLチューニング・セットをSQLパフォーマンス・アナライザの入力ソースとして使用できるように作成する必要があります。

図7-1 Oracle9iからOracle Database 10gリリース2にデータベースをアップグレードする場合のSQLパフォーマンス・アナライザのワークフロー

図7-1の説明は次にあります
「図7-1 Oracle9iからOracle Database 10gリリース2にデータベースをアップグレードする場合のSQLパフォーマンス・アナライザのワークフロー」の説明

アップグレード元となる本番システムでは、Oracle9iまたはOracle Database 10gリリース1が実行されている必要があります。アップグレード先となるテスト・システムでは、Oracle Database 10gリリース2以上のリリースが実行されている必要があります。データベースのバージョンは、リリース10.2.0.2以上にできます。Oracle Database 10gリリース10.2.0.2、10.2.0.3または10.2.0.4にアップグレードする場合は、手順を進める前に、個別パッチをインストールする必要もあります。

本番システムとテスト・システムの両方のパフォーマンスを比較するため、SQLパフォーマンス・アナライザによって行われた分析が正確であることを保証するには、可能なかぎり、テスト・システムが本番システムに類似している必要があります。また、両方のシステムのハードウェア構成は可能なかぎり同じにする必要があります。

次に、Oracle Database 11gリリース2を実行している別のSQLパフォーマンス・アナライザ・システムを設定する必要があります。このシステムを使用して、SQLチューニング・セットを作成し、SQLパフォーマンス・アナライザを実行します。このシステムでは、本番システムのSQLトレース・ファイルに格納されている統計を使用してSQLチューニング・セットが作成されるため、本番データおよびスキーマを使用できる必要はありません。SQLパフォーマンス・アナライザのタスクがテスト・システム上でリモートに実行され、指定したデータベース・リンクを介してSQL試行に対する実行計画および実行統計が生成されます。データベース・リンクは、DBMS_SQLPAパッケージのEXECUTE権限およびテスト・システムのADVISOR権限を持つユーザーに接続するパブリック・データベース・リンクである必要があります。また、テスト・システム上のユーザーのスキーマから既存のPLAN_TABLEを削除する必要もあります。

前述のとおりアップグレード環境を構成したら、Oracle9iまたはOracle Database 10gリリース1からそれ以上のリリースへのデータベースのアップグレードでSQLパフォーマンス・アナライザを使用するために、次に説明する手順を実行します。

  1. 本番システムでSQLトレース機能を有効にします。詳細は、「本番システムでのSQLトレース機能の有効化」を参照してください。

    本番システムへのパフォーマンスの影響を最小限に抑えながら、SQL文の典型的なセットを完全に取得する場合は、必要な期間セッションのサブセットに対してのみSQLトレースを有効にして、すべての重要なSQL文を1回以上取得することを検討してください。

  2. 本番システムでマッピング表を作成します。詳細は、「マッピング表の作成」を参照してください。

    このマッピング表は、SQLトレース・ファイルのユーザーおよびオブジェクトの識別子番号を、同等の文字列に変換するために使用します。

  3. SQLトレース・ファイルおよびマッピング表を本番システムからSQLパフォーマンス・アナライザのシステムに移動します。詳細は、「マッピング表の作成」を参照してください。

  4. SQLパフォーマンス・アナライザのシステムで、SQLトレース・ファイルを使用してSQLチューニング・セットを作成します。詳細は、「SQLチューニング・セットの作成」を参照してください。

    SQLチューニング・セットには、SQLトレース・ファイルで取得されたSQL文がそれらのSQL文に関連する実行コンテキストおよび実行統計とともに含まれます。

  5. SQLパフォーマンス・アナライザ・システムでは、SQLパフォーマンス・アナライザを使用して、SQLパフォーマンス・アナライザのタスクを作成し、SQLチューニング・セットの内容を、比較のベースラインとして使用するアップグレード前のSQL試行に変換します。その後、データベース・リンクを介してSQL文のテスト実行をリモートで行い、アップグレード後のSQL試行を作成します。詳細は、「Oracle9i DatabaseおよびOracle Database 10gリリース1からのデータベースのアップグレードのテスト」を参照してください。

  6. SQLパフォーマンスを比較し、パフォーマンスが低下したSQLを修正します。

    SQLパフォーマンス・アナライザでは、アップグレード前のSQL試行時にSQLチューニング・セットから読み取ったSQL文のパフォーマンスと、アップグレード後のSQL試行時にリモートのテスト実行によって取得したSQL文のパフォーマンスが比較されます。SQL文の実行計画またはパフォーマンスの変更内容を確認するためのレポートが生成されます。

    パフォーマンスが低下したSQL文がレポートに示された場合は、パフォーマンスが低下したSQL文を修正するためにさらに変更を行うことができます。詳細は、「データベースのアップグレードをテストした後のパフォーマンスが低下したSQL文のチューニング」を参照してください。

    SQLチューニング・セットの実行およびそのパフォーマンスと以前の実行のパフォーマンスとの比較を繰り返して、分析結果に満足するまで、行った変更をテストします。

7.1.1 本番システムでのSQLトレース機能の有効化

Oracle9iでは、SQLトレース機能を使用して個々のSQL文のパフォーマンス・データが収集されます。SQLトレースによって生成された情報は、SQLトレース・ファイルに格納されます。SQLパフォーマンス・アナライザでは、これらのファイルに格納されている次の情報が使用されます。

  • 解析が行われたSQLテキストおよびユーザー名

  • 各実行のバインド値

  • CPU時間および経過時間

  • 物理読取りおよび論理読取り

  • 処理された行数

  • 各SQL文の実行計画(SQL文のカーソルがクローズしている場合にのみ取得される)

インスタンスに対してSQLトレースを有効にすることは可能ですが、セッションのサブセットに対してSQLトレースを有効にすることをお薦めします。インスタンスに対してSQLトレース機能を有効にすると、そのインスタンスで実行されたすべてのSQL文のパフォーマンス統計がSQLトレース・ファイルに格納されます。このようにSQLトレースを使用すると、パフォーマンスに重大な影響を与えたり、システムのオーバーヘッドの増加、過度なCPU使用率、ディスク領域の不足などを引き起こす可能性があります。トレース・レベルを4に設定して、バインド値および実行計画を取得する必要があります。

Oracle Database 10gリリース1が実行されている本番システムで、DBMS_MONITOR.SESSION_TRACE_ENABLEプロシージャを使用して、SQLトレースを別のセッションで透過的に有効にします。bindsプロシージャ・パラメータをTRUEに設定して(デフォルト値はFALSE)、バインドを明示的に有効にする必要もあります。

SQLトレースを有効にしたら、SQLパフォーマンス・アナライザで使用するSQL文の典型的なセットの統計が含まれているSQLトレース・ファイルを特定します。その後、SQLトレース・ファイルをSQLパフォーマンス・アナライザのシステムにコピーします。SQLワークロードをSQLトレース・ファイルに取得したら、本番システムでSQL試行を無効にします。


関連項目:

  • SQLトレースを使用する場合の追加の考慮事項(SQLトレース・ファイルを管理する初期化パラメータの設定など)については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

  • DBMS_MONITORパッケージについては、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。


7.1.2 マッピング表の作成

SQLトレース・ファイルに格納されているユーザーおよびオブジェクトの識別子番号を個別の名前に変換するには、それぞれのマッピングを指定する表を用意する必要があります。SQLパフォーマンス・アナライザのシステムでは、トレース・ファイルがSQLチューニング・セットに変換されるときにこのマッピング表が読み取られます。

マッピング表を作成するには、本番データベースで次のSQL文を実行します。

CREATE TABLE mapping AS
    SELECT object_id id, owner, SUBSTR(object_name, 1, 30) name FROM dba_objects
    WHERE object_type NOT IN ('CONSUMER GROUP', 'EVALUATION CONTEXT', 'FUNCTION',
                              'INDEXTYPE', 'JAVA CLASS', 'JAVA DATA',
                              'JAVA RESOURCE', 'LIBRARY', 'LOB', 'OPERATOR',
                              'PACKAGE', 'PACKAGE BODY', 'PROCEDURE', 'QUEUE',
                              'RESOURCE PLAN', 'SYNONYM', 'TRIGGER', 'TYPE',
                              'TYPE BODY')
    UNION ALL
    SELECT user_id id, username owner, null name FROM dba_users;

マッピング表が作成されたら、データ・ポンプを使用してSQLパフォーマンス・アナライザのシステムに転送できます。


関連項目:

  • データ・ポンプの使用については、『Oracle Databaseユーティリティ』を参照してください。


7.1.3 SQLチューニング・セットの作成

SQLパフォーマンス・アナライザのシステムにSQLトレース・ファイルおよびマッピング表が移動されたら、DBMS_SQLTUNEパッケージを使用してSQLチューニング・セットを作成できます。

SQLチューニング・セットを作成するには、次の手順を実行します。

  1. SQLパフォーマンス・アナライザのシステム上のディレクトリにSQLトレース・ファイルをコピーします。

  2. このディレクトリのディレクトリ・オブジェクトを作成します。

  3. DBMS_SQLTUNE.SELECT_SQL_TRACEファンクションを使用して、SQLトレース・ファイルからSQL文を読み取ります。

    各SQL文に対して、単一実行の情報のみが収集されます。各SQL文の実行頻度は取得されません。そのため、Oracle Database 10gリリース1以前のリリースが実行されている本番システムの比較分析を実行する場合は、SQLパフォーマンス・アナライザ・レポートのワークロード・レベルの統計を無視して、実行レベルでのパフォーマンスの変更のみを評価する必要があります。

    次の例では、sql_trace_prodディレクトリ・オブジェクトに格納されているSQLトレース・ファイルのコンテンツを読み取ってSQLチューニング・セットにロードします。

    DECLARE
      cur sys_refcursor;
    BEGIN
      DBMS_SQLTUNE.CREATE_SQLSET('my_sts_9i');
      OPEN cur FOR
        SELECT VALUE (P) 
        FROM table(DBMS_SQLTUNE.SELECT_SQL_TRACE('sql_trace_prod', '%ora%')) P;
      DBMS_SQLTUNE.LOAD_SQLSET('my_sts_9i', cur);
      CLOSE cur;
    END;
    /
    

SELECT_SQL_TRACEファンクションの構文は、次のようになります。

  DBMS_SQLTUNE.SELECT_SQL_TRACE ( 
    directory              IN VARCHAR2,
    file_name              IN VARCHAR2 := NULL,
    mapping_table_name     IN VARCHAR2 := NULL,
    mapping_table_owner    IN VARCHAR2 := NULL,
    select_mode            IN POSITIVE := SINGLE_EXECUTION,
    options                IN BINARY_INTEGER := LIMITED_COMMAND_TYPE,
    pattern_start          IN VARCHAR2 := NULL,
    parttern_end           IN VARCHAR2 := NULL,
    result_limit           IN POSITIVE := NULL)
  RETURN sys.sqlset PIPELINED;

表7-1に、SELECT_SQL_TRACEファンクションで使用できるパラメータを示します。

表7-1 DBMS_SQLTUNE.SELECT_SQL_TRACEファンクションのパラメータ

パラメータ 説明

directory

SQLトレース・ファイルが格納されるディレクトリを指すディレクトリ・オブジェクトを指定します。

file_name

処理するSQLトレース・ファイルの名前の全体または一部を指定します。指定しなかった場合、特定のディレクトリにある現在または最近のトレース・ファイルが使用されます。トレース・ファイル名の照合には、%ワイルドカードを使用できます。

mapping_table_name

マッピング表の名前を指定します。デフォルト値のNULLに設定されている場合、現在のデータベースからのマッピングが使用されます。マッピング表の名前は、大/小文字が区別されないことに注意してください。

mapping_table_owner

マッピング表が存在するスキーマを指定します。NULLに設定すると、現在のスキーマが使用されます。

select_mode

トレース・ファイルからSQL文を選択するためのモードを指定します。デフォルト値はSINGLE_EXECUTIONです。このモードでは、SQL文ごとに1回の実行の統計のみがSQLチューニング・セットにロードされます。統計は、SQLチューニング・セットの他のデータソースのテーブル・ファンクションの場合と同様に累積されません。

options

操作のオプションを指定します。デフォルト値はLIMITED_COMMAND_TYPEで、SQLトレース・ファイルから戻されるのは、SQLパフォーマンス・アナライザにとって意味のあるSQLタイプ(SELECTINSERTUPDATEDELETEなど)のみです。

pattern_start

対象とするトレース・ファイル・セクションの開始区切りパターンを指定します。このパラメータは、現在使用されていません。

pattern_end

処理するトレース・ファイル・セクションの終了区切りパターンを指定します。このパラメータは、現在使用されていません。

result_limit

(除外された)ソースの上位SQLを指定します。デフォルト値は231で、これは実質的に無制限であることを表します。



関連項目:

  • DBMS_SQLTUNEパッケージについては、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。


7.1.4 Oracle9i DatabaseおよびOracle Database 10gリリース1からのデータベースのアップグレードのテスト

SQLチューニング・セットが作成されたら、SQLパフォーマンス・アナライザを使用して、SQLチューニング・セット内の実行計画および実行時の統計からアップグレード前のSQL試行を作成できます。変更前のSQL試行が作成されたら、テスト・システムでSQLチューニング・セット内のSQL文のテスト実行または計画の生成を行い、アップグレード後のSQL試行を作成する必要があります。SQLパフォーマンス・アナライザでは、テスト・システムにリモート接続し、SQL試行の実行計画と統計を生成することによって、指定したパブリック・データベース・リンクを使用してSQL文をテスト実行します。データベース・リンクは、SQLパフォーマンス・アナライザ・システムに存在し、テスト・システムでSQLチューニング・セットを実行する権限を持つリモート・ユーザーに接続されている必要があります。

SQLパフォーマンス・アナライザを実行し、Oracle Enterprise ManagerまたはAPIを使用して、Oracle9i DatabaseまたはOracle Database 10gリリース1からのデータベースのアップグレードをテストすることができます。詳細は、次の項を参照してください。

7.1.4.1 Enterprise Managerを使用した、Oracle9i DatabaseおよびOracle Database 10gリリース1からのデータベースのアップグレードのテスト

SQLパフォーマンス・アナライザを使用して、Oracle9i DatabaseまたはOracle Database 10g リリース1からデータベースのアップグレードをテストするには、次の手順を実行します。

  1. 「ソフトウェアとサポート」ページの「Real Application Testing」で、「SQLパフォーマンス・アナライザ」をクリックします。

    「SQLパフォーマンス・アナライザ」ページが表示されます。

  2. SQLパフォーマンス・アナライザのワークフローで、「9iまたは10.1からのアップグレード」をクリックします。

    「9iまたは10.1からのアップグレード」ページが表示されます。

     spa_upgrade_9i_101.gifの説明が続きます。
    spa_upgrade_9i_101.gifの説明

  3. 「タスク情報」で、次のように指定します。

    1. 「タスク名」フィールドに、タスクの名前を入力します。

    2. 「SQLチューニング・セット」フィールドに、作成されたSQLチューニング・セットの名前を入力します。

      または、検索アイコンをクリックして、「検索と選択: SQLチューニング・セット」ウィンドウでSQLチューニング・セットを検索します。

      選択したSQLチューニング・セットが「SQLチューニング・セット」フィールドに表示されます。

    3. 「説明」フィールドに、オプションでタスクの説明を入力します。

  4. 「作成方法」フォールドで、次のように選択します。

    • SQLの実行: 実際にパブリック・データベース・リンクを介してテスト・システムでSQL文をリモートに実行することによって、SQLチューニング・セット内の各SQL文に対して実行計画と統計の両方を生成します。

    • 計画の生成: 実際にSQL文が実行されることなく、パブリック・データベース・リンクを介してテスト・システムで実行計画がリモートに作成されます。

  5. 「SQL当たりの時間制限」リストで、次のいずれかのアクションを実行して、試行時のSQL実行の時間制限を決定します。

    • 「5分」を選択します。

      この実行では、SQLチューニング・セット内の各SQL文が最大5分間実行され、パフォーマンス・データが収集されます。

    • 「無制限」を選択します。

      この実行では、SQLチューニング・セット内の各SQL文が完了するまで実行され、パフォーマンス・データが収集されます。実行統計を収集することによってパフォーマンス分析の精度は大幅に向上しますが、分析にかかる時間は長くなります。1つのSQL文によってタスクが長時間停止状態になる場合があるため、この設定は使用しないことをお薦めします。

    • 「カスタマイズ」を選択して、指定する秒数、分数、時間数を入力します。

  6. 「データベース・リンク」フィールドに、DBMS_SQLPAパッケージのEXECUTE権限およびテスト・システムのADVISOR権限を持つユーザーに接続しているパブリック・データベース・リンクのグローバル名を入力します。

    あるいは、検索アイコンをクリックしてデータベース・リンクを検索して選択するか、または「データベース・リンクの作成」ページで「データベース・リンクの作成」をクリックしてデータベース・リンクを作成します。

  7. 「比較メトリック」リストで、比較分析に使用する比較メトリックを選択します。

    • 経過時間

    • CPU時間

    • ユーザーI/O時間

    • バッファ読取り

    • 物理I/O

    • オプティマイザ・コスト

    • I/Oインターコネクト・バイト

    SQL試行で実行計画のみを生成した場合に選択可能な比較メトリックは「オプティマイザ・コスト」のみです。

    複数の比較メトリックを使用して比較分析を実行するには、異なるメトリックを使用してこの手順を繰り返すことによって比較分析を別々に実行します。

  8. 「スケジュール」で、次のように選択します。

    1. 「タイムゾーン」リストで、タイムゾーン・コードを選択します。

    2. 「即時」(即時にタスクを開始する場合)または、「後で」(「日付」および「時間」フィールドで指定した時間にタスクを開始するようスケジュールする場合)を選択します。

  9. 「発行」をクリックします。

    「SQLパフォーマンス・アナライザ」ページが表示されます。

    「SQLパフォーマンス・アナライザのタスク」セクションに、このタスクのステータスが表示されます。ステータス・アイコンをリフレッシュするには、「リフレッシュ」をクリックします。タスクが完了すると、「ステータス」フィールドが「完了」に変更されます。

  10. 「SQLパフォーマンス・アナライザのタスク」で、タスクを選択して「名前」列のリンクをクリックします。

    「SQLパフォーマンス・アナライザのタスク」ページが表示されます。

    このページには、次のセクションが含まれています。

    • SQLチューニング・セット

      このセクションには、SQLチューニング・セットに関する情報(名前、所有者、説明、SQLチューニング・セットに含まれているSQL文の数など)の概要が表示されます。

    • SQL試行

      このセクションには、SQLパフォーマンス・アナライザのタスクで使用されるSQL試行を示す表が含まれています。

    • SQL試行比較

      このセクションには、SQL試行比較の結果を示す表が含まれています。

  11. 「比較レポート」列のアイコンをクリックします。

    「SQLパフォーマンス・アナライザのタスク結果」ページが表示されます。

  12. パフォーマンス分析の結果を確認します。詳細は、「Oracle Enterprise Managerを使用したSQLパフォーマンス・アナライザ・レポートの確認」を参照してください。

    データベースのアップグレード後にパフォーマンスが低下したSQL文が検出された場合は、「データベースのアップグレードをテストした後のパフォーマンスが低下したSQL文のチューニング」に従って、それらのSQL文をチューニングします。

7.1.4.2 APIを使用した、Oracle9i DatabaseおよびOracle Database 10gリリース1からのデータベースのアップグレードのテスト

SQLパフォーマンス・アナライザのシステムでSQLパフォーマンス・アナライザのタスクを作成したら、APIを使用して、SQLチューニング・セット内の実行計画および実行時の統計からアップグレード前のSQL試行を作成できます。これを行うには、次のパラメータを使用して、EXECUTE_ANALYSIS_TASKプロシージャをコールします。

  • task_nameパラメータを、実行するSQLパフォーマンス・アナライザのタスクの名前に設定します。

  • execution_typeパラメータをCONVERT SQLSETに設定し、SQLチューニング・セット内の統計を試行実行として処理するようにSQLパフォーマンス・アナライザに指示します。

  • execution_nameパラメータを使用して、実行を識別するための名前を指定します。指定しなかった場合、SQLパフォーマンス・アナライザによってタスク実行の名前が自動的に生成されます。

次の例では、my_spa_taskというSQLパフォーマンス・アナライザのタスクを試行実行として実行します。

EXEC DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(task_name => 'my_spa_task', -
       execution_type => 'CONVERT SQLSET', - 
       execution_name => 'my_trial_9i');

APIを使用してアップグレード後のSQL試行を作成するには、EXECUTE_ANALYSIS_TASKプロシージャをコールすることによって、SQLパフォーマンス・アナライザのシステムを使用して実行計画またはテスト実行を行います。DATABASE_LINKタスク・パラメータをDBMS_SQLPAパッケージのEXECUTE権限およびテスト・システムのADVISOR権限を持つユーザーに接続しているパブリック・データベース・リンクのグローバル名に設定します。

EXPLAIN PLANを使用することを選択した場合、実行計画のみが生成されます。その後の比較では、パフォーマンスの変更に関して結論を出さずに、変更済の計画のリストを生成することのみが可能になります。TEST EXECUTEを使用することを選択した場合、SQLワークロードは完了するまで実行されます。これにより、テスト・システムから生成された統計と実行計画を使用して、アップグレード後のSQL試行が効果的に作成されます。ソースでSQL実行計画およびパフォーマンス・データを取得する場合は、より正確な分析を行えるように、TEST EXECUTEを使用することをお薦めします。

次の例では、データベース・リンクを介してSQL文のテスト実行をリモートで行います。

EXEC DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(task_name => 'my_spa_task', -
       execution_type => 'TEST EXECUTE', - 
       execution_name => 'my_remote_trial_10g', -
       execution_params => dbms_advisor.arglist('database_link',
                                                'LINK.A.B.C.BIZ.COM'));

7.2 Oracle Database 10gリリース2以上のリリースからのアップグレード

SQLパフォーマンス・アナライザを使用すると、本番システムでSQLチューニング・セットを取得し、データベース・リンクを介してSQLチューニング・セットをリモートで2回実行する(まず変更前のSQL試行を作成し、次に変更後のSQL試行を再度作成する)ことによって、Oracle Database 10gリリース2以上のリリースからそれ以上のリリースへのデータベースのアップグレードのSQLレスポンス時間に対する影響をテストできます。

アップグレード元となる本番システムで、Oracle Database 10gリリース2以上のリリースが実行されている必要があります。テスト・システムでは、最初に同じリリースが実行されている必要があります。SQLパフォーマンス・アナライザによって行われた分析が正確であることを保証するには、本番システムで検出されたデータの正確なコピーがテスト・システムに含まれている必要があります。また、ハードウェア構成は可能なかぎり本番システムと同じにする必要があります。

次に、Oracle Database 11gリリース2を実行している別のSQLパフォーマンス・アナライザ・システムを設定する必要があります。このシステムを使用して、SQLパフォーマンス・アナライザを実行します。このシステムでは、本番システムのSQLトレース・ファイルに格納されている統計を使用してSQLチューニング・セットが作成されるため、本番データおよびスキーマを使用できる必要はありません。SQLパフォーマンス・アナライザのタスクがテスト・システム上でリモートに実行され、指定したデータベース・リンクを介してSQL試行に対する実行計画および実行統計が生成されます。データベース・リンクは、DBMS_SQLPAパッケージのEXECUTE権限およびテスト・システムのADVISOR権限を持つユーザーに接続するパブリック・データベース・リンクである必要があります。また、テスト・システム上のユーザーのスキーマから既存のPLAN_TABLEを削除する必要もあります。

前述のとおりアップグレード環境を構成したら、Oracle Database 10g リリース2以上のリリースから以降のリリースへのデータベースのアップグレードでSQLパフォーマンス・アナライザを使用するために、次に説明する手順を実行します。

  1. 本番システムで、分析対象のSQLワークロードを取得して、SQLチューニング・セットに格納します。詳細は、「SQLワークロードの取得」を参照してください。

  2. 可能なかぎり本番環境と一致するようにテスト・システムを設定します。詳細は、「テスト・システムの設定」を参照してください。

  3. SQLチューニングセットをSQLパフォーマンス・アナライザのシステムに転送します。

    SQLチューニング・セットの転送については、使用するツールに応じて次のマニュアルを参照してください。

    • Oracle Enterprise Managerを使用する場合は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

    • APIを使用する場合は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

  4. SQLパフォーマンス・アナライザで、SQLチューニング・セットを入力ソースとして使用してSQLパフォーマンス・アナライザのタスクを作成します。

    テスト・システムで、データベース・リンクを介してSQLチューニング・セットのSQL文をリモートでテスト実行し、比較用のベースラインとして使用するアップグレード前のSQL試行を作成します。詳細は、「Oracle Database 10gリリース2以上のリリースからのデータベースのアップグレードのテスト」を参照してください。

  5. テスト・システムをアップグレードします。

  6. アップグレードしたテスト・システムで、データベース・リンクを介してSQL文をリモートで2回テスト実行し、アップグレード後のSQL試行を作成します。詳細は、「Oracle Database 10gリリース2以上のリリースからのデータベースのアップグレードのテスト」を参照してください。

  7. SQLパフォーマンスを比較し、パフォーマンスが低下したSQLを修正します。

    SQLパフォーマンス・アナライザでは、アップグレード前のSQL試行時にSQLチューニング・セットから読み取ったSQL文のパフォーマンスと、アップグレード後のSQL試行時にリモートのテスト実行によって取得したSQL文のパフォーマンスが比較されます。SQL文の実行計画またはパフォーマンスの変更内容を確認するためのレポートが生成されます。

    パフォーマンスが低下したSQL文がレポートに示された場合は、パフォーマンスが低下したSQL文を修正するためにさらに変更を行うことができます。詳細は、「データベースのアップグレードをテストした後のパフォーマンスが低下したSQL文のチューニング」を参照してください。

    SQLチューニング・セットの実行およびそのパフォーマンスと以前の実行のパフォーマンスとの比較を繰り返して、分析結果に満足するまで、行った変更をテストします。

7.2.1 Oracle Database 10gリリース2以上のリリースからのデータベースのアップグレードのテスト

SQLチューニング・セットをSQLパフォーマンス・アナライザ・システムに転送すると、SQLパフォーマンス・アナライザを使用して、テスト・システムでSQLチューニング・セット内のSQL文の計画を実行または生成し、アップグレード前の SQL試行を作成できます。SQLパフォーマンス・アナライザでは、テスト・システムにリモート接続し、SQL試行の実行計画と統計を生成することによって、指定したデータベース・リンクを使用してSQL文をテスト実行します。データベース・リンクは、SQLパフォーマンス・アナライザ・システムに存在し、テスト・システムでSQLチューニング・セットを実行する権限を持つリモート・ユーザーに接続されている必要があります。

SQL試行が作成されたら、テスト・システムをアップグレードする必要があります。データベースがアップグレードされたら、アップグレードしたテスト・システムで、SQLチューニング・セットに含まれるSQL文の2回目の実行または計画の生成を行い、アップグレード後の SQL試行を作成します。ハードウェア・リソースが使用可能な場合は、別の方法として、アップグレードした別のテスト・システムを使用して、2回目のリモートSQL試行を実行することもできます。この方法は、SQLパフォーマンス・アナライザによって特定された問題を調査する場合に役に立つことがあります。

SQLパフォーマンス・アナライザを実行し、Oracle Enterprise ManagerまたはAPIを使用し、Oracle Database 10g リリース2以上のリリースからのデータベースのアップグレードをテストすることができます。詳細は、次の項を参照してください。

7.2.1.1 Enterprise Managerを使用した、Oracle Database 10gリリース2以上のリリースからのデータベースのアップグレードのテスト

SQLパフォーマンス・アナライザを使用して、Oracle Database 10gリリース以上のリリースからのデータベースのアップグレードをテストするには、次の手順を実行します。

  1. 「ソフトウェアとサポート」ページの「Real Application Testing」で、「SQLパフォーマンス・アナライザ」をクリックします。

    「SQLパフォーマンス・アナライザ」ページが表示されます。

  2. SQLパフォーマンス・アナライザのワークフローで、「10.2または11gからのアップグレード」をクリックします。

    「10.2または11gからのアップグレード」ページが表示されます。

    spa_upgrade_102_11g.gifの説明が続きます。
    spa_upgrade_102_11g.gifの説明

  3. 「タスク情報」で、次のように指定します。

    1. 「タスク名」フィールドに、タスクの名前を入力します。

    2. 「SQLチューニング・セット」フィールドに、作成されたSQLチューニング・セットの名前を入力します。

      または、検索アイコンをクリックして、「検索と選択: SQLチューニング・セット」ウィンドウでSQLチューニング・セットを検索します。

      選択したSQLチューニング・セットが「SQLチューニング・セット」フィールドに表示されます。

    3. 「説明」フィールドに、オプションでタスクの説明を入力します。

  4. 「作成方法」フォールドで、次のように選択します。

    • SQLの実行: 実際にパブリック・データベース・リンクを介してテスト・システムでSQL文をリモートに実行することによって、SQLチューニング・セット内の各SQL文に対して実行計画と統計の両方を生成します。

    • 計画の生成: 実際にSQL文が実行されることなく、パブリック・データベース・リンクを介してテスト・システムで実行計画がリモートに作成されます。

  5. 「SQL当たりの時間制限」リストで、次のいずれかのアクションを実行して、試行時のSQL実行の時間制限を決定します。

    • 「5分」を選択します。

      この実行では、SQLチューニング・セット内の各SQL文が最大5分間実行され、パフォーマンス・データが収集されます。

    • 「無制限」を選択します。

      この実行では、SQLチューニング・セット内の各SQL文が完了するまで実行され、パフォーマンス・データが収集されます。実行統計を収集することによってパフォーマンス分析の精度は大幅に向上しますが、分析にかかる時間は長くなります。1つのSQL文によってタスクが長時間停止状態になる場合があるため、この設定は使用しないことをお薦めします。

    • 「カスタマイズ」を選択して、指定する秒数、分数、時間数を入力します。

  6. 「データベース・リンク」フィールドに、DBMS_SQLPAパッケージのEXECUTE権限およびアップグレード前のシステムのADVISOR権限を持つユーザーに接続しているパブリック・データベース・リンクのグローバル名を入力します。

    あるいは、検索アイコンをクリックしてデータベース・リンクを検索して選択するか、または「データベース・リンクの作成」ページで「データベース・リンクの作成」をクリックしてデータベース・リンクを作成します。

  7. 「アップグレード後の試行」で、次のように指定します。

    1. アップグレード前の試行とアップグレード後の試行の実行に同じシステムを使用するように、「アップグレード前の試行時と同じシステムを使用」を選択します。

      システム構成が異なることによって発生する可能性のあるエラーを回避するため、このオプションを使用することをお薦めします。このオプションを使用する場合は、テスト・データベースを上位データベースにアップグレードしてから、アップグレード後の試行を実行する必要があります。

    2. 「データベース・リンク」フィールドに、DBMS_SQLPAパッケージのEXECUTE権限およびアップグレード後のシステムのADVISOR権限を持つユーザーに接続しているパブリック・データベース・リンクのグローバル名を入力します。

  8. 「比較メトリック」リストで、比較分析に使用する比較メトリックを選択します。

    • 経過時間

    • CPU時間

    • ユーザーI/O時間

    • バッファ読取り

    • 物理I/O

    • オプティマイザ・コスト

    • I/Oインターコネクト・バイト

    SQL試行で実行計画のみを生成した場合に選択可能な比較メトリックは「オプティマイザ・コスト」のみです。

    複数の比較メトリックを使用して比較分析を実行するには、異なるメトリックを使用してこの手順を繰り返すことによって比較分析を別々に実行します。

  9. 「スケジュール」で、次のように選択します。

    1. 「タイムゾーン」リストで、タイムゾーン・コードを選択します。

    2. 「即時」(即時にタスクを開始する場合)または、「後で」(「日付」および「時間」フィールドで指定した時間にタスクを開始するようスケジュールする場合)を選択します。

  10. 「発行」をクリックします。

    「SQLパフォーマンス・アナライザ」ページが表示されます。

    「SQLパフォーマンス・アナライザのタスク」セクションに、このタスクのステータスが表示されます。ステータス・アイコンをリフレッシュするには、「リフレッシュ」をクリックします。

    アップグレード前の試行とアップグレード後の試行の実行に同じシステムを使用している場合は、アップグレード前の試行の手順を完了した後で、データベースをアップグレードする必要があります。データベースをアップグレードした後、アップグレード後の試行を実行できます。タスクが完了すると、「ステータス」フィールドが「完了」に変更されます。

  11. 「SQLパフォーマンス・アナライザのタスク」で、タスクを選択して「名前」列のリンクをクリックします。

    「SQLパフォーマンス・アナライザのタスク」ページが表示されます。

    このページには、次のセクションが含まれています。

    • SQLチューニング・セット

      このセクションには、SQLチューニング・セットに関する情報(名前、所有者、説明、SQLチューニング・セットに含まれているSQL文の数など)の概要が表示されます。

    • SQL試行

      このセクションには、SQLパフォーマンス・アナライザのタスクで使用されるSQL試行を示す表が含まれています。

    • SQL試行比較

      このセクションには、SQL試行比較の結果を示す表が含まれています。

  12. 「比較レポート」列のアイコンをクリックします。

    「SQLパフォーマンス・アナライザのタスク結果」ページが表示されます。

  13. パフォーマンス分析の結果を確認します。詳細は、「Oracle Enterprise Managerを使用したSQLパフォーマンス・アナライザ・レポートの確認」を参照してください。

    データベースのアップグレード後にパフォーマンスが低下したSQL文が検出された場合は、「データベースのアップグレードをテストした後のパフォーマンスが低下したSQL文のチューニング」に従って、それらのSQL文をチューニングします。

7.2.1.2 APIを使用した、Oracle Database 10gリリース2以上のリリースからのデータベースのアップグレードのテスト

SQLパフォーマンス・アナライザのシステムでSQLパフォーマンス・アナライザのタスクを作成したら、APIを使用して、SQLチューニング・セットに含まれているSQL文の実行計画またはテスト実行を行ってアップグレード前のSQL試行を作成できます。これを行うには、次のパラメータを使用して、EXECUTE_ANALYSIS_TASKプロシージャをコールします。

  • task_nameパラメータを、実行するSQLパフォーマンス・アナライザのタスクの名前に設定します。

  • execution_typeパラメータをEXPLAIN PLANまたはTEST EXECUTEに設定します。

    EXPLAIN PLANを使用することを選択した場合、実行計画のみが生成されます。その後の比較では、パフォーマンスの変更に関して結論を出さずに、変更済の計画のリストを生成することのみが可能になります。TEST EXECUTEを使用することを選択した場合、SQLワークロードは完了するまで実行されます。これにより、テスト・システムから生成された統計と実行計画を使用して、アップグレード前のSQL試行が効果的に作成されます。ソースでSQL実行計画およびパフォーマンス・データを取得する場合は、より正確な分析を行えるように、TEST EXECUTEを使用することをお薦めします。

  • execution_nameパラメータを使用して、実行を識別するための名前を指定します。指定しなかった場合、SQLパフォーマンス・アナライザによってタスク実行の名前が自動的に生成されます。

  • DATABASE_LINKタスク・パラメータをDBMS_SQLPAパッケージのEXECUTE権限およびテスト・システムのADVISOR権限を持つユーザーに接続しているパブリック・データベース・リンクのグローバル名に設定します。

次の例では、my_spa_taskというSQLパフォーマンス・アナライザのタスクを実行し、データベース・リンクを介してSQL文のテスト実行をリモートで行います。

EXEC DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(task_name => 'my_spa_task', -
       execution_type => 'TEST EXECUTE', - 
       execution_name => 'my_remote_trial_10g', -
       execution_params => dbms_advisor.arglist('database_link',
                                                'LINK.A.B.C.BIZ.COM'));

APIを使用してアップグレード後のSQL試行を作成する場合は、DBMS_SQLPAパッケージのEXECUTE権限およびテスト・システムのADVISOR権限を持つユーザーに接続しているパブリック・データベース・リンクのグローバル名に設定したDATABASE_LINKタスク・パラメータを使用してEXECUTE_ANALYSIS_TASKプロシージャをコールすることによって、SQLパフォーマンス・アナライザのシステムを使用して実行計画またはテスト実行を行います。EXPLAIN PLANを使用することを選択した場合、実行計画のみが生成されます。その後の比較では、パフォーマンスの変更に関して結論を出さずに、変更済の計画のリストを生成することのみが可能になります。TEST EXECUTEを使用することを選択した場合、SQLワークロードは完了するまで実行されます。これにより、テスト・システムから生成された統計と実行計画を使用して、アップグレード後のSQL試行が効果的に作成されます。ソースでSQL実行計画およびパフォーマンス・データを取得する場合は、より正確な分析を行えるように、TEST EXECUTEを使用することをお薦めします。

次の例では、データベース・リンクを介してSQL文のテスト実行をリモートで行います。

EXEC DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(task_name => 'my_spa_task', -
       execution_type => 'TEST EXECUTE', - 
       execution_name => 'my_remote_trial_11g', -
       execution_params => dbms_advisor.arglist('database_link',
                                                'LINK.A.B.C.BIZ.COM'));

7.3 データベースのアップグレードをテストした後のパフォーマンスが低下したSQL文のチューニング

テスト・システムのデータベースをアップグレードした後に、パフォーマンスが低下したSQL文をSQLパフォーマンス・アナライザで特定する場合があります。

第6章「SQL試行の比較」で説明するとおり、SQLチューニング・アドバイザまたはSQL計画ベースラインを使用して、パフォーマンスが低下したSQL文をチューニングできます。これには、パフォーマンスが低下したSQL文だけを含むSQLチューニング・セットのサブセットを作成し、このパフォーマンスが低下したSQL文のサブセットをリモート・データベースに転送するためのAPIの使用、およびリモート・データベースでのSQLチューニング・アドバイザの実行が含まれます。

Oracle Enterprise Managerでは、1つ以上のSQL試行を含むSQLパフォーマンス・アナライザを実行した後、パフォーマンスの低下を修正することはできません。詳細は、「APIを使用した、リモートSQL試行からのパフォーマンスが低下したSQL文のチューニング」を参照してください。

Oracle Database 10gリリース2以上のリリースからアップグレードする場合は、将来、既存の実行計画を選択するようにオプティマイザに指示するためのSQL計画ベースラインを作成することもできます。詳細は、「APIを使用した、SQL計画ベースラインの作成」を参照してください。