1. Testingガイド
  2. データベース・リプレイ
  3. データベース統合リプレイの使用

15 データベース統合リプレイの使用

データベース・リプレイでは、本番システムのワークロードを取得し、テスト・システムでそれをリプレイすることができます。これは、本番システムに変更の影響を与えずにテストできるので、新しいデータベース・テクノロジを評価したり採用するときに非常に便利です。ただし、テスト対象の新しいシステムのパフォーマンスが既存のシステムよりも大幅に高い場合、データベース・リプレイでは、新しいシステムでさらにどの程度ワークロードを追加処理できるか正確に予測できない場合があります。

たとえば、複数の本番システムを1つのOracle Exadataマシンに統合する場合、1つの既存のシステムから取得したワークロードをOracle Exadataマシンでリプレイすると、新しいシステムの方が強力であるため、リソースの使用率(ホストCPUやI/Oなど)が低くなる場合があります。このような場合には、1つのシステムの1つのワークロードではなく、すべての既存のシステムのワークロードを統合したものを新しいシステムがどのように処理するか評価するのが有用です。

データベース統合リプレイでは、1つ以上のシステムから取得した複数のワークロードを統合し、1つのテスト・システムで同時にリプレイできます。この例では、データベース統合リプレイを使用し、データベースの統合がどのように本番システムに影響を与えるか、また1つのOracle Exadataマシンで統合データベースのワークロードを処理できるか評価できます。

この章では、次の内容で、データベース統合リプレイの使用方法について説明します。

15.1 データベース統合リプレイの使用事例

データベース統合リプレイでは、1つ以上のシステムから取得した複数のワークロードを同時にリプレイできます。統合リプレイでリプレイが開始されると、統合されたすべてのワークロード取得のリプレイが開始されます。

データベース統合リプレイのいくつかの典型的な使用事例は次のとおりです。

これらのいずれの使用事例も、この章で説明する手順を使用して実行できます。さらに、データベース統合リプレイの使用時には、様々なワークロードのスケールアップ・テクニックを採用できます。詳細は、「ワークロード・スケールアップの使用」を参照してください。

15.1.1 プラガブル・データベースを使用したデータベースの統合

データベース統合リプレイの1つの用途は、統合したデータベースのワークロードをシステムが処理できるか評価することです。

たとえば、CRM、ERPおよびSCMアプリケーションのデータベースをプラガブル・データベース(PDB)に移行してデータベースを統合するとします。データベース統合リプレイを使用すると、3つのアプリケーションから取得したワークロードを統合し、PDBで同時にリプレイできます。

関連項目:

この使用事例については、「例: APIを使用した統合済ワークロードのリプレイ」を参照してください

15.1.2 ストレス・テスト

データベース統合リプレイは、ストレス・テストまたはキャパシティ・プランニングにも使用できます。

たとえば、連休の時期に営業アプリケーションのワークロードが倍になると予想されるとします。この場合、データベース統合リプレイを使用し、ワークロードを倍にし統合したワークロードをリプレイして、システムに対する追加の負荷をテストできます。

関連項目:

この使用事例については、「タイム・シフトの使用」を参照してください

15.1.3 スケールアップ・テスト

データベース統合リプレイの3つ目の用途は、スケールアップ・テストです。

たとえば、財務のアプリケーションと注文のアプリケーションの取得済ワークロードをシステムで同時に処理できるかテストしたいとします。この場合、データベース統合リプレイを使用し、ワークロードを統合しそれらを同時にリプレイして、スケールアップしたワークロードのシステムに対する追加の負荷の影響をテストできます。

関連項目:

15.2 データベース統合リプレイの使用手順

この項では、統合済ワークロード・リプレイを使用する場合に含まれる手順を説明します。次の項目が含まれます。

15.2.1 データベース統合リプレイ用のデータベース・ワークロードの取得

データベース統合リプレイ用にデータベース・ワークロードを取得するには、特別な手順は必要ありません。データベース・ワークロードを取得する手順は、データベース・リプレイで単一のワークロードを取得する手順とまったく同じです。詳細は、「データベース・ワークロードの取得」を参照してください。

この項では、データベース統合リプレイに固有なワークロードの取得に関して、次の内容で説明します。

15.2.1.1 サポートされているタイプのワークロード取得
データベース統合リプレイでは、1つ以上のオペレーティング・システム上のOracle Database 9iリリース2(リリース9.2.0.8.0)以上で実行される、1つ以上のシステムから取得された複数のワークロードがサポートされています。たとえば、HP-UX上で実行されるOracle Database 9iリリース2(リリース9.2.0.8.0)を実行するシステムから取得したワークロードと、AIX上で実行されるOracle Database 10gリリース2(リリース10.2.0.4.0)を実行する別のシステムから取得したワークロードを使用できます。

注意:

データベース統合リプレイは、Oracle Database 11gリリース2(リリース11.2.0.2.0)以上のみで使用できます。

15.2.1.2 取得サブセット
データベース統合リプレイでは、取得した既存のワークロードを、新しい小さな取得サブセットに変換することができます。その後、「データベース統合リプレイの使用事例」で説明されているように、別の使用事例で使用できる取得サブセットから、新しいワークロード取得を生成できます。

取得サブセットとは、時間範囲を適用して既存の1つのワークロード取得から定義された1つのワークロード取得の部分です。時間範囲は、ワークロード取得の開始からのオブセットとして指定します。指定した時間範囲に取得されたすべてのユーザー・ワークロードは、定義した取得サブセットに含まれます。

たとえば、午前2時から午後8時までのワークロードを取得し、ワークロードのピークが午前10時から午後4時だと特定されたとします。このとき、ワークロードの開始から8時間後(または午前10時)に開始し、ワークロードの開始から14時間後(または午後4時)に終了する時間範囲をワークロードのピークとして適用して、取得サブセットを定義できます。

