15 データベース統合リプレイの使用
たとえば、複数の本番システムを1つのOracle Exadataマシンに統合する場合、1つの既存のシステムから取得したワークロードをOracle Exadataマシンでリプレイすると、新しいシステムの方が強力であるため、リソースの使用率(ホストCPUやI/Oなど)が低くなる場合があります。このような場合には、1つのシステムの1つのワークロードではなく、すべての既存のシステムのワークロードを統合したものを新しいシステムがどのように処理するか評価するのが有用です。
データベース統合リプレイでは、1つ以上のシステムから取得した複数のワークロードを統合し、1つのテスト・システムで同時にリプレイできます。この例では、データベース統合リプレイを使用し、データベースの統合がどのように本番システムに影響を与えるか、また1つのOracle Exadataマシンで統合データベースのワークロードを処理できるか評価できます。
この章では、次の内容で、データベース統合リプレイの使用方法について説明します。
データベース統合リプレイの使用事例
データベース統合リプレイのいくつかの典型的な使用事例は次のとおりです。
これらのいずれの使用事例も、この章で説明する手順を使用して実行できます。さらに、データベース統合リプレイの使用時には、様々なワークロードのスケールアップ・テクニックを採用できます。詳細は、「ワークロード・スケールアップの使用」を参照してください。
プラガブル・データベースを使用したデータベースの統合
データベース統合リプレイの1つの用途は、統合したデータベースのワークロードをシステムが処理できるか評価することです。
たとえば、CRM、ERPおよびSCMアプリケーションのデータベースをプラガブル・データベース(PDB)に移行してデータベースを統合するとします。データベース統合リプレイを使用すると、3つのアプリケーションから取得したワークロードを統合し、PDBで同時にリプレイできます。
関連項目:
この使用事例については、「例: APIを使用した統合済ワークロードのリプレイ」を参照してください
ストレス・テスト
データベース統合リプレイは、ストレス・テストまたはキャパシティ・プランニングにも使用できます。
たとえば、連休の時期に営業アプリケーションのワークロードが倍になると予想されるとします。この場合、データベース統合リプレイを使用し、ワークロードを倍にし統合したワークロードをリプレイして、システムに対する追加の負荷をテストできます。
関連項目:
この使用事例については、「タイム・シフトの使用」を参照してください
データベース統合リプレイの使用ステップ
データベース統合リプレイ用のデータベース・ワークロードの取得
この項では、データベース統合リプレイに固有なワークロードの取得に関して、次の内容で説明します。
サポートされているタイプのワークロード取得
ノート:
データベース統合リプレイは、Oracle Database 11gリリース2(リリース11.2.0.2.0)以上のみで使用できます。
取得サブセット
取得サブセットとは、時間範囲を適用して既存の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文、および開始時間が原因で不完全となってしまうユーザー・コールはこれに含まれます。
関連項目:
データベース統合リプレイ用のテスト・システムの設定
リプレイ中の相違を最小限に抑えるには、テスト・システムには同じアプリケーション・データが必要であり、アプリケーション・データの状態は、ワークロードをそれぞれ取得開始したときの取得システムのデータの状態と論理的に同じにする必要があります。ただし、取得が統合されている場合、様々な本番システムのワークロード取得が複数含まれている可能性があるため、テスト・システムをすべての取得に対応するよう設定する必要があります。この場合、各データベースが取得の開始時に取得システムと同等のデータを持つように、マルチテナント・アーキテクチャを使用して複数データベースを統合することをお薦めします。
データベース統合リプレイを行うには、関係しているすべてのワークロード取得を、テスト・システムの新しい取得ディレクトリの下に配置する必要があります。ワークロード取得をすべて新しい取得ディレクトリにコピーするか、元のワークロード取得をポイントするシンボリック・リンクを作成します。ワークロード取得を統合する前に、新しい取得ディレクトリに関係するすべての取得を格納する十分な空き領域があることを確認します。
図15-1に、3つのワークロード取得を統合するテスト・システムと新しい取得ディレクトリを設定する方法を示します。
関連項目:
-
マルチテナント・アーキテクチャの詳細は、『Oracle Database概要』を参照してください。
データベース統合リプレイ用のデータベース・ワークロードの前処理
データベース統合リプレイを行うには、取得した各ワークロードをその固有のディレクトリに前処理します。前処理を行う際には、別のワークロード取得を1つのディレクトリにまとめないようにする必要があります。取得済ワークロードの前処理は、ワークロードをリプレイするテスト・システムのOracle Databaseと同じバージョンのデータベースを使用して実行する必要があります。
データベース統合リプレイ用のデータベース・ワークロードのリプレイ
データベース統合リプレイで統合されたワークロードのリプレイは、データベース・リプレイで1つのデータベース・ワークロードをリプレイすることとは大きく異なります。
この項では、データベース統合リプレイに固有なワークロードのリプレイに関して、次の内容で説明します。
リプレイ・スケジュールの定義
リプレイ・スケジュールでは、2種類の操作が実行されます。
関連項目:
ワークロード取得の追加
リプレイ・スケジュールでは、最初に関係するワークロード取得がリプレイに追加されます。
リプレイ・スケジュールにワークロード取得が追加されると、そのワークロード取得を識別する一意の番号が返されます。ワークロード取得には、追加のたびに別の番号が割り当てられるので、複数回リプレイ・スケジュールに追加することが可能です。リプレイ・スケジュールでは、追加のたびに取得をコピーしてディスク領域を無駄にしないために、都度同じ取得ディレクトリをポイントします。
スケジュールの順序の追加
次いで、リプレイ・スケジュールには、関係するワークロード取得のリプレイ時開始順序が追加されます。
スケジュール順序では、リプレイ・スケジュールに追加された2つのワークロード取得の開始順序が定義されます。リプレイ・スケジュールには、複数のスケジュール順序を追加できます。たとえば、リプレイ・スケジュールにワークロード取得が3つ追加されているとします。追加した1つのスケジュール順序では、取得2は取得1が完了してから開始するよう指定します。別のスケジュール順序では、取得3は取得1が完了してから開始するよう指定します。この場合、取得2も取得3も取得1が完了するのを待機してから開始する必要があります。
リプレイ・スケジュールには、必ずしもスケジュール順序を含める必要はありません。この場合、リプレイ・スケジュール内の関係するすべてのワークロード取得は、統合リプレイの開始時に同時にリプレイが開始されます。
データベース統合リプレイ用の接続の再マッピング
データベース統合リプレイを行うには、複数のワークロード取得の取得済接続文字列をリプレイ時に別の接続文字列に再マッピングする必要があります。
関連項目:
データベース統合リプレイ用のユーザーの再マッピング
データベース統合リプレイの場合には、リプレイ時に、複数のワークロード取得からの取得済ユーザーを別のユーザーまたはスキーマに再マッピングするよう選択できます。
関連項目:
データベース統合リプレイの準備
データベース統合リプレイでは、統合リプレイ内のすべての関係しているワークロード取得は、リプレイの準備時に定義された同じリプレイ・オプションを使用してリプレイされます。
個々のワークロードのリプレイ
個々にリプレイすることによって各ワークロード取得のベースライン・パフォーマンスを定めて、統合リプレイのパフォーマンスの分析に使用できます。
データベース統合リプレイのレポート作成および分析
データベース統合リプレイのリプレイの期間比較レポートには、個々のワークロード取得のアクティブ・セッション履歴(ASH)データがあり、ワークロード取得のASHデータが統合リプレイのフィルタされたASHデータと比較されています。このレポートを使用すると、同じ統合されているワークロード取得のリプレイを比較できます。
データベース統合リプレイのリプレイの期間比較レポートでは、統合リプレイを複数の取得とリプレイの比較として扱います。このレポートのサマリー・セクションには、取得とリプレイの比較を個々にまとめた表があります。このセクションの情報を確認すると、統合リプレイがどのように実行されたかの概要を理解できます。
図15-2に、データベース統合リプレイのサンプル・リプレイ期間比較レポートのサマリー・セクションを示します。
このレポートの残りのセクションは、リプレイの期間比較レポートのASHデータ比較セクションと似ており、統合リプレイ内のすべての取得とリプレイのレポートを結合したもので構成されています。このセクションの詳細は、「ASHデータ比較」を参照してください。
Enterprise Managerを使用したデータベース統合リプレイの使用
この項では、Enterprise Managerを使用してデータベース統合リプレイを使用する方法について説明します。
Oracle Enterprise Managerは、統合されたデータベース・ワークロードをリプレイする主要ツールです。Oracle Enterprise Managerを使用できない場合は、「APIを使用したデータベース統合リプレイの使用」で説明されているように、APIを使用して統合されたデータベース・ワークロードをリプレイすることもできます。
統合されたデータベース・ワークロードをリプレイするプロセスは、単一のデータベース・ワークロードをリプレイするプロセスとほとんど同じです。違いは、次の項の単一のリプレイの手順で説明されています。
次のリストは、統合されたデータベース・ワークロードのリプレイと単一のデータベース・ワークロードのリプレイの違いのサマリーを示します。
-
リプレイ・タスクを作成する際、2つ以上の取得済ワークロードをタスクの作成ページの取得の選択表から選択する必要があります。
-
ウィザードの「取得されたワークロードの前処理: ワークロードのコピー」ステップには、「取得名」ドロップダウンの複数の選択肢があるため、ワークロード・ディレクトリの現在の場所の複数の資格証明を入力する必要がある場合があります。
-
ウィザードの「取得されたワークロードの前処理: ディレクトリを選択」ステップでは、単一のリプレイで表示されるように「取得サマリー」が表示されません。
-
ウィザードの「ワークロード・リプレイ: ワークロードのコピー」ステップには、「取得名」ドロップダウンの複数の選択肢があるため、ワークロード・ディレクトリの現在の場所の複数の資格証明を入力する必要がある場合があります。
-
ウィザードの「ワークロード・リプレイ: ディレクトリを選択」ステップでは、単一のリプレイで表示されるように「取得サマリー」が表示されません。
-
ウィザードの「ワークロード・リプレイ: 初期化オプション」ステップでは、「ソースを指定」セクションは表示されません。
-
ウィザードの「ワークロード・リプレイ: オプションのカスタマイズ」ステップの「接続マッピング」の「取得名」ドロップダウンには、1つ以上の選択肢が表示されるので、取得したワークロードの接続をそれぞれ再マッピングできます。1つの接続記述子またはネット・サービス名を使用することはできません。
APIを使用したデータベース統合リプレイの使用
DBMS_WORKLOAD_REPLAYパッケージを使用して統合済ワークロードを作成およびリプレイする方法を説明します。「Enterprise Managerを使用したデータベース統合リプレイの使用」で説明されているように、Oracle Enterprise Managerを使用して統合されているワークロードを作成およびリプレイすることもできます。
APIを使用して統合されているワークロードを作成およびリプレイするステップは、次などの複数のステップを実行する必要があります。
関連項目:
DBMS_WORKLOAD_REPLAYパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
APIを使用した取得サブセットの生成
DBMS_WORKLOAD_REPLAYパッケージを使用して、既存のワークロード取得から取得サブセットを生成する方法を説明します。取得サブセットの詳細は、「取得サブセット」を参照してください。
既存のワークロード取得から取得サブセットを生成するには:
-
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);
-
input_capture_dirパラメータを、既存のワークロード取得をポイントするディレクトリ・オブジェクト名に設定します。 -
output_capture_dirパラメータを、新しいワークロード取得を格納する空のディレクトリをポイントするディレクトリ・オブジェクト名に設定します。 -
new_capture_nameパラメータを、生成する新しいワークロード取得の名前に設定します。 -
任意指定の他のパラメータを適宜設定します。
これらのパラメータの詳細は、『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パッケージおよびタイプ・リファレンス』を参照してください
APIを使用した統合リプレイ・ディレクトリの設定
DBMS_WORKLOAD_REPLAYパッケージを使用して、テスト・システムに統合リプレイ・ディレクトリを設定する方法を説明します。統合リプレイ・ディレクトリを、統合およびリプレイするワークロード取得を含むテスト・システムのディレクトリに設定します。テスト・システムの設定の詳細は、「データベース統合リプレイ用のテスト・システムの設定」を参照してください。
リプレイ・ディレクトリを設定するには:
ヒント:
SET_REPLAY_DIRECTORYプロシージャは非推奨で、SET_CONSOLIDATED_DIRECTORYプロシージャに置き換えられます。
この例では、リプレイ・ディレクトリをrep_dirという名前のディレクトリ・オブジェクトに設定する方法を示します。
EXEC DBMS_WORKLOAD_REPLAY.SET_CONSOLIDATED_DIRECTORY ('rep_dir');
また、DBMS_WORKLOAD_REPLAYパッケージを使用してSET_CONSOLIDATED_DIRECTORYプロシージャによって設定された現在の統合リプレイ・ディレクトリを参照することもできます。
設定されている現在の統合リプレイ・ディレクトリを確認するには:
関連項目:
-
SET_REPLAY_DIRECTORYプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください -
GET_REPLAY_DIRECTORYファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
APIを使用したリプレイ・スケジュールの定義
DBMS_WORKLOAD_REPLAYパッケージを使用してリプレイ・スケジュールを定義する方法を説明します。リプレイ・スケジュールの詳細は、「リプレイ・スケジュールの定義」を参照してください。
リプレイ・スケジュールを定義する前に、次の前提条件が満たされていることを確認します。
-
すべてのワークロード取得は、「データベース・ワークロードの事前処理」で説明しているように、リプレイ・システムと同じデータベース・バージョンを実行しているシステムで、
PROCESS_CAPTUREプロシージャを使用して前処理されています。 -
すべての取得ディレクトリは、リプレイ・システムのリプレイ・ディレクトリにコピー済です。
-
「APIを使用した統合リプレイ・ディレクトリの設定」で説明されているように、リプレイ・ディレクトリが
SET_REPLAY_DIRECTORYプロシージャを使用して設定済です。 -
データベースが、リプレイ・モードの状態ではありません。
リプレイ・スケジュールを定義するには:
-
「APIを使用したリプレイ・スケジュールの作成」で説明されているように、新しいリプレイ・スケジュールを作成します。
-
「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、リプレイ・スケジュールにワークロード取得を追加します。
-
「APIを使用したリプレイ・スケジュールへのスケジュール順序の追加」で説明されているように、リプレイ・スケジュールにスケジュール順序を追加します。
-
「APIを使用したリプレイ・スケジュールの保存」で説明されているように、リプレイ・スケジュールを保存します。
APIを使用したリプレイ・スケジュールの作成
DBMS_WORKLOAD_REPLAYパッケージを使用してリプレイ・スケジュールを作成する方法を説明します。リプレイ・スケジュールの詳細は、「リプレイ・スケジュールの定義」を参照してください。
リプレイ・スケジュールを作成するには:
ノート:
BEGIN_REPLAY_SCHEDULEプロシージャでは、再利用可能なリプレイ・スケジュールの作成を開始します。リプレイ・スケジュールは1度に1つのみ定義できます。リプレイ・スケジュールの定義中にこのプロシージャを呼び出すと、エラーが発生します。
この例に、peak_scheduleというリプレイ・スケジュールを作成する方法を説明します。
EXEC DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ('peak_schedule');
関連項目:
BEGIN_REPLAY_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
APIを使用したリプレイ・スケジュールへのワークロード取得の追加
DBMS_WORKLOAD_REPLAYパッケージを使用して、リプレイ・スケジュールにワークロード取得を追加および削除する方法を説明します。リプレイ・スケジュールにワークロード取得を追加する方法の詳細は、「ワークロード取得の追加」を参照してください。
リプレイ・スケジュールにワークロード取得を追加する前に、次の前提条件が満たされていることを確認します。
-
ワークロード取得を追加するリプレイ・スケジュールが作成済です。
リプレイ・スケジュールの作成の詳細は、「APIを使用したリプレイ・スケジュールの作成」を参照してください。
リプレイ・スケジュールにワークロード取得を追加するには:
-
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;
このファンクションでは、このリプレイ・スケジュール内でワークロード取得を識別する一意の識別子が返されます。
参照:
問合せのみのデータベース・リプレイについては、「問合せのみのデータベース・リプレイについて」を参照してください。
ノート:
問合せのみのデータベース・リプレイはテスト環境でのみ使用され、実行されます。
-
問合せのみのデータベース・リプレイを本番システムで使用しないでください。
-
問合せのみのデータベース・リプレイ中に相違が起こる可能性があります。
-
-
capture_dir_nameパラメータを上位レベルのリプレイ・ディレクトリにある取得したワークロードをポイントするディレクトリ・オブジェクト名に設定します。このディレクトリには、リプレイ・システムと同じデータベース・バージョンを実行しているシステムで前処理された有効なワークロード取得が含まれている必要があります。
-
任意指定の他のパラメータを適宜設定します。
これらのパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
次の例に、SELECT文でADD_CAPTUREファンクションを使用して、リプレイ・スケジュールにpeak_wkldというワークロード取得を追加する方法を示します。
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('peak_wkld')
FROM dual;
リプレイ・スケジュールからワークロード取得を削除する場合、DBMS_WORKLOAD_REPLAYパッケージを使用することも可能です。
リプレイ・スケジュールからワークロード取得を削除するには:
関連項目:
-
ADD_CAPTUREファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
REMOVE_CAPTUREプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
APIを使用したリプレイ・スケジュールへのスケジュール順序の追加
DBMS_WORKLOAD_REPLAYパッケージを使用して、スケジュール順序をリプレイ・スケジュールから削除および追加する方法を説明します。リプレイ・スケジュールにスケジュール順序を追加する方法の詳細は、「スケジュール順序の追加」を参照してください。
リプレイ・スケジュールにスケジュール順序を追加する前に、次の前提条件が満たされていることを確認します。
-
スケジュール順序を追加するリプレイ・スケジュールが作成済です。
リプレイ・スケジュールの作成の詳細は、「APIを使用したリプレイ・スケジュールの作成」を参照してください。
-
そのスケジュール順序に関係するすべてのワークロード取得がリプレイ・スケジュールに追加済です。
リプレイ・スケジュールへのワークロード取得の追加の詳細は、「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」を参照してください。
ノート:
リプレイ・スケジュールにはスケジュール順序を必ずしも追加する必要はありません。リプレイ・スケジュールにスケジュール順序を追加しない場合、統合リプレイが開始されるとき、リプレイ・スケジュールに追加されたすべてのワークロード取得が同時にリプレイされます。
リプレイ・スケジュールにスケジュール順序を追加するには:
-
ADD_SCHEDULE_ORDERINGファンクションを使用します。DBMS_WORKLOAD_REPLAY.ADD_SCHEDULE_ORDERING ( schedule_capture_id IN NUMBER, waitfor_capture_id IN NUMBER) RETURN NUMBER;
このファンクションでは、リプレイ・スケジュールに追加された2つのワークロード取得間にスケジュール順序を追加します。スケジュール順序を追加できない場合、ゼロではないエラー・コードが返されます。
-
このスケジュール順序で待機するワークロード取得に
schedule_capture_idパラメータを設定します。 -
このスケジュール順序で他のワークロード取得が開始される前に、完了するワークロード取得を
wait_for_capture_idパラメータに設定します。
リプレイ・スケジュールからスケジュール順序を削除するには:
-
REMOVE_SCHEDULE_ORDERINGプロシージャを使用します。DBMS_WORKLOAD_REPLAY.REMOVE_SCHEDULE ORDERING ( schedule_capture_id IN VARCHAR2, wait_for_capture_id IN VARCHAR2);
-
このスケジュール順序で待機しているワークロード取得に
schedule_capture_idパラメータを追加します。 -
このスケジュール順序で他のワークロード取得が開始する前に完了する必要のあるワークロード取得に
wait_for_capture_idパラメータを設定します。
スケジュール順序を確認するには:
-
DBA_WORKLOAD_SCHEDULE_ORDERINGビューを使用します。
関連項目:
-
ADD_SCHEDULE_ORDERINGファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
REMOVE_SCHEDULE_ORDERINGプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
DBA_WORKLOAD_SCHEDULE_ORDERINGビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
APIを使用したリプレイ・スケジュールの保存
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して定義されたリプレイ・スケジュールを保存する方法を説明します。
リプレイ・スケジュールを保存する前に、次の前提条件が満たされていることを確認します。
-
保存するリプレイ・スケジュールが作成済です。
リプレイ・スケジュールの作成の詳細は、「APIを使用したリプレイ・スケジュールの作成」を参照してください。
-
そのスケジュール順序に関係するすべてのワークロード取得がリプレイ・スケジュールに追加済です。
リプレイ・スケジュールへのワークロード取得の追加の詳細は、「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」を参照してください。
-
使用するすべてのスケジュール順序がリプレイ・スケジュールに追加済です(このステップは任意指定です)。
リプレイ・スケジュールへのスケジュール順序の追加の詳細は、「APIを使用したリプレイ・スケジュールへのスケジュール順序の追加」を参照してください。
リプレイ・スケジュールを保存するには:
リプレイ・スケジュールを確認するには:
-
DBA_WORKLOAD_REPLAY_SCHEDULESビューを使用します。
関連項目:
-
END_REPLAY_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
DBA_WORKLOAD_REPLAY_SCHEDULESビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
APIを使用したデータベース統合リプレイの実行
DBMS_WORKLOAD_REPLAYパッケージを使用して、データベース統合リプレイを実行する方法を説明します。統合リプレイの詳細は、「データベース統合リプレイ用のデータベース・ワークロードのリプレイ」を参照してください。
データベース統合リプレイを実行する前に、次の前提条件が満たされていることを確認します。
-
すべてのワークロード取得は、「データベース・ワークロードの事前処理」で説明しているように、リプレイ・システムと同じデータベース・バージョンを実行しているシステムで、
PROCESS_CAPTUREプロシージャを使用して前処理されています。 -
すべての取得ディレクトリは、リプレイ・システムのリプレイ・ディレクトリにコピー済です。
-
「APIを使用した統合リプレイ・ディレクトリの設定」で説明されているように、リプレイ・ディレクトリが
SET_REPLAY_DIRECTORYプロシージャを使用して設定済です。 -
データベースは、すべてのワークロード取得の開始時間にすべての取得システムと同じアプリケーション状態に論理的に復元されています。
データベース統合リプレイを実行するには:
-
「APIを使用したデータベース統合リプレイの初期化」で説明されているように、リプレイ・データを初期化します。
-
「APIを使用した接続の再マッピング」で説明されているように、接続文字列を再マッピングします。
-
「APIを使用したユーザーの再マッピング」で説明されているように、ユーザーを再マッピングします。
ユーザーの再マッピングは任意です。
-
「APIを使用したデータベース統合リプレイの準備」で説明されているように、統合リプレイを準備します。
-
「リプレイ・クライアントの設定」で説明されているように、リプレイ・クライアントを設定して開始します。
-
「APIを使用したデータベース統合リプレイの開始」で説明されているように、統合リプレイを開始します。
-
「データベース統合リプレイのレポート作成および分析」で説明されているように、レポート作成および分析を行います。
APIを使用したデータベース統合リプレイの初期化
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイ用にリプレイ・データを初期化する方法を説明します。
リプレイ・データを初期化すると次の操作が実行されます。
-
データベースの状態が統合ワークロードのリプレイ用に初期化モードになります。
-
リプレイ・スケジュールに関係するすべてのワークロード取得を含むリプレイ・ディレクトリがポイントされます。
-
リプレイに必要なメタデータが表にロードされます。
たとえば、取得した接続文字列が、リプレイ用に再マッピング可能な表にロードされます。
データベース統合リプレイを初期化するには:
-
INITIALIZE_CONSOLIDATED_REPLAYプロシージャを使用します:DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ( replay_name IN VARCHAR2, schedule_name IN VARCHAR2, plsql_mode IN VARCHAR2 DEFAULT 'TOP_LEVEL');
-
replay_nameパラメータを統合リプレイの名前に設定します。 -
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パッケージおよびタイプ・リファレンス』を参照してください
APIを使用した接続の再マッピング
DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイ用の接続文字列を再マッピングする方法を説明します。接続の再マッピングの詳細は、「データベース統合リプレイ用の接続の再マッピング」を参照してください。
接続文字列を再マッピングするには:
-
DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION ( schedule_cap_id IN NUMBER, connection_id IN NUMBER, replay_connection IN VARCHAR2);
この手順では、リプレイ・スケジュール内のすべての関係するワークロード取得の取得済の接続を新しい接続文字列に再マッピングします。
-
schedule_capture_idパラメータを、現在のリプレイ・スケジュールに関係するワークロード取得に設定します。schedule_capture_idパラメータは、「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、ワークロード取得をリプレイ・スケジュールに追加した際に返された一意の識別子です。 -
connection_idパラメータを再マッピングする接続に設定します。connection_idパラメータは、リプレイ・データの初期化時に生成され、ワークロード取得からの接続に対応しています。 -
replay_connectionパラメータを、リプレイ時に使用される新しい接続文字列に設定します。
関連項目:
REMAP_CONNECTIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
APIを使用したユーザーの再マッピング
DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイのためにユーザーを再マッピングする方法を説明します。ユーザーの再マッピングの詳細は、「データベース統合リプレイ用のユーザーの再マッピング」を参照してください。
ユーザーを再マッピングする前に、次の前提条件が満たされていることを確認します。
-
「APIを使用したデータベース統合リプレイの初期化」で説明されているように、リプレイ・データが初期化済です。
-
データベースが、リプレイ・モードの状態ではありません。
ユーザーを再マッピングするには:
-
DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING ( schedule_cap_id IN NUMBER, capture_user IN VARCHAR2, replay_user IN VARCHAR2);
-
schedule_capture_idパラメータを、現在のリプレイ・スケジュールに関係するワークロード取得に設定します。schedule_capture_idパラメータは、「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、ワークロード取得をリプレイ・スケジュールに追加した際に返された一意の識別子です。 -
capture_userパラメータを、ワークロードの取得時に取得したユーザーまたはスキーマのユーザー名に設定します。 -
replay_userパラメータを、リプレイ時に取得済ユーザーが再マッピングされている新しいユーザーまたはスキーマのユーザー名に設定します。パラメータが
NULLに設定されている場合、マッピングは無効です。
この例では、1001のワークロード取得のリプレイ中に、取得中に使用されたPRODユーザーをTESTユーザーに再マッピングする方法を示します。
EXEC DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING (1001, 'PROD', 'TEST');
関連項目:
SET_USER_MAPPINGプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
APIを使用したデータベース統合リプレイの準備
DBMS_WORKLOAD_REPLAYパッケージを使用して統合リプレイを準備する方法を説明します。統合リプレイの準備の詳細は、「データベース統合リプレイの準備」を参照してください。
統合リプレイを準備する前に、次の前提条件が満たされていることを確認します。
-
「APIを使用したデータベース統合リプレイの初期化」で説明されているように、リプレイ・データが初期化済です。
-
「APIを使用した接続の再マッピング」で説明されているように、取得済の接続が再マッピング済です。
-
「APIを使用したユーザーの再マッピング」で説明されているように、ユーザーがマッピング済です。
ユーザーの再マッピングは任意です。ただし、リプレイ時にユーザーを再マッピングする予定の場合、統合リプレイを準備する前にそれが完了している必要があります。
統合リプレイの準備では、次の操作が実行されます。
-
同期モード、セッションの接続率およびセッションのリクエスト率などのリプレイ・オプションが指定されます。
-
データベースがリプレイ・モードになります。
-
リプレイ・クライアントの起動が有効になります。
統合リプレイを準備するには:
-
PREPARE_CONSOLIDATED_REPLAYプロシージャを使用します。DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY ( synchronization IN VARCHAR2 DEFAULT 'SCN', 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プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
APIを使用したデータベース統合リプレイの開始
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイを開始する方法を説明します。
統合リプレイを開始する前に、次の前提条件が満たされていることを確認します。
-
「APIを使用したデータベース統合リプレイの準備」で説明されているように、統合リプレイが準備済です。
-
十分な数のリプレイ・クライアントが起動済です。
リプレイ・クライアントの設定および開始の詳細は、「リプレイ・クライアントの設定」を参照してください。
統合リプレイを開始するには:
関連項目:
START_CONSOLIDATED_REPLAYプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
問合せのみのデータベース・リプレイについて
問合せのみのデータベース・リプレイでは、ワークロード取得の読取り専用問合せのみがリプレイされます。つまり、問合せのみのリプレイでは、リプレイ時にSELECT文のみがサーバーに送られます。問合せのみのリプレイ中はDML文は実行されず、リプレイではユーザー・スキーマやデータが変更されることはありません。
ノート:
問合せのみのデータベース・リプレイが一緒に実行できるのは、データベース統合リプレイのみです。
ノート:
問合せのみのデータベース・リプレイはテスト環境でのみ使用され、実行されます。
-
問合せのみのデータベース・リプレイを本番システムで使用しないでください。
-
問合せのみのデータベース・リプレイ中に相違が起こる可能性があります。
問合せのみのデータベース・リプレイの使用事例
-
データベース・バッファ・キャッシュをウォームアップするため
場合によっては、データベース・バッファ・キャッシュがウォームな(データ・ブロックがすでにバッファ・キャッシュ内に存在している)ときにワークロードが取得されます。ただし、テスト・システムでそのワークロードをリプレイする場合、バッファー・キャッシュはウォームではなく、データ・ブロックを最初にディスクからロードする必要があります。これは、リプレイ時間が取得時間よりも長くなる可能性があり、データベース時間が増加します。
バッファー・キャッシュのウォームアップの必要性を避けるために、問合せのみのリプレイを実行し、その後データベースを再起動したりバッファー・キャッシュをフラッシュしたりせずに読取り/書込みリプレイを実行します。問合せのみのリプレイは読取り専用のため、問合せのみのリプレイの後にデータベースを再起動する必要がないことに注意してください。
-
パフォーマンスの低下を見つけるため
問合せのみのリプレイは、同時実行性を持つワークロードの読取り専用部分からパフォーマンスの低下を見つけるための優れた、簡単な方法です。読取り専用部分には、
SELECT文(SELECT...FOR UPDATE文ではありません)、DMLおよびDDL以外のPL/SQL、LOB読取りなどがあります。通常、これがワークロード取得の主要部分です。
問合せのみのデータベース・リプレイの実行
問合せのみのデータベース・リプレイを実行できます。
問合せのみのデータベース・リプレイを実行するには、「APIを使用したデータベース統合リプレイの使用」の手順に従います。「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、ADD_CAPTUREファンクションを使用してリプレイ・スケジュールにワークロードの取得を追加するには、query_onlyパラメータをYに設定します。
例: 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は、そのシナリオを示しています。
このシナリオで、ワークロードを統合し統合ワークロードをリプレイするには:
-
テスト・システムで、個々のワークロード取得を別のディレクトリに前処理します。
-
CRMワークロードには、次を実行します。
-
ディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY crm AS '/u01/test/cap_crm';
-
CRMシステムから取得したワークロードがこのディレクトリに格納されていることを確認します。
-
ワークロードを事前処理します。
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('CRM');
-
-
ERPワークロードには、次を実行します。
-
ディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY erp AS '/u01/test/cap_erp';
-
ERPシステムから取得したワークロードがこのディレクトリに格納されていることを確認します。
-
ワークロードを事前処理します。
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('ERP');
-
-
SCMワークロードには、次を実行します。
-
ディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY scm AS '/u01/test/cap_scm';
-
SCMシステムから取得したワークロードがこのディレクトリに格納されていることを確認します。
-
ワークロードを事前処理します。
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('SCM');
-
-
-
事前処理したワークロードを格納するルート・ディレクトリを作成します。
mkdir '/u01/test/cons_dir'; CREATE OR REPLACE DIRECTORY cons_workload AS '/u01/test/cons_dir';
-
事前処理した各ワークロード・ディレクトリをルート・ディレクトリにコピーします。
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
-
各ワークロード用に、新しいオペレーティング・システムのディレクトリ・パスを使用して、ディレクトリ・オブジェクトを作成します。
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';
-
ステップ2で作成したルート・ディレクトリをリプレイ・ディレクトリに設定します。
EXEC DBMS_WORKLOAD_REPLAY.SET_REPLAY_DIRECTORY ('CONS_WORKLOAD'); -
リプレイ・スケジュールを作成し、ワークロード取得を追加します。
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; -
統合リプレイを初期化します。
EXEC DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ('CONS_REPLAY', 'CONS_SCHEDULE'); -
接続を再マッピングします。
-
DBA_WORKLOAD_CONNECTION_MAPビューに接続マッピング情報を問い合せます。SELECT schedule_cap_id, conn_id, capture_conn, replay_conn FROM dba_workload_connection_map;
-
接続を再マッピングします。
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パラメータは、テスト・システムに定義したサービスを示します。 -
接続の再マッピングを確認します。
SELECT schedule_cap_id, conn_id, capture_conn, replay_conn FROM dba_workload_connection_map;
-
-
統合リプレイを準備します。
EXEC DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY ( synchronization => 'OBJECT_ID'); -
リプレイ・クライアントを起動します。
-
必要なリプレイ・クライアントの数を見積もります。
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
-
必要なリプレイ・クライアントの数を判断するために出力を追加します。
統合したワークロードに含まれるワークロード取得ごとに、最低1つのリプレイ・クライアントを開始する必要があります。
-
このコマンドを繰り返し、必要な数のリプレイ・クライアントを起動します。
wrc username/password mode=replay replaydir=/u01/test/cons_dir
replaydirパラメータは、ワークロード取得が格納されているルート・ディレクトリに設定されています。
-
-
統合リプレイを開始します。
EXEC DBMS_WORKLOAD_REPLAY.START_CONSOLIDATED_REPLAY;
関連項目:
-
CDBの構成の詳細は、『Oracle Database管理者ガイド』を参照してください
-
PDBの作成の詳細は、『Oracle Database管理者ガイド』を参照してください