| Oracle® Database Real Application Testingユーザーズ・ガイド 11gリリース2(11.2) B56321-06 |
|
 前 |
 次 |
データベース・リプレイでは、本番システムのワークロードを取得し、テスト・システムでそれをリプレイすることができます。これは、本番システムに変更の影響を与えずにテストできるので、新しいデータベース・テクノロジを評価したり採用するときに非常に便利です。ただし、状況によっては、システムでどのように追加ワークロードが処理されるかを正確に予測するために、複数のワークロードを同時にリプレイすることが必要な場合があります。
たとえば、既存の取得済ワークロードにワークロードを追加し、一緒にリプレイして、システムに対するストレス・テストを実行する場合に便利です。また、既存の取得済ワークロードを縮小するか、データベース・スキーマを再マッピングして、スケールアップ・テストを実行することもできます。
データベース統合リプレイでは、1つ以上のシステムから取得した複数のワークロードを統合し、1つのテスト・システムで同時にリプレイできます。これにより、ストレス・テスト、スケールアップ・テストなど、より包括的なテストを実行できます。
この章では、次の内容で、データベース統合リプレイの使用方法について説明します。
|
注意: データベース統合リプレイは、Oracle Database 11gリリース2 (11.2)に適切なパッチを適用した後にのみ使用できます。必要なパッチの詳細は、Oracle Supportに問い合せるか、My Oracle Support (MOS)のNote 560977.1を参照してください。 |
データベース統合リプレイでは、1つ以上のシステムから取得した複数のワークロードを同時にリプレイできます。統合リプレイでリプレイが開始されると、統合されたすべてのワークロード取得のリプレイが開始されます。データベース統合リプレイを使用する際には、使用事例に応じて様々なワークロード・スケールアップ・テクニックを使用できます。
この項の内容は次のとおりです。
データベース統合リプレイのいくつかの典型的な使用事例は次のとおりです。
データベース統合リプレイの1つの用途として、ストレス・テストまたはキャパシティ・プランニングがあります。たとえば、連休の時期に営業アプリケーションのワークロードが倍になると予想されるとします。この場合、データベース統合リプレイを使用し、ワークロードを倍にし統合したワークロードをリプレイして、システムに対する追加の負荷をテストできます。システムでストレス・テストを実行するには、タイム・シフトを検討してください。
データベース統合リプレイの別の用途として、スケールアップ・テストがあります。たとえば、財務のアプリケーションと注文のアプリケーションの取得済ワークロードをシステムで同時に処理できるかテストしたいとします。この場合、データベース統合リプレイを使用し、ワークロードを統合しそれらを同時にリプレイして、スケールアップしたワークロードのシステムに対する追加の負荷の影響をテストできます。システムでスケールアップ・テストを実行するには、ワークロードの縮小またはスキーマの再マッピングの使用を検討してください。
この項では、次のワークロード・スケールアップ・テクニックについて説明します。
データベース・リプレイでは、取得したワークロードをリプレイする際にタイム・シフトを実行できます。このテクニックは、既存の取得済ワークロードにワークロードを追加し、一緒にリプレイして、システムに対するストレス・テストを実行したい場合に便利です。
たとえば、営業、CRMおよびDWの3つのアプリケーションから取得した3つのワークロードがあるとします。ストレス・テストを実行するには、これらの取得済ワークロードのピークを合わせ、データベース統合リプレイを使用して一緒にリプレイします。
データベース・リプレイでは、既存のワークロード取得を縮小してスケールアップ・テストを実行できます。たとえば、午前2時から午後8時のワークロードを取得したとします。データベース・リプレイを使用し、元のワークロードを3つの取得サブセット(1番目は午前2時から午後8時、2番目は午前8時から午後2時、3番目は午後2時から午後8時)に縮小します。3つの取得サブセットを同時にリプレイすると、元の取得は縮小してリプレイ時にワークロードを3倍にして、スケールアップ・テストを実行できます。
|
関連項目:
|
データベース・リプレイでは、データベース・スキーマを再マッピングして、スケールアップ・テストを実行できます。このテクニックは、マルチテナント・アプリケーションなどの同じアプリケーションのインスタンスを複数デプロイする際や、既存のアプリケーションに新しいに地理的なエリアを追加するときに便利です。
たとえば、営業のアプリケーションのワークロードが1つあるとします。スケールアップ・テストを実行して存在する場合にホストのボトルネックを特定するには、テスト・システムに営業スキーマの複数のスキーマを設定します。
|
関連項目:
|
この項では、次の内容で、ワークロードの統合リプレイの使用手順について説明します。
データベース統合リプレイ用にデータベース・ワークロードを取得するには、特別な手順は必要ありません。データベース・ワークロードを取得する手順は、第9章「データベース・ワークロードの取得」で説明されている、データベース・リプレイで単一のワークロードを取得する手順とまったく同じです。
この項では、データベース統合リプレイに固有なワークロードの取得に関して、次の内容で説明します。
データベース統合リプレイでは、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)以上のみで使用できます。 |
データベース統合リプレイでは、取得した既存のワークロードを、新しい小さな取得サブセットに変換することができます。その後、「データベース統合リプレイの使用事例」で説明する別の用途で使用する新しいワークロード取得に取得サブセットから生成できます。
取得サブセットとは、既存の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文、および開始時間が原因で不完全となってしまうユーザー・コールはこれに含まれます。
データベース統合リプレイ用のテスト・システムの設定は、「データベース・ワークロードのリプレイの手順」で説明されている、データベース・リプレイ用のテスト・システムの設定と類似しています。ただし、データベース統合リプレイ用にリプレイ・データベースを設定する場合には、他に考慮する必要のある事項があります。
リプレイ中の相違を最小限に抑えるには、テスト・システムには同じアプリケーション・データが必要であり、アプリケーション・データの状態は、ワークロードをそれぞれ取得開始したときの取得システムのデータの状態と論理的に同じにする必要があります。ただし、取得が統合されている場合、様々な本番システムのワークロード取得が複数含まれている可能性があるため、テスト・システムをすべての取得に対応するよう設定する必要があります。
データベース統合リプレイを行うには、関係しているすべてのワークロード取得を、テスト・システムの新しい取得ディレクトリの下に配置する必要があります。ワークロード取得をすべて新しい取得ディレクトリにコピーするか、元のワークロード取得をポイントするシンボリック・リンクを作成します。ワークロード取得を統合する前に、新しい取得ディレクトリに関係するすべての取得を格納する十分な空き領域があることを確認します。
図13-1に、テスト・システムと3つのワークロード取得を統合する新しい取得ディレクトリを設定する方法を示します。
データベース統合リプレイ用のデータベース・ワークロードの前処理は、第10章「データベース・ワークロードの前処理」で説明されている、データベース・リプレイ用のデータベース・ワークロードの前処理と類似しています。
データベース統合リプレイを行うには、取得した各ワークロードをその固有のディレクトリに前処理します。前処理を行う際には、別のワークロード取得を1つのディレクトリにまとめないようにする必要があります。取得済ワークロードの前処理は、ワークロードをリプレイするテスト・システムのOracle Databaseと同じバージョンのデータベースを使用して実行する必要があります。
データベース統合リプレイで統合されたワークロードのリプレイは、データベース・リプレイで1つのデータベース・ワークロードをリプレイすることとは大きく異なります。
この項では、データベース統合リプレイに固有なワークロードのリプレイに関して、次の内容で説明します。
リプレイ・スケジュールでは、1つまたは複数のワークロード取得を統合リプレイに追加し、取得のリプレイ開始順序を指定します。リプレイ・スケジュールは、統合リプレイを初期化する前に作成する必要があります。1回の統合リプレイには、複数のリプレイ・スケジュールを定義できます。リプレイの初期化時、既存のリプレイ・スケジュールの中から任意のものを選択できます。
リプレイ・スケジュールでは、2種類の操作が実行されます。
リプレイ・スケジュールでは、最初に関係するワークロード取得がリプレイに追加されます。
リプレイ・スケジュールにワークロード取得が追加されると、そのワークロード取得を識別する一意の番号が返されます。ワークロード取得には、追加のたびに別の番号が割り当てられるので、複数回リプレイ・スケジュールに追加することが可能です。リプレイ・スケジュールでは、追加のたびに取得をコピーしてディスク領域を無駄にしないために、都度同じ取得ディレクトリをポイントします。
次いで、リプレイ・スケジュールには、関係するワークロード取得のリプレイ時開始順序が追加されます。
スケジュール順序では、リプレイ・スケジュールに追加された2つのワークロード取得の開始順序が定義されます。リプレイ・スケジュールには、複数のスケジュール順序を追加できます。たとえば、リプレイ・スケジュールにワークロード取得が3つ追加されているとします。追加した1つのスケジュール順序では、取得2は取得1が完了してから開始するよう指定します。別のスケジュール順序では、取得3は取得1が完了してから開始するよう指定します。この場合、取得2も取得3も取得1が完了するのを待機してから開始する必要があります。
リプレイ・スケジュールには、必ずしもスケジュール順序を含める必要はありません。この場合、リプレイ・スケジュール内の関係するすべてのワークロード取得は、統合リプレイの開始時に同時にリプレイが開始されます。
「接続の再マッピング」で説明されている、データベース・リプレイを使用して1つのデータベース・ワークロードをリプレイする場合と同様に、本番システムに接続するために使用した取得した接続文字列を使用してリプレイ・システムに再マッピングする必要があります。
データベース統合リプレイを行うには、複数のワークロード取得の取得済接続文字列をリプレイ時に別の接続文字列に再マッピングする必要があります。
「ユーザーの再マッピング」で説明されている、データベース・リプレイを使用して1つのデータベース・ワークロードをリプレイする場合と同様に、本番システムに接続するために使用するデータベースのユーザー名およびスキーマはリプレイ時に再マッピングできます。
データベース統合リプレイの場合には、リプレイ時に、複数のワークロード取得からの取得済ユーザーを別のユーザーまたはスキーマに再マッピングするよう選択できます。
「リプレイ・オプションの指定」で説明されている、データベース・リプレイを使用した1つのデータベース・ワークロードのリプレイの場合と同様に、リプレイ・オプションはリプレイの準備時に定義します。
データベース統合リプレイでは、統合リプレイ内のすべての関係しているワークロード取得は、リプレイの準備時に定義された同じリプレイ・オプションを使用してリプレイされます。
第11章「データベース・ワークロードのリプレイ」で説明されているように、統合ワークロードをリプレイする前に、関係するワークロードを個々にリプレイすることをお薦めします。
個々にリプレイすることによって各ワークロード取得のベースライン・パフォーマンスを定めて、統合リプレイのパフォーマンスの分析に使用できます。
データベース統合リプレイのレポート作成と分析は、「期間比較レポートの使用」で説明されているように、リプレイの期間比較レポートを使用して実行されます。
データベース統合リプレイのリプレイの期間比較レポートには、個々のワークロード取得のアクティブ・セッション履歴(ASH)データがあり、ワークロード取得のASHデータが統合リプレイのフィルタされたASHデータと比較されています。このレポートを使用すると、同じ統合されているワークロード取得のリプレイを比較できます。
データベース統合リプレイのリプレイの期間比較レポートでは、統合リプレイを複数の取得とリプレイの比較として扱います。このレポートのサマリー・セクションには、取得とリプレイの比較を個々にまとめた表があります。このセクションの情報を確認すると、統合リプレイがどのように実行されたかの概要を理解できます。
図13-2に、データベース統合リプレイのサンプル・リプレイ期間比較レポートのサマリー・セクションを示します。
このレポートの残りのセクションは、リプレイの期間比較レポートのASHデータ比較セクションと似ており、統合リプレイ内のすべての取得とリプレイのレポートを結合したもので構成されています。このセクションの詳細は、「ASHデータ比較」を参照してください。
この項では、Enterprise Managerを使用してデータベース統合リプレイを使用する方法について説明します。
Oracle Enterprise Managerは、統合されたデータベース・ワークロードをリプレイする主要ツールです。Oracle Enterprise Managerを使用できない場合は、「APIを使用したデータベース統合リプレイの使用」で説明されているように、APIを使用してデータベース・ワークロードをリプレイできます。
統合されたデータベース・ワークロードをリプレイするプロセスは、単一のデータベース・ワークロードをリプレイするプロセスとほとんど同じです。違いは、次の項の単一のリプレイの手順で説明されています。
次のリストは、統合されたデータベース・ワークロードのリプレイと単一のデータベース・ワークロードのリプレイの違いのサマリーを示します。
リプレイ・タスクを作成する際、2つ以上の取得済ワークロードをタスクの作成ページの取得の選択表から選択する必要があります。
ウィザードの「取得されたワークロードの前処理: ワークロードのコピー」ステップには、「取得名」ドロップダウンの複数の選択肢があるため、ワークロード・ディレクトリの現在の場所の複数の資格証明を入力する必要がある場合があります。
ウィザードの「取得されたワークロードの前処理: ディレクトリを選択」ステップでは、単一のリプレイで表示されるように「取得サマリー」が表示されません。
ウィザードの「ワークロード・リプレイ: ワークロードのコピー」ステップには、「取得名」ドロップダウンの複数の選択肢があるため、ワークロード・ディレクトリの現在の場所の複数の資格証明を入力する必要がある場合があります。
ウィザードの「ワークロード・リプレイ: ディレクトリを選択」ステップでは、単一のリプレイで表示されるように「取得サマリー」が表示されません。
ウィザードの「ワークロード・リプレイ: 初期化オプション」ステップでは、「ソースを指定」セクションは表示されません。
ウィザードの「ワークロード・リプレイ: オプションのカスタマイズ」ステップの「接続マッピング」の「取得名」ドロップダウンには、1つ以上の選択肢が表示されるので、取得したワークロードの接続をそれぞれ再マッピングできます。1つの接続記述子またはネット・サービス名を使用することはできません。
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して統合済ワークロードを作成およびリプレイする方法を説明します。
APIを使用して統合されているワークロードを作成およびリプレイする手順は、次などの複数の手順を実行する必要があります。
|
関連項目: DBMS_WORKLOAD_REPLAYパッケージについては、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
この項では、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パッケージおよびタイプ・リファレンス』を参照してください。
例13-1では、ディレクトリ・オブジェクトrec_dirの既存のワークロード取得から、peak_wkldという名前の取得サブセットをディレクトリ・オブジェクトpeak_capdirに作成する方法を説明します。取得サブセットには、ワークロードの取得の開始から2時間(または7,200秒)から3時間(または10,800秒)のワークロードが含まれています。
例13-1 取得サブセットの生成
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パッケージおよびタイプ・リファレンス』を参照してください。 |
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用してテスト・システムにリプレイ・ディレクトリを設定する方法を説明します。リプレイ・ディレクトリを、リプレイするワークロード取得を含むテスト・システムのディレクトリに設定します。テスト・システムの設定の詳細は、「データベース統合リプレイ用のテスト・システムの設定」を参照してください。
リプレイ・ディレクトリを設定するには、次の手順に従います。
SET_REPLAY_DIRECTORYプロシージャを使用します。
DBMS_WORKLOAD_REPLAY.SET_REPLAY_DIRECTORY ( replay_dir IN VARCHAR2);
replay_dirパラメータをワークロードの統合に使用するワークロード取得を含むオペレーティング・システム・ディレクトリをポイントするディレクトリ・オブジェクト名に設定します。
例13-2に、リプレイ・ディレクトリをrep_dirというディレクトリ・オブジェクト名に設定する方法を示します。
また、DBMS_WORKLOAD_REPLAYパッケージを使用してSET_REPLAY_DIRECTORYプロシージャによって設定された現在のリプレイ・ディレクトリを参照することもできます。
設定されている現在のリプレイ・ディレクトリを確認するには、次の手順に従います。
GET_REPLAY_DIRECTORYファンクションを使用します。
DBMS_WORKLOAD_REPLAY.GET_REPLAY_DIRECTORY RETURN VARCHAR2;
リプレイ・ディレクトリが設定されていない場合、ファンクションでNULLが返されます。
|
関連項目:
|
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用してリプレイ・スケジュールを定義する方法を説明します。リプレイ・スケジュールの詳細は、「リプレイ・スケジュールの定義」を参照してください。
リプレイ・スケジュールを定義する前に、次の前提条件が満たされていることを確認します。
すべてのワークロード取得は、第10章「データベース・ワークロードの前処理」で説明されているように、リプレイ・システムと同じデータベース・バージョンを実行しているシステムでPROCESS_CAPTUREプロシージャを使用して前処理済です。
すべての取得ディレクトリは、リプレイ・システムのリプレイ・ディレクトリにコピー済です。
「APIを使用したリプレイ・ディレクトリ の設定」で説明されているように、リプレイ・ディレクトリがSET_REPLAY_DIRECTORYプロシージャを使用して設定済です。
データベースが、リプレイ・モードの状態ではありません。
リプレイ・スケジュールを定義するには、次の手順に従います。
「APIを使用したリプレイ・スケジュールの作成」で説明されているように新しいリプレイ・スケジュールを定義します。
「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」で説明されているように、リプレイ・スケジュールにワークロード取得を追加します。
「APIを使用したリプレイ・スケジュールへのスケジュール順序の追加」で説明されているように、リプレイ・スケジュールにスケジュール順序を追加します。
「APIを使用したリプレイ・スケジュールの保存」で説明されているように、リプレイ・スケジュールを保存します。
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用してリプレイ・スケジュールを作成する方法を説明します。リプレイ・スケジュールの詳細は、「リプレイ・スケジュールの定義」を参照してください。
リプレイ・スケジュールを作成するには、次の手順に従います。
BEGIN_REPLAY_SCHEDULEプロシージャを使用します。
DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ( schedule_name IN VARCHAR2);
schedule_nameパラメータをこのリプレイ・スケジュールの名前に設定します。
|
注意: BEGIN_REPLAY_SCHEDULEプロシージャでは、再利用可能なリプレイ・スケジュールの作成を開始します。リプレイ・スケジュールは1度に1つのみ定義できます。リプレイ・スケジュールの定義中にこのプロシージャを呼び出すと、エラーが発生します。 |
例13-3に、peak_scheduleというリプレイ・スケジュールを作成する方法を説明します。
|
関連項目: BEGIN_REPLAY_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
この項では、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パッケージおよびタイプ・リファレンス』を参照してください。
例13-4に、SELECT文でADD_CAPTUREファンクションを使用して、リプレイ・スケジュールにpeak_wkldというワークロード取得を追加する方法を示します。
リプレイ・スケジュールからワークロード取得を削除する場合、DBMS_WORKLOAD_REPLAYパッケージを使用することも可能です。
リプレイ・スケジュールからワークロード取得を削除するには、次の手順に従います。
DBMS_WORKLOAD_REPLAY.REMOVE_CAPTURE ( schedule_capture_number IN NUMBER);
schedule_capture_numberパラメータを、このリプレイ・スケジュールのワークロード取得を識別する一意の識別子に設定します。
この一意の識別子は、ワークロード取得がリプレイ・スケジュールに追加された際に、ADD_CAPTUREファンクションによって返された識別子と同じです。
|
関連項目:
|
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、スケジュール順序をリプレイ・スケジュールから削除および追加する方法を説明します。リプレイ・スケジュールにスケジュール順序を追加する方法の詳細は、「スケジュール順序の追加」を参照してください。
リプレイ・スケジュールにスケジュール順序を追加する前に、次の前提条件が満たされていることを確認します。
スケジュール順序を追加するリプレイ・スケジュールが作成済です。
リプレイ・スケジュールの作成の詳細は、「APIを使用したリプレイ・スケジュールの作成」を参照してください。
そのスケジュール順序に関係するすべてのワークロード取得がリプレイ・スケジュールに追加済です。
リプレイ・スケジュールへのワークロード取得の追加の詳細は、「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」を参照してください。
|
注意: リプレイ・スケジュールにはスケジュール順序を必ずしも追加する必要はありません。リプレイ・スケジュールにスケジュール順序を追加しない場合、統合リプレイが開始されるとき、リプレイ・スケジュールに追加されたすべてのワークロード取得が同時にリプレイされます。 |
リプレイ・スケジュールにスケジュール順序を追加するには、次の手順に従います。
ADD_SCHEDULE_ORDERINGファンクションを使用します。
DBMS_WORKLOAD_REPLAY.ADD_SCHEDULE_ORDERING ( schedule_capture_id IN VARCHAR2, wait_for_capture_id IN VARCHAR2) RETURN NUMBER;
このファンクションでは、リプレイ・スケジュールに追加された2つのワークロード取得間にスケジュール順序を追加します。スケジュール順序を追加できない場合、ゼロではないエラー・コードが返されます。
このスケジュール順序で待機するワークロード取得にschedule_capture_idパラメータを設定します。
このスケジュール順序で他のワークロード取得が開始される前に、完了するワークロード取得をwait_for_capture_idパラメータに設定します。
DBMS_WORKLOAD_REPLAYパッケージを使用して、リプレイ・スケジュールからスケジュール順序を削除することも可能です。
リプレイ・スケジュールからスケジュール順序を削除するには、次の手順に従います。
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ビューを使用します。
|
関連項目:
|
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して定義されたリプレイ・スケジュールを保存する方法を説明します。
リプレイ・スケジュールを保存する前に、次の前提条件が満たされていることを確認します。
保存するリプレイ・スケジュールが作成済です。
リプレイ・スケジュールの作成の詳細は、「APIを使用したリプレイ・スケジュールの作成」を参照してください。
そのスケジュール順序に関係するすべてのワークロード取得がリプレイ・スケジュールに追加済です。
リプレイ・スケジュールへのワークロード取得の追加の詳細は、「APIを使用したリプレイ・スケジュールへのワークロード取得の追加」を参照してください。
使用するすべてのスケジュール順序がリプレイ・スケジュールに追加済です(この手順は任意指定です)。
リプレイ・スケジュールにスケジュール順序を追加する方法の詳細は、「APIを使用したリプレイ・スケジュールへのスケジュール順序の追加」を参照してください。
リプレイ・スケジュールを保存するには、次の手順に従います。
END_REPLAY_SCHEDULEプロシージャを使用します。
DBMS_WORKLOAD_REPLAY.END_REPLAY_SCHEDULE;
この手順でリプレイ・スケジュールの作成が完了します。リプレイ・スケジュールがリプレイ・ディレクトリに関連付けられ保存されます。リプレイ・スケジュールは保存すると、統合リプレイ用に使用できます。
リプレイ・スケジュールを確認するには、次の手順に従います。
DBA_WORKLOAD_REPLAY_SCHEDULESビューを使用します。
|
関連項目:
|
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、データベース統合リプレイを実行する方法を説明します。統合リプレイの詳細は、「データベース統合リプレイ用のデータベース・ワークロードのリプレイ」を参照してください。
データベース統合リプレイを実行する前に、次の前提条件が満たされていることを確認します。
すべてのワークロード取得は、第10章「データベース・ワークロードの前処理」で説明されているように、リプレイ・システムと同じデータベース・バージョンを実行しているシステムでPROCESS_CAPTUREプロシージャを使用して前処理済です。
すべての取得ディレクトリは、リプレイ・システムのリプレイ・ディレクトリにコピー済です。
「APIを使用したリプレイ・ディレクトリ の設定」で説明されているように、リプレイ・ディレクトリがSET_REPLAY_DIRECTORYプロシージャを使用して設定済です。
データベースは、すべてのワークロード取得の開始時間にすべての取得システムと同じアプリケーション状態に論理的に復元されています。
データベース統合リプレイを実行するには、次の手順に従います。
「APIを使用したデータベース統合リプレイの初期化」で説明されているように、リプレイ・データを初期化します。
「APIを使用した接続の再マッピング」で説明されているように、接続文字列を再マッピングします。
「APIを使用したユーザーの再マッピング」で説明されているように、ユーザーを再マッピングします。
ユーザーの再マッピングは任意です。
「APIを使用したデータベース統合リプレイの準備」で説明されているように、統合リプレイを準備します。
「リプレイ・クライアントの設定」で説明されているように、リプレイ・クライアントを設定して開始します。
「APIを使用したデータベース統合リプレイの開始」で説明されているように、統合リプレイを開始します。
「データベース統合リプレイのレポート作成および分析」で説明されているように、レポート作成および分析を行います。
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイ用にリプレイ・データを初期化する方法を説明します。
リプレイ・データを初期化すると次の操作が実行されます。
データベースの状態が統合ワークロードのリプレイ用に初期化モードになります。
リプレイ・スケジュールに関係するすべてのワークロード取得を含むリプレイ・ディレクトリがポイントされます。
リプレイに必要なメタデータが表にロードされます。
たとえば、取得した接続文字列が、リプレイ用に再マッピング可能な表にロードされます。
データベース統合リプレイを初期化するには、次の手順に従います。
INITIALIZED_CONSOLIDATED_REPLAYプロシージャを使用します。
DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ( replay_name IN VARCHAR2, schedule_name IN VARCHAR2);
replay_nameパラメータを統合リプレイの名前に設定します。
schedule_nameパラメータを使用するリプレイ・スケジュールの名前に設定します。
schedule_nameパラメータは、「APIを使用したリプレイ・スケジュールの作成」で説明されているように、その作成時に使用されたリプレイ・スケジュールの名前です。
例13-5に、peak_scheduleという名前のリプレイ・スケジュールを使用して、peak_replayという名前の統合リプレイを初期化する方法を説明します。
例13-5 データベース統合リプレイの初期化
EXEC DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ('peak_replay',
'peak_schedule');
|
関連項目: INITIALIZE_CONSOLIDATED_REPLAYプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
この項では、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パッケージおよびタイプ・リファレンス』を参照してください。 |
この項では、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に設定されている場合、マッピングは無効です。
例13-6では、1001のワークロード取得のリプレイ中に、取得中に使用されたPRODユーザーをTESTユーザーに再マッピングする方法を示します。
|
関連項目: SET_USER_MAPPINGプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して統合リプレイを準備する方法を説明します。統合リプレイの準備の詳細は、「データベース統合リプレイの準備」を参照してください。
統合リプレイを準備する前に、次の前提条件が満たされていることを確認します。
「APIを使用したデータベース統合リプレイの初期化」で説明されているように、リプレイ・データが初期化済です。
「APIを使用した接続の再マッピング」で説明されているように、取得済の接続が再マッピング済です。
「APIを使用したユーザーの再マッピング」で説明されているように、ユーザーが再マッピング済です。
ユーザーの再マッピングは任意です。ただし、リプレイ時にユーザーを再マッピングする予定の場合、統合リプレイを準備する前にそれが完了している必要があります。
統合リプレイの準備では、次の操作が実行されます。
同期モード(またはCOMMIT順序)、セッションの接続率およびセッションのリクエスト率などのリプレイ・オプションが指定されます。
データベースがリプレイ・モードになります。
リプレイ・クライアントの起動が有効になります。
|
注意: データベース統合リプレイでは、非同期モードおよび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プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
この項では、DBMS_WORKLOAD_REPLAYパッケージを使用して、統合リプレイを開始する方法を説明します。
統合リプレイを開始する前に、次の前提条件が満たされていることを確認します。
「APIを使用したデータベース統合リプレイの準備」で説明されているように、統合リプレイが準備済です。
十分な数のリプレイ・クライアントが起動済です。
リプレイ・クライアントの設定および開始の詳細は、「リプレイ・クライアントの設定」を参照してください。
統合リプレイを開始するには、次の手順に従います。
|
関連項目: START_CONSOLIDATED_REPLAYプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
この項では、データベース統合リプレイで次のワークロード・スケールアップ・テクニックを使用してストレス・テストおよびスケールアップ・テストを実行する例について説明します。
この項では、タイム・シフトを使用し、3つのアプリケーションから取得したワークロードのピークを合わせて同時にリプレイするシナリオを想定し、データベース統合リプレイでタイム・シフトを使用する方法を説明します。このシナリオでは、タイム・シフトを使用しストレス・テストを実行する方法を説明します。タイム・シフトの詳細は、「タイム・シフトについて」を参照してください。
このシナリオでは、次を想定しています。
最初のワークロードは、営業アプリケーションから取得します。
2つ目のワークロードは、ピーク時間が営業ワークロードの1時間前であるCRMアプリケーションから取得します。
3つ目のワークロードは、ピーク時間が営業ワークロードの30分前であるDWアプリケーションから取得します。
これらのワークロードのピークを合わせるために、リプレイ時にCRMワークロードに1時間の遅延を、DWワークロードには30分の遅延を追加してタイム・シフトを実行します。
このシナリオでタイム・シフトを実行するには、次の手順を実行します。
ストレス・テストを実行するリプレイ・システムで、取得したワークロードが保存されているルート・ディレクトリにディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY cons_dir AS '/u01/test/cons_dir';
取得した個々のワークロードを別のディレクトリに事前処理します。
営業ワークロードでは、次の手順を実行します。
ディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY sales AS '/u01/test/cons_dir/cap_sales';
営業アプリケーションから取得したワークロードがこのディレクトリに格納されていることを確認します。
ワークロードを事前処理します。
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('SALES');
CRMワークロードには、次を実行します。
ディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY crm AS '/u01/test/cons_dir/cap_crm';
CRMアプリケーションから取得したワークロードがこのディレクトリに格納されていることを確認します。
ワークロードを事前処理します。
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('CRM');
DWワークロードには、次の手順を実行します。
ディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY DW AS '/u01/test/cons_dir/cap_dw';
DWアプリケーションから取得したワークロードがこのディレクトリに格納されていることを確認します。
ワークロードを事前処理します。
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('DW');
ルート・ディレクトリをリプレイ・ディレクトリに設定します。
EXEC DBMS_WORKLOAD_REPLAY.SET_REPLAY_DIRECTORY ('CONS_DIR');
リプレイ・スケジュールを作成し、ワークロード取得を追加します。
EXEC DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ('align_peaks_schedule');
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('SALES') FROM dual;
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('CRM', 3600) FROM dual;
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('DW', 1800) FROM dual;
EXEC DBMS_WORKLOAD_REPLAY.END_REPLAY_SCHEDULE;
3,600秒(または1時間)の遅延がCRMワークロードに追加され、1,800秒の遅延(または30分)がDWワークロードに追加されます。
統合リプレイを初期化します。
EXEC DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ('align_peaks_replay',
'align_peaks_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 => 'inst1');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 1,
conn_id => 2, replay_connection => 'inst1');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 2,
conn_id => 1, replay_connection => 'inst2');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 2,
conn_id => 2, replay_connection => 'inst2');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 3,
conn_id => 1, replay_connection => 'inst3');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 3,
conn_id => 2, replay_connection => 'inst3');
replay_connectionパラメータは、テスト・システムに定義したサービスを示します。
接続の再マッピングを確認します。
SELECT schedule_cap_id, conn_id, capture_conn, replay_conn FROM dba_workload_connection_map;
統合リプレイを準備します。
EXEC DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY;
リプレイ・クライアントを起動します。
必要なリプレイ・クライアントの数を見積もります。
wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_sales wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_crm wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_dw
必要なリプレイ・クライアントの数を判断するために出力を追加します。
統合したワークロードに含まれるワークロード取得ごとに、最低1つのリプレイ・クライアントを開始する必要があります。
このコマンドを繰り返し、必要な数のリプレイ・クライアントを起動します。
wrc username/password mode=replay replaydir=/u01/test/cons_dir
replaydirパラメータは、ワークロード取得が格納されているルート・ディレクトリに設定されています。
統合リプレイを開始します。
EXEC DBMS_WORKLOAD_REPLAY.START_CONSOLIDATED_REPLAY;
この項では、ワークロードの縮小を使用して取得したワークロードを3倍にするシナリオを想定し、データベース統合リプレイでワークロードの縮小を使用する方法を説明します。このシナリオでは、スケールアップ・テストでワークロードの縮小を使用する方法を説明します。ワークロードの縮小の詳細は、「ワークロードの縮小について」を参照してください。
このシナリオでは、次を想定しています。
元のワークロードは午前2時から午後8時まで取得され、3つの取得サブセットに縮小されました。
最初の取得のサブセットは、元のワークロードの午前2時から午後8時の部分です。
2つ目の取得のサブセットは、元のワークロードの午前8時から午後2時の部分です。
3つ目の取得のサブセットは、元のワークロードの午後2時から午後8時の部分です。
リプレイ時にワークロードを3倍にするために、3つの取得サブセットを同時にリプレイすることでワークロードの縮小が実行されます。
このシナリオでワークロードの縮小を実行するには、次の手順を実行します。
スケールアップ・テストを実行する計画のあるリプレイ・システムで、取得したワークロードが保存されているルート・ディレクトリにディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY cons_dir AS '/u01/test/cons_dir';
元のワークロードが保存されているディレクトリにディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY cap_monday AS '/u01/test/cons_dir/cap_monday';
取得サブセットを保存する予定のディレクトリにディレクトリ・オブジェクトを作成します。
最初の取得サブセットのディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY cap_mon_2am_8am
AS '/u01/test/cons_dir/cap_monday_2am_8am';
2つ目の取得サブセットのディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY cap_mon_8am_2pm
AS '/u01/test/cons_dir/cap_monday_8am_2pm';
3つ目の取得サブセットのディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY cap_mon_2pm_8pm
AS '/u01/test/cons_dir/cap_monday_2pm_8pm';
取得サブセットを作成します。
午前2時から午前8時の期間の1つ目の取得サブセットを生成します。
EXEC DBMS_WORKLOAD_REPLAY.GENERATE_CAPTURE_SUBSET ('CAP_MONDAY',
'CAP_MON_2AM_8AM', 'mon_2am_8am_wkld',
0, TRUE, 21600, FALSE, 1);
午前8時から午後2時の期間の2つ目の取得サブセットを生成します。
EXEC DBMS_WORKLOAD_REPLAY.GENERATE_CAPTURE_SUBSET ('CAP_MONDAY',
'CAP_MON_8AM_2PM', 'mon_8am_2pm_wkld',
21600, TRUE, 43200, FALSE, 1);
午後2時から午後8時の期間の3つ目の取得サブセットを生成します。
EXEC DBMS_WORKLOAD_REPLAY.GENERATE_CAPTURE_SUBSET ('CAP_MONDAY',
'CAP_MON_2PM_8PM', 'mon_2pm_8pm_wkld',
43200, TRUE, 0, FALSE, 1);
取得サブセットを事前処理します。
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('CAP_MON_2AM_8AM');
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('CAP_MON_8AM_2PM');
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('CAP_MON_2PM_8PM');
ルート・ディレクトリをリプレイ・ディレクトリに設定します。
EXEC DBMS_WORKLOAD_REPLAY.SET_REPLAY_DIRECTORY ('CONS_DIR');
リプレイ・スケジュールを作成し、取得サブセットを追加します。
EXEC DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ('monday_folded_schedule');
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('CAP_MON_2AM_8AM') FROM dual;
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('CAP_MON_8AM_2PM') FROM dual;
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('CAP_MON_2PM_8PM') FROM dual;
EXEC DBMS_WORKLOAD_REPLAY.END_REPLAY_SCHEDULE;
統合リプレイを初期化します。
EXEC DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY (
'monday_folded_replay', 'monday_folded_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 => 'inst1');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 1,
conn_id => 2, replay_connection => 'inst1');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 2,
conn_id => 1, replay_connection => 'inst2');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 2,
conn_id => 2, replay_connection => 'inst2');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 3,
conn_id => 1, replay_connection => 'inst3');
EXEC DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (schedule_cap_id => 3,
conn_id => 2, replay_connection => 'inst3');
replay_connectionパラメータは、テスト・システムに定義したサービスを示します。
接続の再マッピングを確認します。
SELECT schedule_cap_id, conn_id, capture_conn, replay_conn FROM dba_workload_connection_map;
統合リプレイを準備します。
EXEC DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY;
リプレイ・クライアントを起動します。
必要なリプレイ・クライアントの数を見積もります。
wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_monday_2am_8am wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_monday_8am_2pm wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_monday_2pm_8pm
必要なリプレイ・クライアントの数を判断するために出力を追加します。
統合したワークロードに含まれるワークロード取得ごとに、最低1つのリプレイ・クライアントを開始する必要があります。
このコマンドを繰り返し、必要な数のリプレイ・クライアントを起動します。
wrc username/password mode=replay replaydir=/u01/test/cons_dir
replaydirパラメータは、ワークロード取得が格納されているルート・ディレクトリに設定されています。
統合リプレイを開始します。
EXEC DBMS_WORKLOAD_REPLAY.START_CONSOLIDATED_REPLAY;
この項では、アプリケーションにインスタンスを複数デプロイした場合にホストで発生する可能性のあるボトルネックを特定するためにスキーマの再マッピングを使用するシナリオを想定し、データベース統合リプレイでスキーマの再マッピングを使用する方法を説明します。このシナリオでは、スケールアップ・テストでスキーマの再マッピングを使用する方法を説明します。スキーマの再マッピングの詳細は、「スキーマの再マッピングについて」を参照してください。
このシナリオでは、次を想定しています。
営業アプリケーションから取得したワークロードが1つあります。
営業スキーマの複数のスキーマをリプレイ・システムに設定するために、取得したワークロードを複数回リプレイ・スケジュールに追加してユーザーを別のスキーマに再マッピングします。
このシナリオでスキーマの再マッピングを実行するには、次の手順を実行します。
スケールアップ・テストを実行する計画のあるリプレイ・システムで、取得したワークロードが保存されているルート・ディレクトリにディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY cons_dir AS '/u01/test/cons_dir';
取得したワークロードが保存されているディレクトリにディレクトリ・オブジェクトを作成します。
CREATE OR REPLACE DIRECTORY cap_sales AS '/u01/test/cons_dir/cap_sales';
営業アプリケーションから取得したワークロードがこのディレクトリに格納されていることを確認します。
取得したワークロードを事前処理します。
EXEC DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ('CAP_SALES');
ルート・ディレクトリをリプレイ・ディレクトリに設定します。
EXEC DBMS_WORKLOAD_REPLAY.SET_REPLAY_DIRECTORY ('CONS_DIR');
リプレイ・スケジュールを作成し、取得したワークロードを複数回追加します。
EXEC DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ('double_sales_schedule');
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('CAP_SALES') FROM dual;
SELECT DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ('CAP_SALES') FROM dual;
EXEC DBMS_WORKLOAD_REPLAY.END_REPLAY_SCHEDULE;
統合リプレイを初期化します。
EXEC DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY (
'double_sales_replay', 'double_sales_schedule);
ユーザーを再マッピングします。
EXEC DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING (2, 'sales_usr', 'sales_usr_2');
統合リプレイを準備します。
EXEC DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY;
リプレイ・クライアントを起動します。
必要なリプレイ・クライアントの数を見積もります。
wrc mode=calibrate replaydir=/u01/test/cons_dir/cap_sales
必要なリプレイ・クライアントの数を判断するために出力を追加します。
統合したワークロードに含まれるワークロード取得ごとに、最低1つのリプレイ・クライアントを開始する必要があります。
このコマンドを繰り返し、必要な数のリプレイ・クライアントを起動します。
wrc username/password mode=replay replaydir=/u01/test/cons_dir
replaydirパラメータは、ワークロード取得が格納されているルート・ディレクトリに設定されています。
統合リプレイを開始します。
EXEC DBMS_WORKLOAD_REPLAY.START_CONSOLIDATED_REPLAY;