ただし、指定した時間範囲に記録されたユーザー・ワークロードのみを取得サブセットに含める場合、指定した時間範囲よりも前に発生したユーザー・ログインは記録されないことになります。リプレイでこれらのユーザー・ログインが必要な場合、その取得サブセットはリプレイできません。たとえば、取得サブセットに指定した時間範囲が午前10時00分から午後4時であり、ユーザー・セッションが午前9時30分に開始され午前10時30分に終了した場合、午前9時30分のユーザー・ログインがワークロードに含まれないと、リプレイは失敗します。また、ユーザー・セッションが午後3時30分に開始し午後4時30分までに完了しない場合、指定した時間範囲には一部のみしか記録されず、ユーザー・コールが不完全になります。

データベース統合リプレイでは、指定した時間範囲の開始時間のみが原因でユーザー・コールが不完全になる場合、これを含めるようにしてこの問題を解決しています。ワークロード取得が縮小されている場合、同じ不完全なユーザー・コールが2度含まれるのを避けるために、終了時間が原因でユーザー・コールが不完全となるものはデフォルトでは含めないようになっています。したがって、基本的に取得サブセットとは、正常なリプレイに必要な、指定した時間範囲に記録されたユーザー・コールの最少数で、必要なユーザー・ログイン、ALTER SESSION文、および開始時間が原因で不完全となってしまうユーザー・コールはこれに含まれます。

関連項目:

「APIを使用した取得サブセットの生成」

15.2.2 データベース統合リプレイ用のテスト・システムの設定

データベース統合リプレイ用のテスト・システムの設定は、データベース・リプレイ用のテスト・システムの設定と同様です。ただし、データベース統合リプレイ用にリプレイ・データベースを設定する場合には、他に考慮する必要のある事項があります。データベース・リプレイ用のテスト・システムの設定の詳細は、「データベース・ワークロードのリプレイの手順」を参照してください。

リプレイ中の相違を最小限に抑えるには、テスト・システムには同じアプリケーション・データが必要であり、アプリケーション・データの状態は、ワークロードをそれぞれ取得開始したときの取得システムのデータの状態と論理的に同じにする必要があります。ただし、取得が統合されている場合、様々な本番システムのワークロード取得が複数含まれている可能性があるため、テスト・システムをすべての取得に対応するよう設定する必要があります。この場合、各データベースが取得の開始時に取得システムと同等のデータを持つように、マルチテナント・アーキテクチャを使用して複数データベースを統合することをお薦めします。

データベース統合リプレイを行うには、関係しているすべてのワークロード取得を、テスト・システムの新しい取得ディレクトリの下に配置する必要があります。ワークロード取得をすべて新しい取得ディレクトリにコピーするか、元のワークロード取得をポイントするシンボリック・リンクを作成します。ワークロード取得を統合する前に、新しい取得ディレクトリに関係するすべての取得を格納する十分な空き領域があることを確認します。

図15-1に、3つのワークロード取得を統合するテスト・システムと新しい取得ディレクトリを設定する方法を示します。

図15-1 データベース統合リプレイ用のテスト・システムの設定

図15-1の説明が続きます
「図15-1 データベース統合リプレイ用のテスト・システムの設定」の説明

関連項目:

15.2.3 データベース統合リプレイ用のデータベース・ワークロードの前処理

データベース統合リプレイ用のデータベース・ワークロードの事前処理は、データベース・リプレイ用のデータベース・ワークロードの事前処理と同様です。データベース・リプレイ用のデータベース・ワークロードの事前処理の詳細は、「データベース・ワークロードの事前処理」を参照してください。

データベース統合リプレイを行うには、取得した各ワークロードをその固有のディレクトリに前処理します。前処理を行う際には、別のワークロード取得を1つのディレクトリにまとめないようにする必要があります。取得済ワークロードの前処理は、ワークロードをリプレイするテスト・システムのOracle Databaseと同じバージョンのデータベースを使用して実行する必要があります。

15.2.4 データベース統合リプレイ用のデータベース・ワークロードのリプレイ

データベース統合リプレイで統合されたワークロードのリプレイは、データベース・リプレイで1つのデータベース・ワークロードをリプレイすることとは大きく異なります。

この項では、データベース統合リプレイに固有なワークロードのリプレイに関して、次の内容で説明します。

15.2.4.1 リプレイ・スケジュールの定義
リプレイ・スケジュールでは、1つまたは複数のワークロード取得を統合リプレイに追加し、取得のリプレイ開始順序を指定します。リプレイ・スケジュールは、統合リプレイを初期化する前に作成する必要があります。1回の統合リプレイには、複数のリプレイ・スケジュールを定義できます。リプレイの初期化時、既存のリプレイ・スケジュールの中から任意のものを選択できます。

リプレイ・スケジュールでは、2種類の操作が実行されます。

関連項目:

「APIを使用したリプレイ・スケジュールの定義」

15.2.4.1.1 ワークロード取得の追加

リプレイ・スケジュールでは、最初に関係するワークロード取得がリプレイに追加されます。

リプレイ・スケジュールにワークロード取得が追加されると、そのワークロード取得を識別する一意の番号が返されます。ワークロード取得には、追加のたびに別の番号が割り当てられるので、複数回リプレイ・スケジュールに追加することが可能です。リプレイ・スケジュールでは、追加のたびに取得をコピーしてディスク領域を無駄にしないために、都度同じ取得ディレクトリをポイントします。

関連項目:

「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」

15.2.4.1.2 スケジュールの順序の追加

次いで、リプレイ・スケジュールには、関係するワークロード取得のリプレイ時開始順序が追加されます。

スケジュール順序では、リプレイ・スケジュールに追加された2つのワークロード取得の開始順序が定義されます。リプレイ・スケジュールには、複数のスケジュール順序を追加できます。たとえば、リプレイ・スケジュールにワークロード取得が3つ追加されているとします。追加した1つのスケジュール順序では、取得2は取得1が完了してから開始するよう指定します。別のスケジュール順序では、取得3は取得1が完了してから開始するよう指定します。この場合、取得2も取得3も取得1が完了するのを待機してから開始する必要があります。

リプレイ・スケジュールには、必ずしもスケジュール順序を含める必要はありません。この場合、リプレイ・スケジュール内の関係するすべてのワークロード取得は、統合リプレイの開始時に同時にリプレイが開始されます。

