DBMS_WORKLOAD_REPLAY
パッケージは、ワークロード取得をリプレイするためのインタフェースを提供します。
関連項目: データベース・リプレイの詳細は、『Oracle Database Real Application Testingユーザーズ・ガイド』を参照してください。 |
この章では、次の項目について説明します。
概要
セキュリティ・モデル
DBMS_WORKLOAD_REPLAY
パッケージでは、DBMS_WORKLOAD_CAPTUREパッケージによって最初に作成されたワークロード取得をリプレイするために使用されるインタフェースが提供されます。通常、DBMS_WORKLOAD_CAPTURE
パッケージは、本番システムで本番ワークロードを取得する場合に使用され、DBMS_WORKLOAD_REPLAY
パッケージは、その後、取得された本番ワークロードをテストするためにテスト・システムでリプレイする場合に使用されます。
この項で示すコードには、次の操作に必要な最小限の権限が記述されています。
ディレクトリ・オブジェクトの作成
DBMS_WORKLOAD_CAPTURE
およびDBMS_WORKLOAD_REPLAY
パッケージで提供されるインタフェースの操作
リプレイ・クライアント・ユーザー(wrc someuser
/somepassword
またはwrc USER=someuser
PASSWORD=somepassword
)としての動作
DROP USER rom1 CASCADE; CREATE USER rom1 IDENTIFIED BY rom1; GRANT EXECUTE ON DBMS_WORKLOAD_CAPTURE TO rom1; GRANT EXECUTE ON DBMS_WORKLOAD_REPLAY TO rom1; GRANT CREATE SESSION TO rom1; GRANT CREATE ANY DIRECTORY TO rom1; GRANT SELECT_CATALOG_ROLE TO rom1; GRANT BECOME USER TO rom1;
取得システムとリプレイ・システムの両方にあるファイルおよびディレクトリに対してアクセスおよび操作を行うには、適切なOS権限が必要です。取得またはリプレイを実行しているOracleプロセスおよびOSユーザーは、インスタンスが実行されているホストからアクセス可能な1つ以上の共通ディレクトリに対してアクセスおよび操作を行うことができる必要があります。
リプレイ・クライアントはマルチスレッド化されたプログラム($ORACLE_HOME/bin
ディレクトリにあるwrc
という名の実行可能ファイル)で、スレッドごとに取得済セッションからワークロードを発行します。リプレイを実行しているOSユーザーは、必要に応じてリプレイ・クライアントのホストに取得データをコピーできるように、リプレイ・クライアントで使用されるホスト上でのwrc
の実行およびファイル・システムへの適切なアクセスを行うことができる必要があります。
次の表に、このパッケージのサブプログラムをアルファベット順に示します。
表161-1 DBMS_WORKLOAD_REPLAYパッケージのサブプログラム
サブプログラム | 説明 |
---|---|
|
特定の取得を現在のスケジュールに追加します。 |
|
取得されたワークロードのサブセットのみをリプレイするフィルタを追加します。 |
|
2つの取得間のスケジュール順序を追加します。 |
|
再使用可能なリプレイ・スケジュールの作成を開始します。 |
|
処理されたワークロード取得ディレクトリで動作し、指定したワークロードを正確にリプレイするために必要とされるホストおよびワークロード・リプレイ・クライアントの数を見積もります。 |
|
進行中のワークロードのリプレイを取り消します。 |
|
リプレイとその取得、またはリプレイと同じ取得の別のリプレイを比較するレポートを生成します。 |
|
リプレイ中に取得されたsqlsetと、ワークロード取得中に取得されたsqlsetまたは同じ取得の別のリプレイ中に取得されたsqlsetを比較するレポートを生成します。 |
|
追加されたリプレイ・フィルタを使用して、 |
|
指定されたフィルタを削除します。 |
|
指定したワークロード・リプレイIDに対応する |
|
現在のスケジュールの作成を完了します。 |
|
指定されたリプレイIDに関連付けられている自動ワークロード・リポジトリ(AWR)のスナップショットをエクスポートします。 |
|
既存のワークロード取得から新しい取得を作成します。 |
GET_DIVERGING_STATEMENTファンクション |
指定されたリプレイIDに関連付けられている自動ワークロード・リポジトリ(AWR)のスナップショットをエクスポートします。 |
|
SET_REPLAY_DIRECTORYプロシージャによって設定された現在のリプレイ・ディレクトリを戻します。 |
|
ワークロード取得に関する情報と、関連ディレクトリからのすべてのワークロード・リプレイ試行の履歴に関する情報を取得します。 |
|
リプレイのタイムアウト設定を取得します。 |
|
指定されたリプレイIDに関連付けられている自動ワークロード・リポジトリ(AWR)のスナップショットをインポートします。 |
INITIALIZE_CONSOLIDATED_REPLAYプロシージャ |
複数の取得リプレイに対してデータベースの状態を |
|
リプレイを初期化し、処理中に生成された特定のデータをデータベースにロードします。 |
|
リプレイが一時停止中かどうかをレポートします。 |
|
進行中のワークロードのリプレイを一時停止します。 |
|
特定のコール、ストリームまたはリプレイ全体の相違情報を事前計算して、GET_DIVERGING_STATEMENTファンクションが事前計算されたコールに可能な限り迅速に戻ることができるようにします。 |
|
データベースを特別な「準備」モードにします。 |
PREPARE_CONSOLIDATED_REPLAYプロシージャ |
複数の取得リプレイに対してデータベースを特別な「準備」モードにします。 |
|
|
|
ワークロードのリプレイ中にユーザー・セッションが希望の方法でデータベースに接続できるように、取得された接続を新しい接続に再マップします。 |
|
現在のスケジュールから特定の取得を削除します。 |
REMOVE_SCHEDULE_ORDERINGプロシージャ |
現在のリプレイ・スケジュールから既存のスケジュール順序を削除します。 |
|
特定のワークロードのリプレイに関するレポートを生成します。 |
|
一時停止しているワークロードのリプレイを再開します。 |
|
指定されたフィルタ・セットの各フィルタを、ADD_SCHEDULE_ORDERINGプロシージャを使用して追加する場合と同じように再利用します。 |
|
PREPARE_REPLAYプロシージャで使用されるパラメータ以外に、リプレイに対して詳細なパラメータを設定します。 |
|
複数のワークロード取得を含むディレクトリを現在のリプレイ・ディレクトリとして設定します。 |
|
リプレイのタイムアウト設定を指定します。 |
|
取得されたユーザーのかわりに、リプレイ中に使用する新規スキーマまたはユーザー名を設定します。 |
START_CONSOLIDATED_REPLAYプロシージャ |
複数の取得のリプレイを開始します。 |
|
ワークロードのリプレイを開始します。 |
|
CREATE_FILTER_SETプロシージャをコールして作成された特定のフィルタ・セットを使用して、現行のリプレイをフィルタ処理します。 |
このファンクションは、特定の取得を現在のスケジュールに追加します。ディレクトリは、現行データベースのバージョンで処理された、有効な取得である必要があります。このスケジュール内の取得を識別する一意のIDを戻します。
構文
DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ( capture_dir_name IN VARCHAR2, start_delay_seconds IN NUMBER DEFAULT 0, stop_replay IN BOOLEAN FALSE, take_begin_snapshot IN BOOLEAN TRUE, take_end_snapshot IN BOOLEAN TRUE, query_only IN BOOLEAN DEFAULT FALSE) RETURN NUMBER; DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ( capture_dir_name IN VARCHAR2, start_delay_seconds IN NUMBER DEFAULT 0, stop_replay IN BOOLEAN FALSE, take_begin_snapshot IN BOOLEAN TRUE, take_end_snapshot IN BOOLEAN TRUE, query_only IN VARCHAR2 DEFAULT 'N') RETURN NUMBER;
パラメータ
表161-2 ADD_CAPTUREファンクションのパラメータ
パラメータ | 説明 |
---|---|
|
リプレイの最上位のディレクトリの下に取得を含むOSディレクトリの名前。 |
|
この取得のリプレイが開始されるまでの遅延時間(秒単位)。 |
|
リプレイを終了後に停止します。 |
|
この取得のリプレイが開始されるときにAWRスナップショットを取ります。 |
|
この取得のリプレイが終了するときにAWRスナップショットを取ります。 |
|
このワークロード取得の読取り専用問合せのみをリプレイします。 |
このプロシージャは、取得されたワークロードのサブセットのみをリプレイするフィルタを追加します。
プロシージャによって追加される新しいフィルタは、CREATE_FILTER_SETプロシージャで作成される次のリプレイ・フィルタ・セットで使用されます。このフィルタは、フィルタ・セットの作成時にCREATE_FILTER_SET
に渡される引数に応じて、「INCLUSION
」または「EXCLUSION
」フィルタとみなされます。
構文
DBMS_WORKLOAD_REPLAY.ADD_FILTER ( fname IN VARCHAR2, fattribute IN VARCHAR2, fvalue IN VARCHAR2); DBMS_WORKLOAD_REPLAY.ADD_FILTER ( fname IN VARCHAR2, fattribute IN VARCHAR2, fvalue IN NUMBER);
パラメータ
表161-3 ADD_FILTERプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
フィルタ名(必須)。後でフィルタが不要になった場合、削除するときに使用できます。 |
|
|
|
フィルタがアクティブであるとみなされるようにするために、特定の属性と同じにする必要のある値を指定します(必須)。 |
このファンクションは、2つの取得間のスケジュール順序を追加します。schedule_capture_id
とwaitfor_capture_idを同時に指定することで、以前はADD_SCHEDULE_ORDERINGファンクションにより追加されていたスケジュール順序が構成されます。この順序では、waiting_for_capture_id
により指定された取得のリプレイが終了しないかぎり、schedule_capture_id
により指定された取得のリプレイは開始しません。
構文
DBMS_WORKLOAD_REPLAY.ADD_SCHEDULE_ORDERING ( schedule_capture_id IN VARCHAR2, waitfor_capture_id IN VARCHAR2) RETURN NUMBER;
パラメータ
表161-4 ADD_SCHEDULE_ORDERINGファンクションのパラメータ
パラメータ | 説明 |
---|---|
|
現在のリプレイ・スケジュールに追加された取得をポイントします。このサブプログラムにより追加された新規のスケジュール順序によると、そのリプレイは、 |
|
現在のリプレイ・スケジュールに追加された取得をポイントします。このサブプログラムにより追加された新規のスケジュール順序によると、 |
このプロシージャは、再使用可能なリプレイ・スケジュールの作成を開始します。
構文
DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ( replay_dir_obj IN VARCHAR2, schedule_name IN VARCHAR2);
使用上の注意
作成モードにできるスケジュールは、一度に1つのみです。end_replay_schedule
の前にこのサブプログラムを再度コールすると、エラーが発生します。
前提条件は次のとおりです。
同じデータベース・バージョンで、PROCESS_CAPTUREプロシージャを使用して、ワークロード取得がすでに処理されています。
取得ディレクトリを適切にコピーしておく必要があります。
データベースがリプレイ・モードではありません。
SET_REPLAY_DIRECTORYプロシージャがすでにコールされています。
このファンクションは、処理されたワークロード取得ディレクトリで動作し、指定したワークロードを正確にリプレイするために必要とされるホストおよびワークロード・リプレイ・クライアントの数を見積もります。このファンクションは、結果をXML CLOB
として戻します。
構文
DBMS_WORKLOAD_REPLAY.CALIBRATE ( capture_dir IN VARCHAR2, process_per_cpu IN BINARY_INTEGER DEFAULT 4, threads_per_process IN BINARY_INTEGER DEFAULT 50) RETURN CLOB;
戻り値
次の情報が含まれているXML形式のCLOB
を戻します。
取得に関する情報
現行のデータベース・バージョン
このファンクションへの入力パラメータ
指定したワークロードのリプレイに必要なCPUおよびリプレイ・クライアントの数
取得されたセッションに関する情報(合計数および最大同時実行)
使用上の注意
前提条件: 同じデータベース・バージョンで、PROCESS_CAPTUREプロシージャを使用して、入力ワークロード取得がすでに処理されています。
このプロシージャは、calibrateモードでのワークロード・リプレイ・クライアントと同じ結果を戻します。calibrateモードは、次のように実行できます。
$ wrc mode=calibrate replaydir=
このプロシージャは、進行中のワークロードのリプレイを取り消します。すべての外部リプレイ・クライアント(WRC)は、取得したワークロードの発行を停止し、終了するように自動的に通知されます。
このプロシージャは、リプレイとその取得、またはリプレイと同じ取得の別のリプレイを比較するレポートを生成します。
このプロシージャは、リプレイ中に取得されたsqlsetと、ワークロード取得中に取得されたsqlsetまたは同じ取得の別のリプレイ中に取得されたsqlsetを比較するレポートを生成します。
構文
DBMS_WORKLOAD_REPLAY.COMPARE_SQLSET_REPORT ( replay_id1 IN NUMBER, replay_id2 IN NUMBER, format IN VARCHAR2, r_level IN VARCHAR2 DEFAULT 'ALL', r_sections IN VARCHAR2 DEFAULT 'ALL', result OUT CLOB ) RETURN VARCHAR2;
パラメータ
表161-9 COMPARE_SQLSET_REPORTファンクションのパラメータ
パラメータ | 説明 |
---|---|
|
変更後のワークロード・リプレイを示す1番目のID。 |
|
変更前のワークロード・リプレイを示す2番目のID。これが |
|
レポートの書式を指定します。有効な値は、 |
|
DBMS_SQLPAパッケージのREPORT_ANALYSIS_TASKファンクションの |
|
DBMS_SQLPAパッケージのREPORT_ANALYSIS_TASKファンクションの |
|
レポートの出力( |
このプロシージャは、replay_dir
でリプレイに対してフィルタ・セットを新規に作成します。これには、すでにADD_FILTER Procedureによって追加されたリプレイ・フィルタがすべて含まれます。プロシージャが完了してリプレイが開始された後、新規作成されたフィルタ・セットを使用して、USE_FILTER_SETプロシージャ
をコールすることでreplay_dirのリプレイをフィルタ処理できます。
構文
DBMS_WORKLOAD_REPLAY.CREATE_FILTER_SET( replay_dir IN VARCHAR2, filter_set IN VARCHAR2, default_action IN VARCHAR2 DEFAULT 'INCLUDE');
パラメータ
表161-10 CREATE_FILTER_SETプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
フィルタ処理するリプレイのオブジェクト・ディレクトリ |
|
作成するフィルタ・セットの名前(USE_FILTER_SETプロシージャで使用されます)。 |
|
デフォルト: |
このプロシージャは、現在のスケジュールの作成を完了します。スケジュールが保存され、リプレイ・ディレクトリに関連付けられ、リプレイに使用できるようになります。
このプロシージャは、規定のリプレイIDに関連付けられたAWRスナップショットをエクスポートします。
使用上の注意
各リプレイの最後に、対応するAWRスナップショットが自動的にエクスポートされます。そのため、EXPORT_AWR
の自動起動が失敗しないかぎり、ワークロードのリプレイが完了した後に手動でエクスポートする必要はありません。
このプロシージャは対応するワークロードのリプレイが現行のデータベースで実行され(このことは、DBA_WORKLOAD_REPLAYS
内の対応する行がGET_REPLAY_INFOファンクションのコールによって作成されていないことを意味します)、そのリプレイ時間に対応するAWRスナップショットが使用可能である場合にのみ機能します。
このプロシージャは、既存のワークロード取得から新しい取得を作成します。
構文
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);
パラメータ
表161-14 GENERATE_CAPTURE_SUBSETプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
既存のワークロード取得を指すディレクトリ・オブジェクトの名前(必須)。 |
|
新しい取得を指すディレクトリ・オブジェクトの名前(必須)。 |
|
新しい取得の名前(必須)。 |
|
時間範囲の開始: ワークロード取得の開始からの時間オフセット(秒単位)。 |
|
|
|
時間範囲の終了: ワークロード取得の開始からの時間オフセット(秒単位)。 |
|
|
|
入力取得を並行処理するために使用されるOracleプロセスの数。 |
このファンクションは、相違コールに関する情報(文のテキスト、SQL ID、バインドなど)を取得します。記録されたユーザー・コールのリプレイにデータまたはエラーの相違がある場合は、相違コールになります。
構文
DBMS_WORKLOAD_REPLAY.GET_DIVERGING_STATEMENT ( replay_id IN NUMBER, stream_id IN NUMBER, call_counter IN NUMBER) RETURN CLOB;
使用上の注意
次の情報が含まれているXML形式のCLOB
を戻します。
SQL ID
SQLテキスト
バインド情報(位置、名前、値)
このファンクションは、POPULATE_DIVERGENCEプロシージャを黙示的に起動して、取得ファイルから情報を読み取ります。そのため、相違が移入されていない場合には、特定の相違コールに対してこのファンクションを最初にコールする際に時間がかかることがあります(特に、取得が大規模な場合には時間がかかる可能性があります)。
このファンクションは、SET_REPLAY_DIRECTORYプロシージャによって設定された現在のリプレイ・ディレクトリを戻します。リプレイ・ディレクトリが設定されていない場合、NULL
が戻されます。
このファンクションは、ワークロード取得に関する情報と、規定のディレクトリからのすべてのワークロード・リプレイ試行の履歴に関する情報を取得します。
このプロシージャは、リプレイのタイムアウト設定を取得します。
構文
DBMS_WORKLOAD_REPLAY.GET_REPLAY_TIMEOUT ( enabled OUT BOOLEAN, min_delay OUT NUMBER, max_delay OUT NUMBER, delay_factor OUT NUMBER);
パラメータ
表161-17 GET_REPLAY_TIMEOUTプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
タイムアウト・アクションが有効にされている場合は |
|
コール遅延の下限(分単位)。リプレイ・アクションは、遅延が |
|
コール遅延の上限(分単位)。遅延が |
|
|
このプロシージャは、指定したリプレイからAWRスナップショットをインポートします。
構文
DBMS_WORKLOAD_REPLAY.IMPORT_AWR ( replay_id IN NUMBER, staging_schema IN VARCHAR2) RETURN NUMBER;
戻り値
AWRスナップショットをインポートするときに使用した、ランダムに生成された新しいデータベースIDを戻します。DBA_WORKLOAD_REPLAYS
ビューのAWR_DBID
列に同じ値があります。
使用上の注意
このプロシージャは、それらのAWRスナップショットがEXPORT_AWRプロシージャを使用して、元のリプレイ・システムから事前にエクスポートされていた場合に機能します。
入力として指定したstaging_schema
に、任意のAWR表と同じ名前(WRM$_SNAPSHOT
、WRH$_PARAMETER
など)を持つ表が含まれている場合、IMPORT_AWR
は失敗します。このような表をstaging_schema
から削除してから、IMPORT_AWR
を起動します。
このプロシージャは、複数の取得リプレイに対してデータベースの状態をINIT
に設定します。SET_REPLAY_DIRECTORYプロシージャによって定義されたreplay_dir
を使用し、スケジュール関連のすべての取得ディレクトリを含むディレクトリを指します。スケジュールschedule_name
に関するデータをディレクトリから読み取り、必要な接続データをリプレイ・システムにロードします。
構文
DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ( replay_name IN VARCHAR2, schedule_name IN VARCHAR2);
パラメータ
表161-19 INITIALIZE_CONSOLIDATED_REPLAYプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
ワークロード・リプレイの名前(必須)。処理済のワークロード取得のすべてのリプレイに名前を付けることができます。 |
|
リプレイするスケジュールの名前。これは、リプレイ・ディレクトリ |
使用上の注意
前提条件は次のとおりです。
同じデータベース・バージョンで、PROCESS_CAPTUREプロシージャを使用して、ワークロード取得がすでに処理されています。
データベースの状態は、元のワークロード取得の開始時点の状態に論理的にリストアされています。
SET_REPLAY_DIRECTORYプロシージャがコールされています。
このプロシージャはデータベースの状態をREPLAY
モードのINIT
に設定し、(PAUSE_REPLAYプロシージャを実行して)リプレイの準備をする前に、必要なリプレイ・システムにデータをロードします。
使用上の注意
前提条件は次のとおりです。
同じデータベース・バージョンで、PROCESS_CAPTUREプロシージャを使用して、ワークロード取得がすでに処理されています。
データベースの状態は、元のワークロード取得の開始時点の状態に論理的にリストアされています。
サブプログラムは、PAUSE_REPLAYプロシージャをコールしてリプレイの準備をする前に、必要なリプレイ・システムにデータをロードします。
たとえば、取得中に、ユーザーは各セッションでサーバーへの接続に使用された接続文字列を記録することがあります。INITIALIZE_REPLAYプロシージャはこのデータをロードして、記録された接続文字列を、ユーザーが新しい接続文字列やサービス・ポイントに再マップできるようにします。
ユーザーは、PROCESS_CAPTUREプロシージャに示した例を詳細に指定して、次のようなコマンドを起動できます。
DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY('replay foo #1', 'rec_dir');
このコマンドは接続マップをロードし、デフォルトで、リプレイ時接続文字列をすべてNULL
と同じに設定します。NULL
のリプレイ時接続文字列は、ワークロード・リプレイ・クライアント(WRC)が、リプレイ・クライアントのランタイム環境設定によって決定されるデフォルトのホストに接続することを意味します。ユーザーは、REMAP_CONNECTIONプロシージャを使用して、特定の接続文字列をリプレイ用の新しい接続文字列(または新しいサービス・ポイント)に変更できます。
このプロシージャは、進行中のワークロードのリプレイを一時停止します。リプレイ・クライアントからの後続のすべてのコールは、RESUME_REPLAYプロシージャへのコールが発行されるか、またはリプレイが取り消されるまで停止状態になります。
使用上の注意
前提条件: START_REPLAYプロシージャに対するコールがすでに発行されています。
このプロシージャを起動したときにすでに進行中であるユーザー・コールは、完了するまで実行できます。後続のユーザー・コールのみが、発行された場合に一時停止されます。
このプロシージャは特定のコール、ストリームまたはリプレイ全体の相違情報を事前計算して、GET_DIVERGING_STATEMENTファンクションが事前計算されたコールに可能な限り迅速に戻ることができるようにします。
このプロシージャは、データベースの状態をPREPARE FOR REPLAY
モードに設定します。
構文
DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY ( synchronization IN BOOLEAN DEFAULT TRUE, connect_time_scale IN NUMBER DEFAULT 100, think_time_scale IN NUMBER DEFAULT 100, think_time_auto_correct IN BOOLEAN DEFAULT TRUE, scale_up_multiplier IN NUMBER DEFAULT 1, capture_sts IN BOOLEAN DEFAULT FALSE, sts_cap_interval IN NUMBER DEFAULT 300); DBMS_WORKLOAD_REPLAY.PREPARE_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, scale_up_multiplier IN NUMBER DEFAULT 1, capture_sts IN BOOLEAN DEFAULT FALSE, sts_cap_interval IN NUMBER DEFAULT 300);
パラメータ
表161-22 PREPARE_REPLAYプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
ワークロードのリプレイ中に、同期化を
下位互換性を保つために、このプロシージャにはブール・バージョンがあります。
|
|
ワークロード取得が開始されてから、指定した値でセッションが接続されるまでの経過時間を変更します。入力は、%値として解釈されます。ワークロードのリプレイ中に同時ユーザー数を増加または削減する場合に使用できます。 |
|
同じセッションからの2つの連続したユーザー・コール間の経過時間を変更します。入力は、%値として解釈されます。ワークロードのリプレイ中に同時ユーザー数を増加または削減する場合に使用できます。 |
|
元の取得時よりもリプレイ時にユーザー・コールの完了に時間がかかる場合、コール間の思考時間を適切に自動修正します。 |
|
リプレイ中に問合せワークロードを拡大する回数を定義します。取得された各セッションは、 |
|
このパラメータが |
|
カーソル・キャッシュからのSQLセット取得の取得間隔を秒単位で指定します。デフォルト値は300です。 |
使用上の注意
前提条件は次のとおりです。
データベースは、リプレイに備えてINITIALIZE_REPLAYプロシージャを使用して初期化されています。
再マッピングが必要なすべての取得時接続文字列が、REMAP_CONNECTIONプロシージャを使用して、すでに再マッピングされています。
PREPARE_REPLAY
プロシージャを実行すると、1つ以上の外部リプレイ・クライアント(WRC)を開始できます。
scale_up_multiplierの関連事項:
各同一セッション・セットの1つのリプレイ・セッション(ベース・セッション)が、通常どおり取得からすべてのコールをリプレイします。
その他のセッション(拡大セッション)は、読取り専用のコールのみをリプレイします。したがって、データベースを変更したDDL、DMLおよびPL/SQLコールは省略されます。SELECT
FOR
UPDATE
文も省略されます。
拡大セッションの読取り専用コールは適切に同期化され、think_time_scale
、connect_time_scale
およびthink_time_auto_correct
によって定義されたタイミングに従います。また、問合せは適切なコミットを待機します。
拡大セッションに対しては、リプレイ・データもエラー相違記録も生成されません。
同じ取得ファイルをリプレイするベース・セッションや拡大セッションはすべて、同じワークロード・リプレイ・クライアントから接続します。
例
connect_time_scaleパラメータの適用
元のワークロード取得中に次のことが確認されたとします。
12:00 : Capture was started 12:10 : First session connect (10m after) 12:30 : Second session connect (30m after) 12:42 : Third session connect (42m after)
connect_time_scaleが50の場合、セッション接続は次のようになります。
12:00 : Replay was started with 50% connect time scale 12:05 : First session connect ( 5m after) 12:15 : Second session connect (15m after) 12:21 : Third session connect (21m after)
connect_time_scaleが200の場合、セッション接続は次のようになります。
12:00 : Replay was started with 200% connect time scale 12:20 : First session connect (20m after) 13:00 : Second session connect (60m after) 13:24 : Third session connect (84m after)
think_time_scaleパラメータの適用
元のワークロード取得中に次のことが確認されたとします。
12:00 : User SCOTT connects 12:10 : First user call issued (10m after completion of prevcall) 12:14 : First user call completes in 4mins 12:30 : Second user call issued (16m after completion of prevcall) 12:40 : Second user call completes in 10m 12:42 : Third user call issued ( 2m after completion of prevcall) 12:50 : Third user call completes in 8m
ワークロードのリプレイ時にthink_time_scaleが50の場合、ユーザー・コールは次のようになります。
12:00 : User SCOTT connects 12:05 : First user call issued 5 mins (50% of 10m) after the completion of previous call 12:10 : First user call completes in 5m (takes a minute longer) 12:18 : Second user call issued 8 mins (50% of 16m) after the completion of prev call 12:25 : Second user call completes in 7m (takes 3 minutes less) 12:26 : Third user call issued 1 min (50% of 2m) after the completion of prev call 12:35 : Third user call completes in 9m (takes a minute longer)
think_time_auto_correctパラメータの適用
元のワークロード取得中に次のことが確認されたとします。
12:00 : User SCOTT connects 12:10 : First user call issued (10m after completion of prevcall) 12:14 : First user call completes in 4m 12:30 : Second user call issued (16m after completion of prevcall) 12:40 : Second user call completes in 10m 12:42 : Third user call issued ( 2m after completion of prevcall) 12:50 : Third user call completes in 8m
ワークロードのリプレイ時にthink_time_scaleが100で、think_time_auto_correctがTRUEの場合、ユーザー・コールは次のようになります。
12:00 : User SCOTT connects 12:10 : First user call issued 10 mins after the completion of prev call 12:15 : First user call completes in 5m (takes 1 minute longer) 12:30 : Second user call issued 15 mins (16m minus the extra time of 1m the prev call took) after the completion of prev call 12:44 : Second user call completes in 14m (takes 4 minutes longer) 12:44 : Third user call issued immediately (2m minus the extra time of 4m the prev call took) after the completion of prev call 12:52 : Third user call completes in 8m
PREPARE_REPLAYプロシージャと同様に、このプロシージャは、複数の取得リプレイに対してデータベースを特別な「準備」モードにします。このサブプログラムは統合されたリプレイのみに使用される点が異なります。
構文
DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY ( synchronization IN BOOLEAN, 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); 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);
パラメータ
表161-23 PREPARE_CONSOLIDATED_REPLAYプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
ワークロードのリプレイ中に、同期化を 同期が
|
|
ワークロード取得が開始されてから、指定した値でセッションが接続されるまでの経過時間を変更します。入力は、%値として解釈されます。ワークロードのリプレイ中に同時ユーザー数を増加または削減する場合に使用できます。 |
|
同じセッションからの2つの連続したユーザー・コール間の経過時間を変更します。入力は、%値として解釈されます。ワークロードのリプレイ中に同時ユーザー数を増加または削減する場合に使用できます。 |
|
リプレイでのユーザー・コールの完了にかかる時間が、元の取得でかかった時間よりも長くなる場合に、コール間の思考時間を適切に自動修正します。 |
|
このパラメータが |
|
カーソル・キャッシュからのSQLセット取得の取得間隔を秒単位で指定します。デフォルト値は300です。 |
このプロシージャは、capture_dir
内で検出されたワークロード取得を処理します。
構文
DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ( capture_dir IN VARCHAR2, parallel_level IN NUMBER DEFAULT NULL);
使用上の注意
このサブプログラムは、capture_dir
にあるワークロードの取得を分析し、指定したワークロード取得のリプレイに必要となる新しいワークロード・リプレイ固有のメタデータ・ファイルを作成します。これは新しいファイルを作成するだけであり、ワークロード取得中に最初に作成されたファイルは変更しません。したがって、このプロシージャは、プロシージャに予期しないエラーが発生したり、ユーザーによって取り消された場合などに、同じ取得ディレクトリで複数回実行できます。
このプロシージャが正常に実行されると、capture_dir
に存在する取得済ワークロードをリプレイするために、capture_dirをINITIALIZE_REPLAYプロシージャへの入力として使用できます。
特定のデータベース・バージョンでワークロード取得をリプレイする前に、PROCESS_CAPTURE
を使用して、同じデータベース・バージョンで取得を処理しておく必要があります。処理済のワークロード取得を作成すると、取得されたワークロードを同じデータベース・バージョンでリプレイする場合に複数回使用できます。
たとえば、ワークロードfooがOracle Databaseバージョン10.2.0.5のrec_dir
で取得されたとします。ワークロードfooをバージョン11.1.0.1でリプレイするには、このワークロードをバージョン11.1.0.1で処理する必要があります。取得ディレクトリrec_dir
を処理するには、次のプロシージャを11.1.0.1のデータベースで実行する必要があります。
DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE('rec_dir');
これで、rec_dir
に有効な11.1.0.1の処理済ワークロード取得が含まれます。この処理済ワークロード取得を使用して、ワークロードfooを11.1.0.1のデータベースで必要な回数だけリプレイできます。
このプロシージャは、ワークロードのリプレイ中にユーザー・セッションが希望の方法でデータベースに接続できるように、取得された接続を新しい接続に再マップします。
構文
DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION ( connection_id IN NUMBER, replay_connection IN VARCHAR2); DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION ( capture_number IN VARCHAR2, connection_id IN NUMBER, replay_connection IN VARCHAR2);
使用上の注意
REMAP_CONNECTION
をコールする前に、すべてのリプレイ接続文字列がデフォルトでNULL
に設定されます。replay_connection
がNULL
の場合、リプレイ・セッションは、リプレイ・クライアントのランタイム環境によって決定される接続先に接続されます。たとえば、環境変数TNS_ADMIN
が定義され、ユーザーがREMAP_CONNECTIONプロシージャをコールしない場合、wrc
実行可能ファイルは、TNS_ADMIN
が指すtnsnames.oraファイルで指定されたサーバーに接続します。
有効なreplay_connection
は、接続識別子またはサービス・ポイントを指定する必要があります。接続識別子(ネット・サービス名、データベース・サービス名、ネット・サービスの別名など)を指定する方法、および接続識別子を接続記述子に解決する場合に使用できる命名方法については、『Oracle Database Net Servicesリファレンス』を参照してください。
指定したconnection_id
に一致する行がない場合、エラーが戻されます。
後続のワークロード・リプレイで使用されるすべての接続文字列を確認したり、以前のワークロード・リプレイに使用された接続文字列の再マッピングを調べるには、DBA_WORKLOAD_CONNECTION_MAP
ビューを使用します。
このプロシージャは、現在のリプレイ・スケジュールから既存のスケジュール順序を削除します。schedule_capture_id
とwaitfor_capture_id
を同時に指定することで、以前はADD_SCHEDULE_ORDERINGファンクション(schedule_capture_id
、waitfor_capture_id
)により追加されたスケジュール順序が構成されます。この順序では、waiting_for_capture_id
により指定された取得のリプレイが終了しないかぎり、schedule_capture_id
により指定された取得のリプレイは開始しません。
構文
DBMS_WORKLOAD_REPLAY.REMOVE_SCHEDULE_ORDERING ( schedule_capture_id IN NUMBER, waitfor_capture_id IN NUMBER);
使用上の注意
前提条件は次のとおりです。
BEGIN_REPLAY_SCHEDULEプロシージャがコールされている必要があります。
リプレイ・スケジュールの順序は、ADD_SCHEDULE_ORDERINGファンクションを使用して追加済である必要があります。
このプロシージャは、指定されたフィルタ・セットの各フィルタを、ADD_SCHEDULE_ORDERINGプロシージャを使用して追加する場合と同じように再利用します。1回のコールで1つのフィルタ・セットが追加されますが、このフィルタ・セットは、様々な属性に対する個別フィルタのコレクションです。また、新規フィルタ・ルールを追加することや、CREATE_FILTER_SETプロシージャを起動して新規フィルタ・セットを作成する前に既存のフィルタを削除することもできます。
このプロシージャは、PREPARE_REPLAYプロシージャで使用されるパラメータ以外に、リプレイに対して詳細なパラメータを設定します。この詳細パラメータによって、リプレイのより特殊な側面を制御できます。詳細パラメータは、リプレイの完了後にデフォルト値にリセットされます。
構文
DBMS_WORKLOAD_REPLAY.SET_ADVANCED_PARAMETER( pname IN VARCHAR2, pvalue IN VARCHAR2); DBMS_WORKLOAD_REPLAY.SET_ADVANCED_PARAMETER( pname IN VARCHAR2, pvalue IN NUMBER); DBMS_WORKLOAD_REPLAY.SET_ADVANCED_PARAMETER( pname IN VARCHAR2, pvalue IN BOOLEAN);
使用上の注意
使用可能な現行のパラメータおよび値:
'DO_NO_WAIT_COMMITS': (default: FALSE)
このパラメータは、リプレイ・セッションにより発行されるCOMMIT
がNOWAIT
かどうかを制御します。このパラメータのデフォルト値はFALSE
です。その場合、COMMIT
は取得されたモードで発行されます(wait
、no-wait
、batch
、no-batch
)。このパラメータをTRUE
に設定すると、COMMIT
はno-wait
モードで発行されます。これは、同時COMMIT
の量が多いためリプレイが非常に遅くなっている場合に役立ちます。パラメータをTRUE
に設定すると、取得に関するリプレイ中に'log file sync'
イベントでの待機を大幅に短縮できます。
このプロシージャは、リプレイのタイムアウト設定を指定します。リプレイを極度に遅くしたり、リプレイをハングさせる可能性のあるユーザー・コールを中断する目的で使用します。
構文
DBMS_WORKLOAD_REPLAY.SET_REPLAY_TIMEOUT ( enabled OUT BOOLEAN DEFAULT TRUE, min_delay OUT NUMBER DEFAULT 10, max_delay OUT NUMBER DEFAULT 120, delay_factor OUT NUMBER DEFAULT 8);
パラメータ
表161-32 SET_REPLAY_TIMEOUTプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
タイムアウト・アクションを有効にする場合は |
|
コール遅延の下限(分単位)。リプレイ・アクションは、遅延が |
|
コール遅延の上限(分単位)。遅延が |
|
|
使用上の注意
このプロシージャは、リプレイ中にいつでもコールできます。
コール遅延は、リプレイの経過時間がコールの経過時間より長い場合に、リプレイと取得の間の差異として定義されます。
リプレイのタイムアウト・アクションが有効になると、ユーザー・コールは、リプレイ・アクションによって指定された条件を超えて遅延した場合、ORA-15569
が発生して終了します。コールとそのエラーは、エラーの相違として報告されます。
リプレイのタイムアウトは、次のように動作します。
タイムアウト・アクションは、有効にしないと効果はありません。
コール遅延(分単位)がmin_delay
パラメータで指定された下限未満の場合、タイムアウト・アクションは動作しません。
遅延(分単位)がmax_delay
パラメータで指定された上限を超えると、タイムアウト・アクションによってユーザー・コールが中断され、ORA-15569
がスローされます。
遅延が下限と上限の間にある状態では、現行のリプレイの経過時間が取得の経過時間とdelay_factor
パラメータの積を超える場合にのみ、ORA-15569
が発生してユーザー・コールは中断されます。
このプロシージャは、取得されたユーザーのかわりに、リプレイ中に使用する新規スキーマまたはユーザー名を設定します。
構文
DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING ( schedule_cap_id IN NUMBER, capture_user IN VARCHAR2, replay_user IN VARCHAR2); DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING ( capture_user IN VARCHAR2, replay_user IN VARCHAR2);
使用上の注意
NULL
のschedule_cap_id
は、通常の非統合リプレイに使用されます。
リプレイは初期化が必要ですが、このサブプログラムを使用するために準備する必要はありません。
replay_user
がNULL
に設定されている場合、マッピングは無効になります。
同じcapture_user
を使用して複数回コールした後、常に最後のコールが有効になります。
後続のリプレイ中に有効になるマッピングをすべてリストするには、次のように実行します。
SELECT * FROM DBA_WORKLOAD_ACTIVE_USER_MAP
schedule_cap_id
を指定しないオーバーロードのバージョンでは、NULL
を渡すことによってschedule_cap_id
引数のあるものがコールされます。
マッピングは、ビューDBA_WORKLOAD_USER_MAP
を介して公開された表に格納されます。古いマッピングを削除するには、次のように実行します。
DELETE * FROM DBA_WORKLOAD_USER_MAP
このプロシージャは、複数の取得のリプレイを開始します。これは、統合されたリプレイのみに使用してください。
使用上の注意
前提条件は次のとおりです。
PREPARE_REPLAYプロシージャに対するコールがすでに発行されています。
取得されたワークロードを正確にリプレイできる十分な数の外部リプレイ・クライアント(WRC)が、すでに起動されています。このような外部リプレイ・クライアントのステータスは、V$WORKLOAD_REPLAY_CLIENTS
を使用して監視できます。
このプロシージャは、ワークロードのリプレイを開始します。現在リプレイ・データベースに接続されているすべての外部リプレイ・クライアント(WRC)が自動的に通知され、それらのリプレイ・クライアント(WRC)は取得されたワークロードの発行を開始します。これは、統合されたリプレイのみに使用してください。
使用上の注意
前提条件は次のとおりです。
PREPARE_REPLAYプロシージャに対するコールがすでに発行されています。
取得されたワークロードを正確にリプレイできる十分な数の外部リプレイ・クライアント(WRC)が、すでに起動されています。このような外部リプレイ・クライアントのステータスは、V$WORKLOAD_REPLAY_CLIENTS
を使用して監視できます。
取得されたワークロードを正確にリプレイするために必要なリプレイ・クライアントの数を決定するには、WRCのCALIBRATE
モードを使用します。次に例を示します。
$ wrc mode=calibrate replaydir=.
このプロシージャは、フィルタ・セットを現在のリプレイ・スケジュールの取得に適用します。このフィルタは、CREATE_FILTER_SETプロシージャをコールして作成されている必要があります。
構文
DBMS_WORKLOAD_REPLAY.USE_FILTER_SET( capture_number IN VARCHAR2, filter_set IN VARCHAR2); DBMS_WORKLOAD_REPLAY.USE_FILTER_SET( filter_set IN VARCHAR2);