関連項目:

「APIを使用したリプレイ・スケジュールへのスケジュール順序の追加」

15.2.4.2 データベース統合リプレイ用の接続の再マッピング
データベース・リプレイを使用して1つのデータベース・ワークロードをリプレイする場合と同様に、本番システムに接続するために使用した取得した接続文字列を使用してリプレイ・システムに再マッピングする必要があります。詳細は、「接続の再マッピング」を参照してください。

データベース統合リプレイを行うには、複数のワークロード取得の取得済接続文字列をリプレイ時に別の接続文字列に再マッピングする必要があります。

関連項目:

「APIを使用した接続の再マッピング」

15.2.4.3 データベース統合リプレイ用のユーザーの再マッピング
データベース・リプレイを使用して1つのデータベース・ワークロードをリプレイする場合と同様に、本番システムに接続するために使用するデータベースのユーザー名およびスキーマはリプレイ時に再マッピングできます。詳細は、「ユーザーの再マッピング」を参照してください。

データベース統合リプレイの場合には、リプレイ時に、複数のワークロード取得からの取得済ユーザーを別のユーザーまたはスキーマに再マッピングするよう選択できます。

関連項目:

「APIを使用したユーザーの再マッピング」

15.2.4.4 データベース統合リプレイの準備
データベース・リプレイを使用した1つのデータベース・ワークロードのリプレイの場合と同様に、リプレイ・オプションはリプレイの準備時に定義します。詳細は、「リプレイ・オプションの指定」を参照してください。

データベース統合リプレイでは、統合リプレイ内のすべての関係しているワークロード取得は、リプレイの準備時に定義された同じリプレイ・オプションを使用してリプレイされます。

関連項目:

「APIを使用したデータベース統合リプレイの準備」

15.2.4.5 個々のワークロードのリプレイ
統合ワークロードをリプレイする前に、関係するワークロードを個々にリプレイすることをお薦めします。詳細は、「データベース・ワークロードのリプレイ」を参照してください。

個々にリプレイすることによって各ワークロード取得のベースライン・パフォーマンスを定めて、統合リプレイのパフォーマンスの分析に使用できます。

15.2.5 データベース統合リプレイのレポート作成および分析

データベース統合リプレイのレポート作成および分析は、リプレイの期間比較レポートを使用して実行されます。詳細は、「リプレイの期間比較レポートの使用」を参照してください。

データベース統合リプレイのリプレイの期間比較レポートには、個々のワークロード取得のアクティブ・セッション履歴(ASH)データがあり、ワークロード取得のASHデータが統合リプレイのフィルタされたASHデータと比較されています。このレポートを使用すると、同じ統合されているワークロード取得のリプレイを比較できます。

データベース統合リプレイのリプレイの期間比較レポートでは、統合リプレイを複数の取得とリプレイの比較として扱います。このレポートのサマリー・セクションには、取得とリプレイの比較を個々にまとめた表があります。このセクションの情報を確認すると、統合リプレイがどのように実行されたかの概要を理解できます。

図15-2に、データベース統合リプレイのサンプル・リプレイ期間比較レポートのサマリー・セクションを示します。

図15-2 期間比較レポート: 統合リプレイ

図15-2の説明が続きます
「図15-2 期間比較レポート: 統合リプレイ」の説明

このレポートの残りのセクションは、リプレイの期間比較レポートのASHデータ比較セクションと似ており、統合リプレイ内のすべての取得とリプレイのレポートを結合したもので構成されています。このセクションの詳細は、「ASHデータ比較」を参照してください。

15.3 Enterprise Managerを使用したデータベース統合リプレイの使用

この項では、Enterprise Managerを使用してデータベース統合リプレイを使用する方法について説明します。

Oracle Enterprise Managerは、統合されたデータベース・ワークロードをリプレイする主要ツールです。Oracle Enterprise Managerを使用できない場合は、「APIを使用したデータベース統合リプレイの使用」で説明されているように、APIを使用して統合されたデータベース・ワークロードをリプレイすることもできます。

統合されたデータベース・ワークロードをリプレイするプロセスは、単一のデータベース・ワークロードをリプレイするプロセスとほとんど同じです。違いは、次の項の単一のリプレイの手順で説明されています。

次のリストは、統合されたデータベース・ワークロードのリプレイと単一のデータベース・ワークロードのリプレイの違いのサマリーを示します。

  • リプレイ・タスクを作成する際、2つ以上の取得済ワークロードをタスクの作成ページの取得の選択表から選択する必要があります。

  • ウィザードの「取得されたワークロードの前処理: ワークロードのコピー」ステップには、「取得名」ドロップダウンの複数の選択肢があるため、ワークロード・ディレクトリの現在の場所の複数の資格証明を入力する必要がある場合があります。

  • ウィザードの「取得されたワークロードの前処理: ディレクトリを選択」ステップでは、単一のリプレイで表示されるように「取得サマリー」が表示されません。

  • ウィザードの「ワークロード・リプレイ: ワークロードのコピー」ステップには、「取得名」ドロップダウンの複数の選択肢があるため、ワークロード・ディレクトリの現在の場所の複数の資格証明を入力する必要がある場合があります。

  • ウィザードの「ワークロード・リプレイ: ディレクトリを選択」ステップでは、単一のリプレイで表示されるように「取得サマリー」が表示されません。

  • ウィザードの「ワークロード・リプレイ: 初期化オプション」ステップでは、「ソースを指定」セクションは表示されません。

  • ウィザードの「ワークロード・リプレイ: オプションのカスタマイズ」ステップの「接続マッピング」の「取得名」ドロップダウンには、1つ以上の選択肢が表示されるので、取得したワークロードの接続をそれぞれ再マッピングできます。1つの接続記述子またはネット・サービス名を使用することはできません。

15.4 APIを使用したデータベース統合リプレイの使用

この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して統合済ワークロードを作成およびリプレイする方法を説明します。「Enterprise Managerを使用したデータベース統合リプレイの使用」で説明されているように、Oracle Enterprise Managerを使用して統合されているワークロードを作成およびリプレイすることもできます。

APIを使用して統合されているワークロードを作成およびリプレイする手順は、次などの複数の手順を実行する必要があります。

関連項目:

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

15.4.1 APIを使用した取得サブセットの生成

この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、既存のワークロード取得から取得サブセットを生成する方法を説明します。取得サブセットの詳細は、「取得サブセット」を参照してください。

既存のワークロード取得から取得サブセットを生成するには、次の手順に従います。

  1. GENERATE_CAPTURE_SUBSETプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.GENERATE_CAPTURE_SUBSET (
   input_capture_dir        IN VARCHAR2,
   output_capture_dir       IN VARCHAR2,
   new_capture_name         IN VARCHAR2,
   begin_time               IN NUMBER,
   begin_include_incomplete IN BOOLEAN   DEFAULT TRUE,
   end_time                 IN NUMBER,
   end_include_incomplete   IN BOOLEAN   DEFAULT FALSE,
   parallel_level           IN NUMBER    DEFAULT NULL);

  2. input_capture_dirパラメータを、既存のワークロード取得をポイントするディレクトリ・オブジェクト名に設定します。

  3. output_capture_dirパラメータを、新しいワークロード取得を格納する空のディレクトリをポイントするディレクトリ・オブジェクト名に設定します。

  4. new_capture_nameパラメータを、生成する新しいワークロード取得の名前に設定します。

  5. 任意指定の他のパラメータを適宜設定します。

    これらのパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

この例では、ディレクトリ・オブジェクトrec_dirの既存のワークロード取得からpeak_wkldという取得サブセットをディレクトリ・オブジェクトpeak_capdirに作成する方法を説明します。取得サブセットには、ワークロードの取得の開始から2時間(または7,200秒)から3時間(または10,800秒)のワークロードが含まれています。 

EXEC DBMS_WORKLOAD_REPLAY.GENERATE_CAPTURE_SUBSET ('rec_dir', 'peak_capdir',
     'peak_wkld', 7200, TRUE, 10800, FALSE, 1);

関連項目:

GENERATE_CAPTURE_SUBSETプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

15.4.2 APIを使用した統合リプレイ・ディレクトリの設定

この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、テスト・システムに統合リプレイ・ディレクトリを設定する方法を説明します。統合リプレイ・ディレクトリを、統合およびリプレイするワークロード取得を含むテスト・システムのディレクトリに設定します。テスト・システムの設定の詳細は、「データベース統合リプレイ用のテスト・システムの設定」を参照してください。

リプレイ・ディレクトリを設定するには、次の手順に従います。

  1. SET_CONSOLIDATED_DIRECTORYプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.SET_CONSOLIDATED_DIRECTORY (
   replay_dir IN VARCHAR2);

  2. replay_dirパラメータをワークロードの統合に使用するワークロード取得を含むオペレーティング・システム・ディレクトリをポイントするディレクトリ・オブジェクト名に設定します。

ヒント:

SET_REPLAY_DIRECTORYプロシージャは非推奨で、SET_CONSOLIDATED_DIRECTORYプロシージャに置き換えられます。

この例では、リプレイ・ディレクトリをrep_dirという名前のディレクトリ・オブジェクトに設定する方法を示します。 

EXEC DBMS_WORKLOAD_REPLAY.SET_CONSOLIDATED_DIRECTORY ('rep_dir');

また、DBMS_WORKLOAD_REPLAYパッケージを使用してSET_CONSOLIDATED_DIRECTORYプロシージャによって設定された現在の統合リプレイ・ディレクトリを参照することもできます。

設定されている現在の統合リプレイ・ディレクトリを確認するには、次の手順を実行します。

  • GET_REPLAY_DIRECTORYファンクションを使用します。 

    DBMS_WORKLOAD_REPLAY.GET_REPLAY_DIRECTORY RETURN VARCHAR2;

    統合リプレイ・ディレクトリが設定されていない場合、ファンクションでNULLが返されます。

関連項目:

15.4.3 APIを使用したリプレイ・スケジュールの定義

この項では、DBMS_WORKLOAD_REPLAYパッケージを使用してリプレイ・スケジュールを定義する方法を説明します。リプレイ・スケジュールの詳細は、「リプレイ・スケジュールの定義」を参照してください。

リプレイ・スケジュールを定義する前に、次の前提条件が満たされていることを確認します。

  • すべてのワークロード取得は、「データベース・ワークロードの事前処理」で説明しているように、リプレイ・システムと同じデータベース・バージョンを実行しているシステムで、PROCESS_CAPTUREプロシージャを使用して前処理されています。

  • すべての取得ディレクトリは、リプレイ・システムのリプレイ・ディレクトリにコピー済です。

  • 「APIを使用した統合リプレイ・ディレクトリの設定」で説明されているように、リプレイ・ディレクトリがSET_REPLAY_DIRECTORYプロシージャを使用して設定済です。

  • データベースが、リプレイ・モードの状態ではありません。

リプレイ・スケジュールを定義するには、次の手順に従います。

  1. 「APIを使用したリプレイ・スケジュールの作成」で説明されているように、新しいリプレイ・スケジュールを作成します。

  2. 「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、リプレイ・スケジュールにワークロード取得を追加します。

  3. 「APIを使用したリプレイ・スケジュールへのスケジュール順序の追加」で説明されているように、リプレイ・スケジュールにスケジュール順序を追加します。

  4. 「APIを使用したリプレイ・スケジュールの保存」で説明されているように、リプレイ・スケジュールを保存します。

15.4.3.1 APIを使用したリプレイ・スケジュールの作成
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用してリプレイ・スケジュールを作成する方法を説明します。リプレイ・スケジュールの詳細は、「リプレイ・スケジュールの定義」を参照してください。

リプレイ・スケジュールを作成するには、次の手順に従います。

  1. BEGIN_REPLAY_SCHEDULEプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE (
   schedule_name  IN VARCHAR2);

  2. schedule_nameパラメータをこのリプレイ・スケジュールの名前に設定します。

注意:

BEGIN_REPLAY_SCHEDULEプロシージャでは、再利用可能なリプレイ・スケジュールの作成を開始します。リプレイ・スケジュールは1度に1つのみ定義できます。リプレイ・スケジュールの定義中にこのプロシージャを呼び出すと、エラーが発生します。

この例に、peak_scheduleというリプレイ・スケジュールを作成する方法を説明します。 

EXEC DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ('peak_schedule');

関連項目:

BEGIN_REPLAY_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

15.4.3.2 APIを使用したリプレイ・スケジュールへのワークロード取得の追加
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、リプレイ・スケジュールにワークロード取得を追加および削除する方法を説明します。リプレイ・スケジュールにワークロード取得を追加する方法の詳細は、「ワークロード取得の追加」を参照してください。

リプレイ・スケジュールにワークロード取得を追加する前に、次の前提条件が満たされていることを確認します。

リプレイ・スケジュールにワークロード取得を追加するには、次の手順に従います。

  1. ADD_CAPTUREファンクションを使用します。 

    DBMS_WORKLOAD_REPLAY.ADD_CAPTURE (
   capture_dir_name    IN VARCHAR2,
   start_delay_seconds IN NUMBER  DEFAULT 0,
   stop_replay         IN BOOLEAN DEFAULT FALSE,
   take_begin_snapshot IN BOOLEAN DEFAULT FALSE,
   take_end_snapshot   IN BOOLEAN DEFAULT FALSE,
   query_only          IN BOOLEAN DEFAULT FALSE)
RETURN NUMBER;

    DBMS_WORKLOAD_REPLAY.ADD_CAPTURE (
   capture_dir_name    IN VARCHAR2,
   start_delay_seconds IN NUMBER,
   stop_replay         IN VARCHAR2,
   take_begin_snapshot IN VARCHAR2 DEFAULT 'N',
   take_end_snapshot   IN VARCHAR2 DEFAULT 'N',
   query_only          IN VARCHAR2 DEFAULT 'N')
RETURN NUMBER;

    このファンクションでは、このリプレイ・スケジュール内でワークロード取得を識別する一意の識別子が返されます。

    参照:

    問合せのみのデータベース・リプレイについては、「問合せのみのデータベース・リプレイについて」を参照してください。

    注意:

    問合せのみのデータベース・リプレイはテスト環境でのみ使用され、実行されます。

    • 問合せのみのデータベース・リプレイを本番システムで使用しないでください。

    • 問合せのみのデータベース・リプレイ中に相違が起こる可能性があります。

  2. capture_dir_nameパラメータを上位レベルのリプレイ・ディレクトリにある取得したワークロードをポイントするディレクトリ・オブジェクト名に設定します。

    このディレクトリには、リプレイ・システムと同じデータベース・バージョンを実行しているシステムで前処理された有効なワークロード取得が含まれている必要があります。

  3. 任意指定の他のパラメータを適宜設定します。

    これらのパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

次の例に、SELECT文でADD_CAPTUREファンクションを使用して、リプレイ・スケジュールにpeak_wkldというワークロード取得を追加する方法を示します。 

SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('peak_wkld')
  FROM dual;

リプレイ・スケジュールからワークロード取得を削除する場合、DBMS_WORKLOAD_REPLAYパッケージを使用することも可能です。

リプレイ・スケジュールからワークロード取得を削除するには、次の手順に従います。

  1. REMOVE_CAPTUREプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.REMOVE_CAPTURE (
   schedule_capture_number IN NUMBER);

  2. schedule_capture_numberパラメータを、このリプレイ・スケジュールのワークロード取得を識別する一意の識別子に設定します。

    この一意の識別子は、ワークロード取得がリプレイ・スケジュールに追加された際に、ADD_CAPTUREファンクションによって返された識別子と同じです。

関連項目:

15.4.3.3 APIを使用したリプレイ・スケジュールへのスケジュール順序の追加
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、スケジュール順序をリプレイ・スケジュールから削除および追加する方法を説明します。リプレイ・スケジュールにスケジュール順序を追加する方法の詳細は、「スケジュール順序の追加」を参照してください。

リプレイ・スケジュールにスケジュール順序を追加する前に、次の前提条件が満たされていることを確認します。

注意:

リプレイ・スケジュールにはスケジュール順序を必ずしも追加する必要はありません。リプレイ・スケジュールにスケジュール順序を追加しない場合、統合リプレイが開始されるとき、リプレイ・スケジュールに追加されたすべてのワークロード取得が同時にリプレイされます。

リプレイ・スケジュールにスケジュール順序を追加するには、次の手順に従います。

  1. ADD_SCHEDULE_ORDERINGファンクションを使用します。 

    DBMS_WORKLOAD_REPLAY.ADD_SCHEDULE_ORDERING (
   schedule_capture_id IN NUMBER,
   waitfor_capture_id IN NUMBER)
RETURN NUMBER;

    このファンクションでは、リプレイ・スケジュールに追加された2つのワークロード取得間にスケジュール順序を追加します。スケジュール順序を追加できない場合、ゼロではないエラー・コードが返されます。

  2. このスケジュール順序で待機するワークロード取得にschedule_capture_idパラメータを設定します。

  3. このスケジュール順序で他のワークロード取得が開始される前に、完了するワークロード取得をwait_for_capture_idパラメータに設定します。

DBMS_WORKLOAD_REPLAYパッケージを使用して、リプレイ・スケジュールからスケジュール順序を削除することも可能です。

リプレイ・スケジュールからスケジュール順序を削除するには、次の手順に従います。

  1. REMOVE_SCHEDULE_ORDERINGプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.REMOVE_SCHEDULE ORDERING (
   schedule_capture_id IN VARCHAR2,
   wait_for_capture_id IN VARCHAR2);

  2. このスケジュール順序で待機しているワークロード取得にschedule_capture_idパラメータを追加します。

  3. このスケジュール順序で他のワークロード取得が開始する前に完了する必要のあるワークロード取得にwait_for_capture_idパラメータを設定します。

スケジュール順序を確認するには、次の手順に従います。

  • DBA_WORKLOAD_SCHEDULE_ORDERINGビューを使用します。

関連項目:

15.4.3.4 APIを使用したリプレイ・スケジュールの保存

この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して定義されたリプレイ・スケジュールを保存する方法を説明します。

リプレイ・スケジュールを保存する前に、次の前提条件が満たされていることを確認します。

リプレイ・スケジュールを保存するには、次の手順に従います。

  • END_REPLAY_SCHEDULEプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.END_REPLAY_SCHEDULE;

    この手順でリプレイ・スケジュールの作成が完了します。リプレイ・スケジュールがリプレイ・ディレクトリに関連付けられ保存されます。リプレイ・スケジュールは保存すると、統合リプレイ用に使用できます。

リプレイ・スケジュールを確認するには、次の手順に従います。

  • DBA_WORKLOAD_REPLAY_SCHEDULESビューを使用します。

関連項目:

15.4.4 APIを使用したデータベース統合リプレイの実行

この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、データベース統合リプレイを実行する方法を説明します。統合リプレイの詳細は、「データベース統合リプレイ用のデータベース・ワークロードのリプレイ」を参照してください。

データベース統合リプレイを実行する前に、次の前提条件が満たされていることを確認します。

  • すべてのワークロード取得は、「データベース・ワークロードの事前処理」で説明しているように、リプレイ・システムと同じデータベース・バージョンを実行しているシステムで、PROCESS_CAPTUREプロシージャを使用して前処理されています。

  • すべての取得ディレクトリは、リプレイ・システムのリプレイ・ディレクトリにコピー済です。

  • 「APIを使用した統合リプレイ・ディレクトリの設定」で説明されているように、リプレイ・ディレクトリがSET_REPLAY_DIRECTORYプロシージャを使用して設定済です。

  • データベースは、すべてのワークロード取得の開始時間にすべての取得システムと同じアプリケーション状態に論理的に復元されています。

データベース統合リプレイを実行するには、次の手順に従います。

  1. 「APIを使用したデータベース統合リプレイの初期化」で説明されているように、リプレイ・データを初期化します。

  2. 「APIを使用した接続の再マッピング」で説明されているように、接続文字列を再マッピングします。

  3. 「APIを使用したユーザーの再マッピング」で説明されているように、ユーザーを再マッピングします。

    ユーザーの再マッピングは任意です。

  4. 「APIを使用したデータベース統合リプレイの準備」で説明されているように、統合リプレイを準備します。

  5. 「リプレイ・クライアントの設定」で説明されているように、リプレイ・クライアントを設定して開始します。

  6. 「APIを使用したデータベース統合リプレイの開始」で説明されているように、統合リプレイを開始します。

  7. 「データベース統合リプレイのレポート作成および分析」で説明されているように、レポート作成および分析を行います。

15.4.4.1 APIを使用したデータベース統合リプレイの初期化

この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイ用にリプレイ・データを初期化する方法を説明します。

リプレイ・データを初期化すると次の操作が実行されます。

  • データベースの状態が統合ワークロードのリプレイ用に初期化モードになります。

  • リプレイ・スケジュールに関係するすべてのワークロード取得を含むリプレイ・ディレクトリがポイントされます。

  • リプレイに必要なメタデータが表にロードされます。

    たとえば、取得した接続文字列が、リプレイ用に再マッピング可能な表にロードされます。

データベース統合リプレイを初期化するには、次の手順に従います。

  1. INITIALIZE_CONSOLIDATED_REPLAYプロシージャを使用します: 

    DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY (
   replay_name    IN VARCHAR2,
   schedule_name  IN VARCHAR2,
   plsql_mode     IN VARCHAR2 DEFAULT 'TOP_LEVEL');

  2. replay_nameパラメータを統合リプレイの名前に設定します。

  3. schedule_nameパラメータを使用するリプレイ・スケジュールの名前に設定します。

    schedule_nameパラメータは、「APIを使用したリプレイ・スケジュールの作成」で説明されているように、その作成時に使用されたリプレイ・スケジュールの名前です。

オプションのplsql_modeパラメータで、PL/SQLのリプレイ・モードを指定します。

plsql_modeパラメータには次の2つの値を設定できます。

  • top_level: 最上位レベルのPL/SQLコールのみ。これがデフォルト値です。

  • extended: PL/SQL内で実行されたSQL、またはPL/SQL内に記録されているSQLがない場合は最上位レベルのPL/SQL。すべての取得は、'extended' PL/SQLモードで実行されている必要があります。PL/SQL以外のコールは通常の方法でリプレイされます。

次の例に、peak_scheduleという名前のリプレイ・スケジュールを使用して、peak_replayという名前の統合リプレイを初期化する方法を説明します。 

EXEC DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ('peak_replay',
     'peak_schedule');

関連項目:

INITIALIZE_CONSOLIDATED_REPLAYプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

15.4.4.2 APIを使用した接続の再マッピング
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイ用の接続文字列を再マッピングする方法を説明します。接続の再マッピングの詳細は、「データベース統合リプレイ用の接続の再マッピング」を参照してください。

接続文字列を再マッピングするには、次の手順に従います。

  1. REMAP_CONNECTIONプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (
   schedule_cap_id   IN NUMBER,
   connection_id     IN NUMBER,
   replay_connection IN VARCHAR2);

    この手順では、リプレイ・スケジュール内のすべての関係するワークロード取得の取得済の接続を新しい接続文字列に再マッピングします。

  2. schedule_capture_idパラメータを、現在のリプレイ・スケジュールに関係するワークロード取得に設定します。

    schedule_capture_idパラメータは、「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、ワークロード取得をリプレイ・スケジュールに追加した際に返された一意の識別子です。

  3. connection_idパラメータを再マッピングする接続に設定します。

    connection_idパラメータは、リプレイ・データの初期化時に生成され、ワークロード取得からの接続に対応しています。

  4. replay_connectionパラメータを、リプレイ時に使用される新しい接続文字列に設定します。

関連項目:

REMAP_CONNECTIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

15.4.4.3 APIを使用したユーザーの再マッピング
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイのためにユーザーを再マッピングする方法を説明します。ユーザーの再マッピングの詳細は、「データベース統合リプレイ用のユーザーの再マッピング」を参照してください。

ユーザーを再マッピングする前に、次の前提条件が満たされていることを確認します。

ユーザーを再マッピングするには、次の手順に従います。

  1. SET_USER_MAPPINGプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING (
   schedule_cap_id IN NUMBER,
   capture_user    IN VARCHAR2,
   replay_user     IN VARCHAR2);

  2. schedule_capture_idパラメータを、現在のリプレイ・スケジュールに関係するワークロード取得に設定します。

    schedule_capture_idパラメータは、「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、ワークロード取得をリプレイ・スケジュールに追加した際に返された一意の識別子です。

  3. capture_userパラメータを、ワークロードの取得時に取得したユーザーまたはスキーマのユーザー名に設定します。

  4. replay_userパラメータを、リプレイ時に取得済ユーザーが再マッピングされている新しいユーザーまたはスキーマのユーザー名に設定します。

    パラメータがNULLに設定されている場合、マッピングは無効です。

この例では、1001のワークロード取得のリプレイ中に、取得中に使用されたPRODユーザーをTESTユーザーに再マッピングする方法を示します。 

EXEC DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING (1001, 'PROD', 'TEST');

関連項目:

SET_USER_MAPPINGプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

15.4.4.4 APIを使用したデータベース統合リプレイの準備
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して統合リプレイを準備する方法を説明します。統合リプレイの準備の詳細は、「データベース統合リプレイの準備」を参照してください。

統合リプレイを準備する前に、次の前提条件が満たされていることを確認します。

統合リプレイの準備では、次の操作が実行されます。

  • 同期モード、セッションの接続率およびセッションのリクエスト率などのリプレイ・オプションが指定されます。

  • データベースがリプレイ・モードになります。

  • リプレイ・クライアントの起動が有効になります。

注意:

データベース統合リプレイでは、時間ベースまたはOBJECT_IDベースの同期(synchronization=TIMEまたはOBJECT_ID)しかサポートされていません。SCNベースの動機は、現在はサポートされていません。

統合リプレイを準備するには、次の手順に従います。

  • PREPARE_CONSOLIDATED_REPLAYプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY (
   synchronization         IN VARCHAR2 DEFAULT 'OBJECT_ID',
   connect_time_scale      IN NUMBER   DEFAULT 100,
   think_time_scale        IN NUMBER   DEFAULT 100,
   think_time_auto_correct IN BOOLEAN  DEFAULT TRUE,
   capture_sts             IN BOOLEAN  DEFAULT FALSE,
   sts_cap_interval        IN NUMBER   DEFAULT 300);

    これらのパラメータおよびその設定方法の詳細は、「リプレイ・オプションの指定」を参照してください。

注意:

PREPARE_CONSOLIDATED_REPLAYプロシージャを使用する場合、synchronizationを必ずfalseに設定してください。

関連項目:

PREPARE_CONSOLIDATED_REPLAYプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

15.4.4.5 APIを使用したデータベース統合リプレイの開始

この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイを開始する方法を説明します。

統合リプレイを開始する前に、次の前提条件が満たされていることを確認します。

統合リプレイを開始するには、次の手順に従います。

  • START_CONSOLIDATED_REPLAYプロシージャを使用します。 

    DBMS_WORKLOAD_REPLAY.START_CONSOLIDATED_REPLAY;

関連項目:

START_CONSOLIDATED_REPLAYプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

15.5 問合せのみのデータベース・リプレイについて

問合せのみのデータベース・リプレイでは、ワークロード取得の読取り専用問合せのみがリプレイされます。つまり、問合せのみのリプレイでは、リプレイ時にSELECT文のみがサーバーに送られます。問合せのみのリプレイ中はDML文は実行されず、リプレイではユーザー・スキーマやデータが変更されることはありません。

注意:

問合せのみのデータベース・リプレイが一緒に実行できるのは、データベース統合リプレイのみです。

注意:

問合せのみのデータベース・リプレイはテスト環境でのみ使用され、実行されます。

  • 問合せのみのデータベース・リプレイを本番システムで使用しないでください。

  • 問合せのみのデータベース・リプレイ中に相違が起こる可能性があります。

15.5.1 問合せのみのデータベース・リプレイの使用事例

問合せのみのデータベース・リプレイを使用して、データベース・バッファ・キャッシュをウォームアップしたり、パフォーマンスの低下を見つけることができます。次に例を示します。

  • データベース・バッファ・キャッシュをウォームアップするため

    場合によっては、データベース・バッファ・キャッシュがウォームな(データ・ブロックがすでにバッファ・キャッシュ内に存在している)ときにワークロードが取得されます。ただし、テスト・システムでそのワークロードをリプレイする場合、バッファー・キャッシュはウォームではなく、データ・ブロックを最初にディスクからロードする必要があります。これは、リプレイ時間が取得時間よりも長くなる可能性があり、データベース時間が増加します。

    バッファー・キャッシュのウォームアップの必要性を避けるために、問合せのみのリプレイを実行し、その後データベースを再起動したりバッファー・キャッシュをフラッシュしたりせずに読取り/書込みリプレイを実行します。問合せのみのリプレイは読取り専用のため、問合せのみのリプレイの後にデータベースを再起動する必要がないことに注意してください。

  • パフォーマンスの低下を見つけるため

    問合せのみのリプレイは、同時実行性を持つワークロードの読取り専用部分からパフォーマンスの低下を見つけるための優れた、簡単な方法です。読取り専用部分には、SELECT文(SELECT...FOR UPDATE文ではありません)、DMLおよびDDL以外のPL/SQL、LOB読取りなどがあります。通常、これがワークロード取得の主要部分です。

15.5.2 問合せのみのデータベース・リプレイの実行

問合せのみのデータベース・リプレイを実行できます。

問合せのみのデータベース・リプレイを実行するには、「APIを使用したデータベース統合リプレイの使用」の手順に従います。「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、ADD_CAPTUREファンクションを使用してリプレイ・スケジュールにワークロードの取得を追加するには、query_onlyパラメータをYに設定します。

15.6 例: APIを使用した統合済ワークロードのリプレイ

この項では、別のオペレーション・システムで別のバージョンのOracle Databaseを実行している3つの別の本番システムのワークロードを統合するシナリオを仮定しています。

このシナリオでは、次を想定しています。

  • 統合する最初のワークロードは、SolarisサーバーでOracle Database 10gリリース2(リリース10.2.0.4)を実行しているCRMシステムから取得します。

  • 統合する2番目のワークロードは、LinuxサーバーでOracle Database 10gリリース2(リリース10.2.0.5)を実行しているERPシステムから取得します。

  • 統合する3番目のワークロードは、SolarisサーバーでOracle Database 11gリリース2(リリース11.2.0.2)を実行しているSCMシステムから取得します。

  • テスト・システムは、Oracle Database 12c リリース1 (リリース12.1.0.1)を実行するマルチテナント・コンテナ・データベース(CDB)として設定されます。

  • CDBには、CRM、ERPおよびSCMで作成された3つのPDBが含まれています。

  • CDBに含まれる各PDBは、取得の開始時にCRM、ERPおよびSCMシステムのアプリケーション・データと同じ状態に復元されています。

図15-3は、そのシナリオを示しています。

図15-3 3つのワークロードを統合するシナリオ

図15-3の説明が続きます
「図15-3 3つのワークロードを統合するシナリオ」の説明

このシナリオで、ワークロードを統合し統合ワークロードをリプレイするには、次の手順に従います。

  1. テスト・システムで、個々のワークロード取得を別のディレクトリに前処理します。

    • CRMワークロードには、次を実行します。

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

        CREATE OR REPLACE DIRECTORY crm AS '/u01/test/cap_crm';

      2. CRMシステムから取得したワークロードがこのディレクトリに格納されていることを確認します。

      3. ワークロードを事前処理します。

        EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('CRM');

    • ERPワークロードには、次を実行します。

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

        CREATE OR REPLACE DIRECTORY erp AS '/u01/test/cap_erp';

      2. ERPシステムから取得したワークロードがこのディレクトリに格納されていることを確認します。

      3. ワークロードを事前処理します。

        EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('ERP');

    • SCMワークロードには、次を実行します。

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

        CREATE OR REPLACE DIRECTORY scm AS '/u01/test/cap_scm';

      2. SCMシステムから取得したワークロードがこのディレクトリに格納されていることを確認します。

      3. ワークロードを事前処理します。

        EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('SCM');

  2. 事前処理したワークロードを格納するルート・ディレクトリを作成します。

    mkdir '/u01/test/cons_dir';
CREATE OR REPLACE DIRECTORY cons_workload AS '/u01/test/cons_dir';

  3. 事前処理した各ワークロード・ディレクトリをルート・ディレクトリにコピーします。

    cp -r /u01/test/cap_crm /u01/test/cons_dir
cp -r /u01/test/cap_erp /u01/test/cons_dir
cp -r /u01/test/cap_scm /u01/test/cons_dir

  4. 各ワークロード用に、新しいオペレーティング・システムのディレクトリ・パスを使用して、ディレクトリ・オブジェクトを作成します。

    CREATE OR REPLACE DIRECTORY crm AS '/u01/test/cons_dir/cap_crm';
CREATE OR REPLACE DIRECTORY erp AS '/u01/test/cons_dir/cap_erp';
CREATE OR REPLACE DIRECTORY scm AS '/u01/test/cons_dir/cap_scm';

  5. 手順2で作成したルート・ディレクトリをリプレイ・ディレクトリに設定します。 

    EXEC DBMS_WORKLOAD_REPLAY.SET_REPLAY_DIRECTORY ('CONS_WORKLOAD');

  6. リプレイ・スケジュールを作成し、ワークロード取得を追加します。

    EXEC DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ('CONS_SCHEDULE');
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('CRM') FROM dual;
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('ERP') FROM dual;
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('SCM') FROM dual;
EXEC DBMS_WORKLOAD_REPLAY.END_REPLAY_SCHEDULE;

  7. 統合リプレイを初期化します。

    EXEC DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ('CONS_REPLAY',
     'CONS_SCHEDULE');

  8. 接続を再マッピングします。

    1. DBA_WORKLOAD_CONNECTION_MAPビューに接続マッピング情報を問い合せます。 

      SELECT schedule_cap_id, conn_id, capture_conn, replay_conn
  FROM dba_workload_connection_map;

    2. 接続を再マッピングします。

      EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 1,
     conn_id => 1, replay_connection => 'CRM');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 2,
     conn_id => 1, replay_connection => 'ERP');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 3,
     conn_id => 1, replay_connection => 'SCM');

      replay_connectionパラメータは、テスト・システムに定義したサービスを示します。

    3. 接続の再マッピングを確認します。

      SELECT schedule_cap_id, conn_id, capture_conn, replay_conn
  FROM dba_workload_connection_map;

  9. 統合リプレイを準備します。

    EXEC DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY (
     synchronization => 'OBJECT_ID');

  10. リプレイ・クライアントを起動します。

    1. 必要なリプレイ・クライアントの数を見積もります。

      wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_crm
wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_erp
wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_scm

    2. 必要なリプレイ・クライアントの数を判断するために出力を追加します。

      統合したワークロードに含まれるワークロード取得ごとに、最低1つのリプレイ・クライアントを開始する必要があります。

    3. このコマンドを繰り返し、必要な数のリプレイ・クライアントを起動します。

      wrc username/password mode=replay replaydir=/u01/test/cons_dir

      replaydirパラメータは、ワークロード取得が格納されているルート・ディレクトリに設定されています。

  11. 統合リプレイを開始します。

    EXEC DBMS_WORKLOAD_REPLAY.START_CONSOLIDATED_REPLAY;

関連項目: