12 データベース・ワークロードのリプレイ

取得されたワークロードの事前処理後に、Oracle Databaseの同じバージョンを稼働しているリプレイ・システムで繰り返しリプレイすることができます。通常は、事前処理されたワークロードがリプレイされるリプレイ・システムは、本番システムとは別のテスト・システムである必要があります。

この章では、テスト・システムでデータベース・ワークロードをリプレイする方法について説明します。内容は次のとおりです。

• データベース・ワークロードのリプレイのステップ

• Enterprise Managerを使用したデータベース・ワークロードのリプレイ

• Enterprise Managerを使用したリプレイ・スケジュールおよびパラメータの設定

• Enterprise Managerを使用したワークロードのリプレイの監視

• Enterprise Manager外部のリプレイのインポート

• APIを使用したデータベース・ワークロードのリプレイ

• APIを使用したワークロードのリプレイの監視

ヒント:

データベース・ワークロードをリプレイする前に、次の操作を行う必要があります。

• 本番システムでのワークロードの取得(「データベース・ワークロードの取得」)

• 取得されたワークロードの事前処理(「データベース・ワークロードの事前処理」)

データベース・ワークロードのリプレイのステップ

リプレイ・システムを適切に準備し、ワークロードのリプレイを適切に計画すると、リプレイの正確性が保証されます。データベースのワークロードをリプレイする前に、次のステップを完了して、リプレイ・システムとワークロードのリプレイを準備します。

• リプレイ・ディレクトリの設定

• データベースのリストア

• 外部システムへの参照の解決

• 接続の再マッピング

• ユーザーの再マッピング

• リプレイ・オプションの指定

• ワークロード・リプレイ時のフィルタの使用

• リプレイ・クライアントの設定

リプレイ・ディレクトリの設定

取得したワークロードは、事前処理してリプレイ・システムにコピーしておく必要があります。事前処理したワークロードのコピー先ディレクトリのディレクトリ・オブジェクトが、リプレイ・システムに存在している必要があります。

データベースのリストア

ワークロードをリプレイする前に、リプレイ・システムのアプリケーション・データの状態を、ワークロードの取得の開始時における取得システムのデータの状態と論理的に同じにする必要があります。これによって、リプレイ時のリプレイの相違が最小限に抑えられます。データベースのリストア方法は、ワークロードの取得前に使用したバックアップ方法に応じて異なります。たとえば、取得システムのバックアップにRMANを使用した場合は、テスト・データベースの作成にRMANのDUPLICATE機能を使用できます。詳細は、「データベース・ワークロードの取得の前提条件」を参照してください。

リプレイ・システムで適切なアプリケーション・データを使用してデータベースを作成したら、テストするシステム変更(データベースやオペレーティング・システムのアップグレードなど)を行います。データベース・リプレイの主な目的は、取得したワークロードでシステム変更の影響をテストすることです。したがって、実行したシステム変更によって、取得したワークロードで実施するテストが定義されることになります。

外部システムへの参照の解決

取得したワークロードに、データベース・リンクや外部表などの外部システムへの参照が含まれている場合があります。通常、このような外部との対話は、リプレイ時に他の本番システムに影響が及ばないように再構成する必要があります。ワークロードのリプレイ前に解決する必要がある外部参照は、次のとおりです。

• データベース・リンク

  通常、リプレイ・システムが他のデータベースと相互作用するのは好ましくありません。したがって、リプレイに必要なデータが含まれている適切なデータベースを指すように、すべてのデータベース・リンクを再構成する必要があります。

• 外部表

  外部表によって参照されるディレクトリ・オブジェクトを試用して指定されたすべての外部ファイルは、リプレイ時にデータベースに対して使用可能である必要があります。これらのファイルのコンテンツは、取得時と同一である必要があり、外部表の定義に使用されるファイル名およびディレクトリ・オブジェクトも有効である必要があります。

• ディレクトリ・オブジェクト

  本番システムのディレクトリへの参照は、データベースのリストア後にリプレイ・システムに存在するディレクトリ・オブジェクトを適切に再定義することによって再構成する必要があります。

• URL

  ワークロードの取得時にアクセスしたWebサービスがリプレイ時に適切なURLを指すように、データベースに格納されているURL/URIを構成する必要があります。ワークロードが本番システムに格納されているURLを参照する場合、リプレイ時にそのテスト・システム・ネットワークを切り離す必要があります。

• 電子メール

  リプレイ時に電子メール通知が再送信されないようにするには、送信電子メールのリクエストを無視するように、リプレイ・システムにアクセス可能な電子メール・サーバーを構成する必要があります。

ヒント:

リプレイ時に他の本番システムに影響が及ばないようにするために、リプレイは、本番環境のホストにアクセスできない切り離されたプライベート・ネットワーク内で実行することをお薦めします。

接続の再マッピング

ワークロードの取得時に、本番システムへの接続に使用される接続文字列が取得されます。リプレイが正常に完了するには、この接続文字列をリプレイ・システムに再マッピングする必要があります。これによって、リプレイ・クライアントは再マッピングされた接続を使用してリプレイ・システムに接続できます。

Oracle Real Application Clusters(Oracle RAC)データベースの場合、すべての接続文字列をロード・バランシング接続文字列にマップできます。これは、リプレイ・システムのノード数が取得システムとは異なる場合に特に便利です。また、ワークロードを特定のインスタンスに適用する場合は、サービスを使用するか、または再マッピングした接続文字列でインスタンス識別子を明示的に指定することができます。

ユーザーの再マッピング

ワークロードの取得時、本番システムに接続するために使用されるデータベース・ユーザーまたはスキーマのユーザー名が取得されます。取得したユーザー名は、新しいユーザーまたはスキーマに再マッピングするよう選択できます。

リプレイ・オプションの指定

データベースをリストアして接続とユーザーを再マッピングしたら、適切なリプレイ・オプションを設定できます。たとえば:

• 同期方法の指定

• セッションの接続速度の制御

• セッション内のリクエスト速度の制御

同期方法の指定

synchronizationパラメータでは、データベース・リレーに使用する同期方法を指定します。

このパラメータをTIMEに設定すると、リプレイでは取得と同じ実時間が使用されます。すべてのデータベース・セッション・ログイン時間は、取得どおり正確にリプレイされます。同様に、データベース・セッション内のトランザクション間のすべてのタイミングは、取得どおり維持およびリプレイされます。この同期方法により、ほとんどのワークロードで適切なリプレイが実行されます。

このパラメータをSCNに設定すると、取得したワークロード内のCOMMITの順序がリプレイ時に確認され、すべてのリプレイ・アクションがすべての依存COMMITアクションの完了後にのみ実行されます。この同期方法では、ほとんどのワークロードで大幅な遅延が生じる可能性があります。この場合は、synchronizationパラメータとしてTIMEを使用することをお薦めします。

このパラメータをOBJECT_IDに設定すると、関連するすべてのCOMMITアクションが完了するまで、すべてのリプレイ・アクションは実行されません。関連するCOMMITアクションは、次の条件を満たしている必要があります。

• ワークロードの取得内の指定したアクションの前に発行されている。

• 指定したアクションが暗黙的または明示的に参照しているデータベース・オブジェクトが1つ以上修正されている。

このパラメータをOBJECT_IDに設定すると、ワークロードの取得時に同じデータベース・オブジェクトを参照しないCOMMITアクションに関して、ワークロードのリプレイ時の同時実行性が向上します。

セッションの接続速度の制御

connect_time_scaleパラメータによって、ワークロードの取得を開始した時点から各セッションが接続した時点までの経過時間をスケール変更できます。このオプションでは、パーセント値を指定して、リプレイ時のセッションの接続時間を操作できます。デフォルト値は100で、すべてのセッションへの接続が取得時のとおりに試行されます。このパラメータを0(ゼロ)に設定すると、すべてのセッションへの接続が即時試行されます。

セッション内のリクエスト速度の制御

ユーザー思考時間とは、リプレイされたユーザーが単一セッションでコールの発行から次のコールの発行までに待機する経過時間です。リプレイの速度を制御するには、think_time_scaleパラメータを使用してリプレイ時のユーザー思考時間をスケール変更します。

リプレイ時のユーザー・コールの実行が取得時より遅い場合は、think_time_auto_correctパラメータをTRUEに設定して、データベース・リプレイで遅延の回復を試行できます。これによってリプレイ・クライアントでのコール間の思考時間を短縮できるため、リプレイ時の経過時間全体が取得時の経過時間により近くなります。

リプレイ時のユーザー・コールの実行が取得時よりも速い場合は、think_time_auto_correctパラメータをTRUEに設定しても思考時間は変更されません。取得された経過時間に一致させるために、リプレイ・クライアントがコール間の思考時間を長くすることはありません。

ワークロード・リプレイ時のフィルタの使用

デフォルトでは、取得したすべてのデータベース・コールが、ワークロードのリプレイ時にリプレイされます。ワークロード・フィルタを使用して、ワークロード・リプレイ時にワークロードに含めるデータベース・コール、または除外するデータベース・コールを指定できます。

ワークロード・リプレイ・フィルタは、定義後、ワークロード・リプレイで使用できるようにリプレイ・フィルタ・セットに追加されます。包含フィルタおよび除外フィルタという2種類のワークロード・フィルタがあります。包含フィルタでは、リプレイされるデータベース・コールを指定できます。除外フィルタでは、リプレイされないデータベース・コールを指定できます。ワークロード・リプレイでは包含フィルタまたは除外フィルタを使用できますが、両方を使用することはできません。ワークロード・フィルタは、リプレイ・フィルタ・セットの作成時に包含または除外フィルタと判断されます。

リプレイ・クライアントの設定

リプレイ・クライアントはマルチスレッド化されたプログラム($ORACLE_HOME/binディレクトリにあるwrcという名の実行可能ファイル)で、スレッドごとに取得済セッションからワークロードを発行します。リプレイが開始される前に、データベースはリプレイ・クライアントの接続を待機します。この時点で、リプレイ・クライアントを設定して起動する必要があり、このリプレイ・クライアントがリプレイ・システムに接続し、ワークロードに取得された内容に基づいてリクエストを送信します。

リプレイ・クライアントを開始する前に、次の項目を確認します。

• リプレイ・クライアント・ソフトウェアが実行場所のホストにインストールされていること

• リプレイ・クライアント・ソフトウェアのバージョンがRDBMSデータベース・ソフトウェアと同じであること

• リプレイ・クライアントがリプレイ・ディレクトリにアクセスできること

• リプレイ・ディレクトリに事前処理された取得済のワークロードが含まれていること

• リプレイ・ユーザーが正しいユーザーID、パスワードおよび権限を持っていること(リプレイ・ユーザーにはDBAロールが必要であり、SYSユーザーはリプレイ・ユーザーになることができない)

• リプレイ・クライアントは、データベースが実行されているシステムでは起動しません。

• リプレイ・クライアントは、データベース・ファイルが存在しているファイル・システムとは別のファイル・システム上の取得ディレクトリを読み取ります。

  このため、取得ディレクトリをリプレイ・クライアントが実行されるシステムにコピーします。リプレイの完了後、取得ディレクトリは削除できます。

これらの前提条件を満たしたら、wrc実行可能ファイルを使用してリプレイ・クライアントの設定および起動に進むことができます。wrc実行可能ファイルでは、次の構文を使用します。

wrc [user/password[@server]] MODE=[value] [keyword=[value]]

パラメータuser、password、およびserverは、リプレイ・データベースへの接続に使用するユーザー名、パスワード、および接続文字列を指定します。パラメータmodeは、wrc実行可能ファイルの実行モードを指定します。使用可能な値はreplay(デフォルト)、calibrate、およびlist_hostsです。パラメータkeywordは、実行に使用するオプションを指定し、これは選択したモードにより異なります。使用可能なキーワードおよび対応する値を表示するには、引数なしでwrc実行可能ファイルを実行します。

次の項では、wrc実行可能ファイルの実行時に選択できるモードについて説明します。

• リプレイ・クライアントの較正

• リプレイ・クライアントの起動

• ホスト情報の表示

リプレイ・クライアントの較正

1つのリプレイ・クライアントからデータベースとの複数のセッションを開始できるため、取得されたセッションごとにリプレイ・クライアントを起動する必要はありません。起動する必要があるリプレイ・クライアントの数は、ワークロード・ストリームの数、ホストの数およびホストごとのリプレイ・クライアントの数によって異なります。

リプレイ・クライアントおよび特定のワークロードをリプレイするために必要なホストの数を見積もるには、wrc実行可能ファイルをcalibrateモードで実行します。

較正モードでは、wrc実行可能ファイルで次のキーワードを使用できます。

• replaydir: リプレイする事前処理された取得済のワークロードを含むディレクトリを指定します。指定しない場合は、デフォルトで現在のディレクトリが使用されます。

• process_per_cpu: 各CPUで実行可能なクライアント・プロセスの最大数を指定します。デフォルト値は4です。

• threads_per_process: 1つのクライアント・プロセスで実行可能なスレッドの最大数を指定します。デフォルト値は50です。

次の例は、較正モードでwrc実行可能ファイルを実行する方法を示しています。

%> wrc mode=calibrate replaydir=./replay

この例では、現在のディレクトリ内のreplayサブディレクトリに格納されている取得済のワークロードのリプレイに必要なリプレイ・クライアントおよびホストの数を見積もるために、wrc実行可能ファイルを実行しています。次の出力例では、21個以上のリプレイ・クライアントを6個のCPUで分割して使用することが推奨されています。

Workload Replay Client: Release 12.1.0.0.1 - Production on Fri Sept 30
13:06:33 2011
 
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
 
Report for Workload in: /oracle/replay/
-----------------------
 
Recommendation:
Consider using at least 21 clients divided among 6 CPU(s).
 
Workload Characteristics:
- max concurrency: 1004 sessions
- total number of sessions: 1013
 
Assumptions:
- 1 client process per 50 concurrent sessions
- 4 client process per CPU
- think time scale = 100
- connect time scale = 100
- synchronization = TRUE

リプレイ・クライアントの起動

ワークロードをリプレイするために必要となるリプレイ・クライアントの数を決定したら、wrc実行ファイルがインストールされているホスト上でこれらの実行ファイルをreplayモードで実行し、リプレイ・クライアントを開始する必要があります。各リプレイ・クライアントは、起動されると、データベースとの1つ以上のセッションを開始してワークロードをリプレイします。

リプレイ・モードでは、wrc実行可能ファイルで次のキーワードを使用できます。

• useridおよびpassword: リプレイ・クライアントのリプレイ・ユーザーのユーザーIDおよびパスワードを指定します。指定しない場合は、デフォルトでsystemユーザーが使用されます。

• server: リプレイ・システムへの接続に使用する接続文字列を指定します。指定しない場合は、デフォルトで空の文字列が使用されます。

• replaydir: リプレイする事前処理された取得済のワークロードを含むディレクトリを指定します。指定しない場合は、デフォルトで現在のディレクトリが使用されます。

• workdir: クライアント・ログが書き込まれるディレクトリを指定します。このパラメータは、デバッグを目的としてdebugパラメータとともにのみ使用します。

• debug: デバッグ・データを作成するかどうかを指定します。次の値を指定できます。

  • on

    デバッグ・データが作業ディレクトリのファイルに書き込まれます

  • off

    デバッグ・データは書き込まれません(デフォルト値)

  ノート:

  wrc実行可能ファイルをデバッグ・モードで実行する前に、詳細をOracleサポート・サービスに問い合せてください。

• connection_override: DBA_WORKLOAD_CONNECTION_MAPビューに格納されている接続マッピングを無視するかどうかを指定します。TRUEに設定すると、DBA_WORKLOAD_CONNECTION_MAPビューに格納されている接続の再マッピングは無視され、serverパラメータで指定した接続文字列が使用されます。FALSEに設定すると、すべてのリプレイ・スレッドがDBA_WORKLOAD_CONNECTION_MAPビューに格納されている接続の再マッピングを使用して接続します。これがデフォルトの設定です。

• walletdirは、自動ログイン・ソフトウェア・キーストア・ディレクトリの場所をポイントします。デフォルト値は空の文字列です。walletdirは暗号化されたワークロード取得のリプレイにおいて必須です。暗号化されていない取得の場合はwalletdirは設定できず、デフォルトで空の文字列となります。

ノート:

• 暗号化されたワークロード取得の場合、oracle.rat.database_replay.encryption (大/小文字を区別)識別子を使用してパスワードを設定する必要があります。パスワードは自動ログイン・ソフトウェア・キーストアに格納されます。

• 暗号化されたワークロード取得のリプレイ時に、別個にクライアント側ソフトウェア・キーストアを設定する必要があります。たとえば:

  rm -rf keystore_location 
  mkdir keystore_location 
  orapki -wrl keystore_location -create 
  orapki -wrl keystore_location -createEntry 'oracle.rat.database_replay.encryption' secret_key 
  orapki -wrl keystore_location -createSSO 

  secret_keyは、ワークロード取得の暗号化時に作成されたサーバー側ソフトウェア・キーストアで使用されたsecret_keyと一致している必要があります。

mkstoreウォレット管理コマンドライン・ツールは、Oracle Database 23aiでは非推奨であり、将来のリリースで削除される可能性があります。

ウォレットの管理には、orapkiコマンドライン・ツールの使用をお薦めします。

すべてのリプレイ・クライアントが接続すると、データベースによって取得済のワークロードのストリームがすべての使用可能なリプレイ・クライアントに自動的に配分され、ワークロードのリプレイが開始可能になります。V$WORKLOAD_REPLAY_THREADビューで、リプレイ・クライアントのステータスを監視できます。リプレイが終了すると、すべてのリプレイ・クライアントの接続が自動的に切断されます。

例: 暗号化されていない取得に対するリプレイ・モードでのwrc実行可能ファイルの実行

次の例は、wrc実行可能ファイルをリプレイ・モードで実行する方法を示しています。

%> wrc system/password@test mode=replay replaydir=./replay

この例では、wrc実行可能ファイルによってリプレイ・クライアントが起動され、現在のディレクトリ内のreplayサブディレクトリに格納されている取得済のワークロードがリプレイされます。

例: 暗号化された取得に対するリプレイ・モードでのwrc実行可能ファイルの実行

次に、暗号化されたワークロード取得についてwrc実行可能ファイルをリプレイ・モードで実行する方法の例を示します。

%> wrc system/password@test mode=replay replaydir=./replay walletdir=/tmp/replay_encrypt_cwallet

この例では、wrc実行可能ファイルによってリプレイ・クライアントが起動され、現在のディレクトリ内のreplayサブディレクトリに格納されている取得済のワークロードがリプレイされます。walletdirは自動ログイン・ソフトウェアのキーストア・ディレクトリの場所をポイントします。

ホスト情報の表示

wrc実行可能ファイルをlist_hostsモードで実行すると、ワークロードの取得およびワークロードのリプレイに関連したホストを表示することができます。

list_hostsモードでは、wrc実行型ファイルはキーワードreplaydirを使用してリプレイ対象の前処理済ワークロードの取得を含むディレクトリを指定します。指定しない場合は、デフォルトで現在のディレクトリが使用されます。

次の例は、list_hostsモードでwrc実行可能ファイルを実行する方法を示しています。

%> wrc mode=list_hosts replaydir=./replay

この例では、現在のディレクトリ内のreplayサブディレクトリに格納されているワークロード取得またはリプレイに関連したすべてのホストを示すために、wrc実行可能ファイルを実行しています。次の出力例では、ワークロードの取得およびその後の3回のリプレイに関連したホストが示されています。

Workload Replay Client: Release 12.1.0.0.1 - Production on Fri Sept 30
13:44:48 2011
 
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
 
Hosts found:
Capture:
        prod1
        prod2
Replay 1:
        test1
Replay 2:
        test1
        test2
Replay 3:
        testwin

Enterprise Managerを使用したデータベース・ワークロードのリプレイ

この項では、Enterprise Managerを使用したデータベース・ワークロードのリプレイ方法について説明します。

続行する前に、リプレイ・タスクが作成済でリプレイ・タスクからリプレイが作成されている必要があります。これを行う方法の詳細は、"「Enterprise Managerを使用した単一のデータベース・ワークロードの準備」を参照してください。

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

Enterprise Managerを使用してデータベース・ワークロードをリプレイするには:

1. Enterprise Manager Cloud Controlコンソールの「エンタープライズ」メニューで、「クオリティ管理」、「データベース・リプレイ」の順に選択します。

   「データベース・ログイン」ページが表示されたら、管理者権限のあるユーザーとしてログインします。

   「データベース・リプレイ」ページが表示されます。

   
   dbr.gifの説明

2. 「リプレイ・タスク」タブを選択し、表の希望のリプレイ・タスクのリンクをクリックします。

   リプレイのリプレイ・タスク・ページが表示されます。

   
   dbr_replay_tasks.gifの説明

3. 「リプレイ」セクションの「作成」をクリックしてリプレイを作成します。

   「リプレイの作成」ポップアップが表示されます。

4. 必要な名前と説明(オプション)を入力し、「ターゲット・データベース」アイコンをクリックします。

   「検索と選択: ターゲット」ポップアップが表示されます。

5. 適切なデータベースを選択し、「選択」をクリックします。

6. 「リプレイの作成」ポップアップの「OK」をクリックします。

   リプレイを実行するリンク付きの「タスク・リスト」が含まれるリプレイのデータベース・リプレイ・ページが表示されます。

   
   dbr_replay_workload.gifの説明

7. 「ワークロード・リプレイ」タスクのリンクをクリックします。

   「ワークロード・リプレイ: ワークロードの検索」ページが表示されます。

   
   dbr_replay_loc_wkload.gifの説明

8. 必要なワークロードの場所オプションを選択します。

   リプレイ・クライアントがアクセス可能なリプレイ場所に格納されている場所からワークロードをまだコピーしていない場合、ワークロードをコピーするオプションを選択します。それ以外の場合は、リプレイするワークロードを含む既存のリプレイ・ディレクトリを使用するオプションを選択します。

   「次へ」をクリックして、ワークロード・リプレイ: ワークロードのコピー・ページを表示します。

   
   dbr_replay_copy_wkload.gifの説明

9. 必要な資格証明およびワークロードをコピーする新たなワークロード・ディレクトリの場所を指定して、「次へ」をクリックします。

   • 統合されたリプレイには複数のソース・ワークロードがあるため、複数のソース資格証明をワークロード・ディレクトリの現在の場所に入力しなければならないことがあります。統合リプレイの詳細は、「Enterprise Managerを使用したデータベース統合リプレイの使用」を参照してください。

   システムは処理中に進捗状況の棒グラフを表示して応答し、コピー操作が終了した後にワークロード・リプレイ: ディレクトリを選択ページが表示されます。

   
   dbr_replay_select_dir.gifの説明

10. ディレクトリ・オブジェクトを指定するかワークロードが含まれる場所をポイントする新しいディレクトリ・オブジェクトを作成します。前のステップでワークロードを新しい場所にコピーするよう選択をした場合、ディレクトリ・オブジェクトが「ワークロード・ディレクトリの新しい場所」で指定した正しい場所を確実にポイントするようにします。

    システムは取得サマリーを表示して応答します。「詳細の取得」セクションを展開して、ワークロード・プロファイルとワークロード・フィルタを表示できます。ワークロード取得アナライザ・レポートとデータベース取得レポートも生成できます。統合されたリプレイに取得サマリーは表示されません。

    「次へ」をクリックして、ワークロード・リプレイ: 初期化オプション・ページを表示します。

    
    dbr_replay_init_options.gifの説明

11. 「SQLパフォーマンス・アナライザ」セクションで、デフォルトでは有効になっており推奨されているSQL文の取得オプションを保持または無効化します。リプレイ終了時にSQLチューニング・セットを比較しない場合は、このオプションを無効化できます。

    • SQLパフォーマンス・アナライザでは、SQLチューニング・セット内のSQL文のパフォーマンスに関する環境の変更の影響の分析を開始できます。データベースのアップグレード、初期化パラメータの変更、Exadataシミュレーションまたはカスタム試験の結果をテストする、SQLパフォーマンス・アナライザ・タスクを作成および分析できます。このタスクでは、試行前の変更と試行後の変更の結果を比較します。

      データベースのリプレイでは、変更がシステム全体に及ぼす影響が分析されますが、SQLパフォーマンス・アナライザとともにSQLチューニング・セットを使用すれば、変更がSQL文と実行計画にどのように影響するか、SQLを中心とした分析を行うことができます。

      ワークロードのリプレイ中にSQLチューニング・セットを取得することで、SQLパフォーマンス・アナライザを使用して、そのSQLチューニング・セットとワークロードの取得時に取得された別のSQLチューニング・セットを比較できます(SQL文を再実行する必要はありません)。この方法では、データベース・リプレイの実行中に、SQLパフォーマンス・アナライザ・レポートを取得して、変更の前と後のSQLパフォーマンスを比較することができます。

    • 「ソースを指定」セクションでは、リプレイの初期オプションはオプションのカスタマイズ・ページの接続マッピングおよびパラメータを参照しています。接続はワークロードとともに取得されます。

      ノート:

      このセクションは、統合リプレイまたはOracle RACでは表示されません。

    「次へ」をクリックして、ワークロード・リプレイ: オプションのカスタマイズ・ページを表示します。

    
    dbr_replay_cust_options.gifの説明

12. 取得した接続文字列を、リプレイ・システムを指す接続文字列に再マッピングします。それぞれの取得の接続は再マッピングする必要があることに注意してください。たとえば、前述の図では、capture12_1およびcapture12_adcの両方の接続を再マッピングする必要があります。

    (統合リプレイでは、ワークロードごとに接続を再マッピングできます。ワークロードを選択するには、「取得名」ドロップダウンを利用します。)

    「接続マッピング」タブをクリックします。取得した接続文字列を再マッピングするには、複数の方法があります。次のいずれかを選択できます。

    • すべてのクライアント接続に単一の接続記述子を使用する: このオプションを選択して、使用する接続記述子を入力します。接続記述子が、リプレイ・システムを示す必要があります。

      接続をテストするには、「接続のテスト」をクリックします。接続記述子が有効な場合は、正常に接続されたことを示す情報メッセージが表示されます。

    • すべてのクライアント接続に単一のTNSネット・サービス名を使用する: このオプションを選択して、使用するネット・サービス名を入力します。すべてのリプレイ・クライアントは、ローカルのtnsnames.oraファイルを使用してネット・サービス名を解決する必要があります。

    • ワークロード内の取得されたクライアント接続記述子ごとに個別の接続記述子またはネット・サービス名を使用する: このオプションを選択して、取得システムの値ごとに、リプレイ・クライアントが使用するリプレイ・システムの値を入力します。「初期化オプション」ステップで「前回のリプレイのオプションを使用」オプションを選択した場合、別の接続記述子の使用に関するオプションが選択され、前回のリプレイ・システムの値が次のテキスト・フィールドに表示されます。

      ノート:

      このオプションは、統合リプレイにはありません。

13. リプレイの一部を制御するリプレイ・オプションを、リプレイ・パラメータを使用して指定します。

    リプレイの動作を変更するには、「リプレイ・パラメータ」タブをクリックし、リプレイ・パラメータごとに目的の値を入力します。デフォルト値を使用することをお薦めします。リプレイ・パラメータの設定の詳細は、次を参照してください。

    リプレイ・パラメータを設定したら、「次へ」をクリックします。

    「ワークロード・リプレイ: リプレイ・クライアントの準備」ページが表示されます。

    
    dbr_replay_prep_clients.gifの説明

14. リプレイ・クライアントでリプレイの準備ができていることを確認します。

    処理を行う前に、リプレイ・クライアントを設定する必要があります。

    1. 「見積り」をクリックして、リプレイに必要なリプレイ・クライアントとCPUの数を特定します。

    2. 「リプレイ・クライアント・ホストの追加」をクリックして、リプレイ・クライアントのホストを追加します。(リプレイ・クライアントのホストを追加しない場合は、Enterprise Managerを使用しないでコマンドラインからリプレイ・クライアントを開始して続行できます)。

       「検索と選択: リプレイ・クライアント・ホスト」ポップアップが表示されます。

       • ターゲット名を指定して「実行」をクリックするか、「実行」をクリックして使用可能なホストのリスト全体を表示します。

       • ホストを選択して、「選択」をクリックします。

    3. 「リプレイ・クライアント・ホスト」表の「ターゲット」列にホスト名が表示されたら、見積り結果で推奨されたリプレイ・クライアント数を指定し、ホストにリストされたCPU数が見積り結果の最小推奨数を満たすことを確認します。取得されたワークロードごとに、少なくとも1つのリプレイ・クライアントを起動する必要があります。

    4. 構成済の列で、「いいえ」リンクをクリックして、表示されたポップアップ内でリプレイ・クライアントを構成します。

    5. ポップアップに値を入力した後に、「適用」をクリックします。構成済の列の「リプレイ・クライアント・ホスト」表に「はい」と表示されます。

15. 「次へ」をクリックして、リプレイ・クライアントを起動して、ワークロード・リプレイ: クライアント接続の待機ページを表示します。

    
    dbr_replay_client.gifの説明

    ノート:

    プロセスのこのステップに「エンタープライズ」メニューからたどりついた場合は、リプレイ・ジョブおよびリプレイ結果記憶域ホスト用の資格証明も入力する必要があります。

    • リプレイ・クライアントを起動すると、リプレイ・クライアント接続が「クライアント接続」表に表示されます。

    • リプレイ・クライアントが接続されると、時計の下のテキストが変わります。

    • 1つ以上のリプレイ・クライアントが接続されると、「クライアント接続」表が移入されます。

    すべてのリプレイ・クライアントが接続されたら、ページ下部にホストの資格証明書を入力しリプレイ・ジョブを開始して、「次へ」をクリックして、ワークロード・リプレイ: 確認ページを表示します。

16. ワークロードのリプレイに関して定義したオプションおよびパラメータを確認します。

    • ワークロードのリプレイ・ジョブを正常に発行するには、「接続されているリプレイ・クライアント」の値を1以上にする必要があります。

    • 「発行」ボタンは、1つ以上のリプレイ・クライアントが接続されている場合のみ有効です。

17. 表示内容がすべて意図したとおりである場合は、「発行」をクリックしてリプレイ・ジョブを発行します。

    リプレイが開始された後、「ワークロード・リプレイは開始されました。」というシステム・メッセージが表示された状態で、このリプレイのデータベース・リプレイ・ページの「ホーム」タブが再表示されます。

関連項目:

• 「接続の再マッピング」

• 「リプレイ・オプションの指定」

• 「リプレイ・クライアントの設定」

• 「アクティブなワークロードのリプレイの監視」

Enterprise Managerを使用したリプレイ・スケジュールおよびパラメータの設定

リプレイ・スケジュール機能では、統合リプレイに含める取得済ワークロードのインスタンスをスケール・アップし、リプレイ内のインスタンスの相対再生スケジューリングを制御できます。各インスタンスのアクティブ・セッション・チャートの配置を更新することで、取得済ワークロード・インスタンスの相対スケジューリングが視覚的に表示されます。

この機能は、Cloud Control Databaseプラグイン12.1.0.5以降のリリースで利用できます。

この機能では、次のタスクを実行できます。

• 様々な時間間隔で実行できるようにインスタンスをオフセット

  各ワークロード・インスタンスの相対リプレイ開始時間を調整し、取得ワークロードのスケジュール済インスタンスにアクティブ・セッションの平均ピーク時間を配置できます。このワークロード・ピークの配置により、システムの負荷が最大化される可能性があり、その結果、様々なワークロード条件でテスト・システムがどのように反応するかを実験できます。

• 取得済ワークロードのインスタンスを追加してリプレイ・ワークロードをスケール・アップ

  追加した各インスタンスは、他のインスタンスとは独立してリプレイされます。

  ワークロードの複数のインスタンスを指定してワークロードをスケール・アップすると、デフォルトおよび推奨の構成では、インスタンスのいずれかでDML文がリプレイされます。追加のすべてのインスタンスは文の問合せ(読取り専用)をリプレイするのみです。

  たとえば、ワークロードに従業員データベースへのSQL挿入がある場合、通常は挿入を実行するインスタンスを1つのみにし、それ以外のインスタンスでは、この挿入でデータベースを変更するユーザー・コールを省略します。ただし、「問合せのみリプレイ」チェック・ボックスの選択を解除して、ワークロードのすべての文をリプレイすることで、インスタンスのデフォルト設定をオーバーライドできます。

リプレイ・スケジュールの計画ページにアクセスするには:

1. 「データベース・リプレイ」ホームページで、「リプレイ・タスク」タブをクリックします。

2. 複数のワークロードについて既存のリプレイ・タスクの名前をクリックして、「リプレイ・タスク」ページに移動します。

3. 「作成」をクリックして、新しいリプレイを作成します。

4. 「リプレイの作成」ポップアップで必要な情報を指定して、「OK」をクリックします。

   「リプレイ」表に新しいリプレイが表示されます。

5. 「リプレイ」表の新しいリプレイの名前をクリックします。

   「リプレイ」ページにタスク・リストが表示されます。

6. リプレイ・スケジュールの計画リンクをクリックします。

   リプレイ・スケジュールの計画ページが表示されます。

リプレイをスケール・アップするには:

1. ワークロード・インスタンスの追加ボタンの横のドロップダウンで、インスタンスを追加する取得ワークロードを選択します。

2. ワークロード・インスタンスの追加をクリックしてインスタンスを追加します。

時間間隔をスケジュールするには:

1. リプレイ遅延列で、最初の取得インスタンスをデフォルト値の0のままにするか、インスタンスの実行が開始されるまでの必要な時間(分)を調整します。

2. テスト用にパフォーマンス・スパイクをどのように実行するかを表す値をすべて設定するまで、取得インスタンスごとに前述のステップを繰り返します。

ワークロード・ピークを自動配置するには:

1. 自動配置ボタンをクリックします。

問合せのみのインスタンスを指定するには:

1. 問合せのみにするインスタンスごとに、「問合せのみリプレイ」チェック・ボックスを有効にします。

更新済スケジュールを確認するには:

1. 「データベース・リプレイ」ページの「リプレイ・タスク」タブで、スケジュール済リプレイを含む「リプレイ・タスク」リンクをクリックします。

   「リプレイ・タスク」ページが表示されます。

2. 「リプレイ」表でスケジュール済のタスクをクリックします。

3. 「リプレイ」ページの「確認」タブをクリックします。

Enterprise Managerを使用したワークロードのリプレイの監視

この項では、Enterprise Managerを使用したワークロード・リプレイの監視方法について説明します。ワークロードのリプレイを監視するための主要ツールは、Oracle Enterprise Managerです。Enterprise Managerを使用すると、次の操作を実行できます。

• アクティブなワークロードのリプレイの監視または停止

• 完了したワークロードのリプレイの表示

Oracle Enterprise Managerが使用できない場合は、「APIを使用したワークロードのリプレイの監視」で説明されているように、APIおよびビューを使用してワークロードのリプレイを監視できます。

この項では、次の項目について説明します。

• アクティブなワークロードのリプレイの監視

• 完了したワークロードのリプレイの表示

アクティブなワークロードのリプレイの監視

この項では、Enterprise Managerを使用してアクティブなワークロードのリプレイを監視する方法について説明します。

アクティブなワークロードのリプレイを監視するには:

1. データベース・リプレイ・ページで「リプレイ・タスク」タブをクリックします。
2. リプレイの進捗状況を監視するリプレイが含まれるリプレイ・タスクの名前をクリックします。
3. リプレイ・タスク・ページの「リプレイ」セクションから、リプレイの作成ウィザードで処理用に発行したリプレイの名前をクリックします。(このリプレイの「ステータス」列には「進行中」と表示されています。)

   データベース・リプレイ・ページの「ホーム」タブが表示され、「リプレイ・サマリー」に実行のステータスが表示されます。

   • リプレイの進行中には、「リプレイの進捗状況」チャートのリプレイ線が動的に更新されます。「リフレッシュ」ボタンをクリックすると、チャートを更新できます。

   • 「リプレイの進捗状況」チャートのユーザー・コール線は、同じ時期の取得と比較して、データベースがどの程度のワークロードを処理したかを示しています。

   • リプレイが完了するまで、「リプレイ相違サマリー」のデータは使用できません。

完了したワークロードのリプレイの表示

この項では、完了したワークロードのリプレイをEnterprise Managerを使用して表示する方法について説明します。

完了したワークロードのリプレイを表示するには:

1. データベース・リプレイ・ページで「リプレイ・タスク」タブをクリックします。
2. 表示する完了済リプレイが含まれるリプレイ・タスクの名前をクリックします。
3. リプレイ・タスク・ページの「リプレイ」セクションから、リプレイの作成ウィザードで処理用に発行したリプレイの名前をクリックします。(このリプレイの「ステータス」列には「完了」と表示されています。)

   データベース・リプレイ・ページの「ホーム」タブが表示され、「リプレイ・サマリー」に完了のステータスが表示されます。

   
   dbr_replay_completed.gifの説明

   • 「ユーザー・コール」チャートのリプレイ線は、開始から完了までのリプレイ全体を通して、リプレイの進捗状況をグラフィカルに示します。

     グラフに、ワークロードの取得中にユーザー・コールに関して経過した時間と比較して、同じワークロードのリプレイにかかった時間が表示されます。「リプレイ」の線が「取得」の線の上側または左側に表示される場合、リプレイ・システムは取得システムよりも高速にワークロードを処理しています。

   • 「リプレイ相違サマリー」には、リプレイ・システムと取得システム間のエラーおよびデータの矛盾点が、リプレイ時に違いが出たデータベース・コールとして表示されます。リプレイの質の測定値として違いが出た合計コール数の割合を使用できます。

     違いが出たコールの詳細を表示するには、「件数」列で違いが出たコールのタイプに対応するリンクをクリックし、リプレイ時に違いのあったコール・ページにアクセスします。「リプレイ時に違いのあったコール」ページには、取得されたワークロードと違いがあるリプレイ済コールの最も関連性が高いセットが、共通属性値および指定したフィルタ条件に基づいてグループ化されて表示されます。違いがある特定のコールに関する詳細(コールの属性、SQLテキスト、バインド変数など)を表示するには、「SQL ID」列の対応するリンクをクリックすると、違いの出た文をリプレイするページが表示されます。

4. データベース・リプレイ・ページに戻るには、「データベース・リプレイ」ブレッドクラムをクリックします。

   関連項目:

   ワークロード・リプレイ・レポートへのアクセスの詳細は、「取得およびリプレイ済ワークロードの分析」を参照してください

Enterprise Manager外部のリプレイのインポート

Enterprise Manager外部のワークロードのインポートと同様に、リプレイをEnterprise Managerにインポートして管理できます。リプレイをインポートするには、1つ以上のワークロードおよびリプレイを含めることができるリプレイ・タスクからインポートします。リプレイ・タスクは、データベース・リプレイの階層の最上部にあり、これらの他の従属コンポーネントのコンテナとして機能します。

インポート対象のリプレイは、テスト・データベースで実行したり、リプレイを完了して、ファイル・システムにリプレイ・ディレクトリを格納できます。

この機能は、Cloud Control Databaseプラグイン12.1.0.5以降のリリースで利用できます。

Enterprise Manager外部のリプレイをインポートするには:

1. 「データベース・リプレイ」ページの「リプレイ・タスク」タブをクリックし、目的のリプレイ・タスクを選択します。

   「リプレイ・タスク」ページが表示されます。

2. 「リプレイ」セクションの「インポート」をクリックします。

   「リプレイのインポート: ソース」ページが表示されます。

3. 次の3つの選択肢のいずれかを選択して、リプレイをインポートし、「次へ」をクリックします。

   • 完了した1つ以上のリプレイをファイル・システムのディレクトリからインポート

     このオプションは、通常APIを使用して作成されたリプレイに適用され、後続の処理用にEnterprise Managerにインポートします。この場合、Enterprise Managerは必ずしもリプレイ・データベースを管理していない可能性があります。

   • 完了した1つ以上のリプレイをデータベース・ターゲットからインポート

     この場合、Enterprise Managerはリプレイ・データベースをすでに管理している可能性があります。リプレイは、このデータベースで実行された可能性があるか、前述のオプションの場合と同様にロードされた可能性があります。

   • データベース・ターゲットで実行中のこのリプレイ・タスクのリプレイにアタッチ

     このオプションは前述のオプションと似ていますが、すでに完了しているリプレイではなく、実行中のリプレイである点が異なります。

   「リプレイのインポート: データベース」ページが表示されます。

4. 「データベース・ターゲット」フィールドの横の検索アイコンをクリックして、表示されるポップアップからデータベースを選択します。

   ノート:

   リプレイを読み取るデータベースのターゲット・バージョンは、リプレイ・タスクで使用されるバージョン以上である必要があります。たとえば、Oracle Database 12xで使用されるリプレイ・タスクの場合、リプレイの読取りで選択するデータベースはバージョン12x以上である必要があります。

   • データベースおよびホスト資格証明が要求されます。

   • 前述のステップで、完了した1つ以上のリプレイをファイル・システムのディレクトリからインポートを選択した場合は、ワークロードの場所も要求されます。

   • リプレイ・タスクでは、リプレイ・タスクに含まれるワークロードの数に基づいて、統合リプレイであるかどうかを判別できます。統合リプレイの場合は、ワークロードの場所に統合リプレイのディレクトリを入力するよう求められます。

5. 前述のステップで必要な入力を行い、「次へ」をクリックします。

   「リプレイのインポート: リプレイ」ページが表示されます。

   • ステップ3で、「1つ以上の完了したリプレイをファイル・システムのディレクトリからインポートします。」を選択した場合は、このページに「リプレイのロード」ボタンが表示されます。

   • ステップ3で、「1つ以上の完了したリプレイをデータベース・ターゲットからインポートします。」または「データベース・ターゲットで実行中のこのリプレイ・タスクのリプレイにアタッチします。」を選択した場合は、このページに「リプレイの検出」ボタンが表示されます。

6. ステップ3の選択に従って表示されるボタンに応じて、「リプレイのロード」または「リプレイの検出」のいずれかをクリックします。

   リプレイが1つ以上見つかった場合は、検出されたリプレイ表に表示されます。

7. 「次へ」をクリックして、リプレイをロードするか、リプレイを1つ以上選択し、「次へ」をクリックしてリプレイのインポートを継続します。

   「リプレイのインポート: 確認」ページが表示されます。

8. すべてが目的どおりに表示されたら、「送信」をクリックします。

   「データベース・リプレイ」ページには、ジョブが正常に送信されたことを示すメッセージが表示されます。表で、インポートしたリプレイの「ステータス」列に「進行中」と表示されます。

   ヒント:

   「確認」ステップで送信したリプレイ名をクリックして、ジョブの進行状況を確認できます。「リプレイ・サマリー」ページが表示され、データベース・リプレイ・インポート・ジョブ・リンクをクリックして、ジョブ実行ステップの進行状況を確認できます。

APIを使用したデータベース・ワークロードのリプレイ

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

DBMS_WORKLOAD_REPLAYパッケージを使用したデータベース・ワークロードのリプレイは、次に示す複数のステップで構成されているプロセスです。

• リプレイ・データの初期化

• 接続の再マッピング

• ユーザーの再マッピング

• ワークロードのリプレイ・オプションの設定

• ワークロード・リプレイ・フィルタおよびリプレイ・フィルタ・セットの定義

• リプレイのタイムアウト・アクションの設定

• ワークロードのリプレイの開始

• ワークロード・リプレイの一時停止

• ワークロード・リプレイの再開

• ワークロード・リプレイの取消し

• ワークロード・リプレイに関する情報の取得

• ワークロード・リプレイの相違データのロード

• ワークロード・リプレイに関する情報の削除

• ワークロードのリプレイのAWRデータのエクスポート

• ワークロードのリプレイのAWRデータのインポート

関連項目:

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

リプレイ・データの初期化

取得したワークロードを事前処理し、テスト・システムを適切に準備したら、リプレイ・データを初期化できます。リプレイ・データの初期化では、必要なメタデータが、ワークロードのリプレイで必要な表にロードされます。たとえば、取得した接続文字列が、リプレイ用に再マッピング可能な表にロードされます。

リプレイ・データを初期化するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY (replay_name => 'dec06_102',
                             replay_dir => 'dec06',
                             plsql_mode => 'top_level');
  END;
  /
  

  この例では、INITIALIZE_REPLAYプロシージャによって事前処理済のワークロード・データがdec06ディレクトリからデータベースにロードされます。

  この例のINITIALIZE_REPLAYプロシージャでは、次のパラメータを使用します。

  • replay_name: 以前のリプレイの設定およびフィルタを取得するために他のAPIで使用できるリプレイ名を指定する必須パラメータ。

  • replay_dir: リプレイする取得済のワークロードを含むディレクトリを指定する必須パラメータ。

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

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

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

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

ノート:

暗号化されたワークロード取得でINITIALIZE_REPLAYを実行するには、oracle.rat.database_replay.encryption識別子(大/小文字を区別)を使用してパスワードを設定する必要があります。パスワードはソフトウェア・キーストアに格納されます。ワークロード取得が暗号化されているかどうかは、DBA_WORKLOAD_CAPTURESビューから確認できます。

関連項目:

• ワークロードの取得の事前処理については、「APIを使用したデータベース・ワークロードの事前処理」を参照してください

• テスト・システムの準備の詳細は、「データベース・ワークロードのリプレイのステップ」を参照してください

接続の再マッピング

リプレイ・データを初期化したら、ユーザー・セッションが適切なデータベースに接続し、リプレイ時に取得される場合と同様に外部との対話を実行できるように、取得済のワークロードで使用されている接続文字列を再マッピングする必要があります。接続マッピングを表示するには、DBA_WORKLOAD_CONNECTION_MAPビューを使用します。

接続を再マッピングするには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (connection_id => 101,
                             replay_connection => 'dlsun244:3434/bjava21');
  END;
  /
  

  この例では、接続ID 101に対応する接続で、replay_connectionパラメータで定義された新しい接続文字列が使用されます。

  この例のREMAP_CONNECTIONプロシージャでは、次のパラメータを使用します。

  • connection_id: リプレイ・データの初期化時に生成され、取得したワークロードの接続に対応している必須パラメータ。

  • replay_connection: ワークロードのリプレイ時に使用される新しい接続文字列を指定する必須パラメータ。

関連項目:

「接続の再マッピング」

ユーザーの再マッピング

接続文字列の再マッピングに加え、ワークロード取得で取得したユーザーのかわりに、新しいスキーマやユーザーを使用することも可能です。取得済のユーザーを参照するには、DBA_WORKLOAD_USER_MAPビューを使用します。

ユーザーを再マッピングするには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING (capture_user => 'PROD',
                             replay_user => 'TEST');
  END;
  /
  

  この例では、取得時に使用されたPRODユーザーは、リプレイ時にTESTユーザーに再マッピングされます。

  この例のSET_USER_MAPPINGプロシージャでは、次のパラメータを使用します。

  • 必須のcapture_userパラメータには、ワークロードの取得時に取得したユーザー名を指定します。

  • 必須のreplay_userパラメータには、取得したユーザーがリプレイ時に再マッピングされるユーザー名を指定します。パラメータがNULLに設定されている場合、マッピングは無効です。

関連項目:

「ユーザーの再マッピング」

ワークロードのリプレイ・オプションの設定

リプレイ・データを初期化し、接続とユーザーを再マッピングしたら、ワークロードのリプレイ用にデータベースを準備する必要があります。

ワークロードのリプレイをリプレイ・システムで準備するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY (synchronization => 'OBJECT_ID',
                             capture_sts => TRUE,
                             sts_cap_interval => 300);
  END;
  /
  

  この例では、PREPARE_REPLAYプロシージャによって、事前に初期化されたリプレイが準備されます。ワークロードのリプレイと並行して、SQLチューニング・セットも取得されます。

  PREPARE_REPLAYプロシージャでは、次のパラメータを使用します。

  • synchronization必須パラメータでは、ワークロードのリプレイ時に使用される同期のタイプを指定します。

    このパラメータをTIMEに設定すると、リプレイでは取得と同じ実時間が使用されます。すべてのデータベース・セッション・ログイン時間は、取得どおり正確にリプレイされます。同様に、データベース・セッション内のトランザクション間のすべてのタイミングは、取得どおり維持およびリプレイされます。この同期方法により、ほとんどのワークロードで適切なリプレイが実行されます。

    このパラメータをSCN (デフォルト値)に設定すると、取得したワークロード内のCOMMITの順序がリプレイ時に確認され、すべてのリプレイ・アクションがすべての依存COMMITアクションの完了後にのみ実行されます。この同期方法では、ほとんどのワークロードで大幅な遅延が生じる可能性があります。この場合は、synchronizationパラメータとしてTIMEを使用することをお薦めします。

    このパラメータをOBJECT_IDに設定すると、関連するすべてのCOMMITアクションが完了するまで、すべてのリプレイ・アクションは実行されません。関連するCOMMITアクションは、次の条件を満たしている必要があります。

    • ワークロードの取得内の指定したアクションの前に発行されている。

    • 指定したアクションが暗黙的または明示的に参照しているデータベース・オブジェクトが1つ以上修正されている。

    このパラメータをOBJECT_IDに設定すると、ワークロードの取得時に同じデータベース・オブジェクトを参照しないCOMMITアクションに関して、ワークロードのリプレイ時の同時実行性が向上します。

  • connect_time_scale: 指定した値で、ワークロードの取得を開始した時点からセッションが接続する時点までの経過時間をスケール変更するパラメータで、%値として解釈されます。このパラメータは、リプレイ中に同時ユーザー数を増加または削減する場合に使用します。デフォルト値は100です。

  • think_time_scale: 同一セッションからの連続する2つのユーザー・コール間の経過時間をスケール変更するパラメータで、%値として解釈されます。このパラメータを0(ゼロ)に設定すると、リプレイ時にユーザー・コールは可能なかぎり高速でデータベースに送信されます。デフォルト値は100です。

  • think_time_auto_correct: リプレイ時にユーザー・コールの完了にかかる時間が取得時より長い場合に、コール間の思考時間を(think_time_scaleパラメータに基づいて)変更するパラメータ。このパラメータは、TRUEまたはFALSEに設定できます。このパラメータをTRUEに設定すると、ワークロードのリプレイがワークロードの取得より長くかかっている場合に、思考時間が短縮されます。デフォルト値はTRUEです。

  • scale_up_multiplier: リプレイ時にワークロードをn倍に増加させる値を定義するパラメータ。取得された各セッションが、このパラメータで指定された値を掛けた数だけ、同時にリプレイされます。ただし、同一リプレイ・セッションの各セット内で1つのセッションのみが問合せと更新の両方を実行します。残りのセッションは問合せのみを実行します。

  • capture_sts: ワークロードのリプレイと並行してSQLチューニング・セットを取得するかどうかを指定するパラメータ。このパラメータをTRUEに設定した場合、ワークロードのリプレイ中に1つのSQLチューニング・セットを取得することで、SQL文を再実行しなくても、SQLパフォーマンス・アナライザを使用してそのSQLチューニング・セットを別のSQLチューニング・セットと比較できます。この方法では、データベース・リプレイの実行中に、SQLパフォーマンス・アナライザ・レポートを取得して、変更の前と後のSQLパフォーマンスを比較することができます。また、「ワークロードのリプレイのAWRデータのエクスポート」で説明されているように、EXPORT_AWRプロシージャを使用して、結果のSQLチューニング・セットをそのAWRデータとともにエクスポートできます。

    この機能は、Oracle RACではサポートされていません。DBMS_WORKLOAD_REPLAYを使用して定義したワークロード・リプレイ・フィルタは、SQLチューニング・セットの取得には適用されません。このパラメータのデフォルト値はFALSEです。

  • sts_cap_interval: カーソル・キャッシュからのSQLチューニング・セット取得の継続時間(秒)を指定するパラメータ。デフォルト値は300です。このパラメータの値をデフォルト値未満に設定すると、一部のワークロードで追加オーバーヘッドが生じる可能性があるため、そのような設定は推奨されません。

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

関連項目:

「データベース・ワークロードのリプレイのステップ」

ワークロード・リプレイ・フィルタおよびリプレイ・フィルタ・セットの定義

この項では、ワークロード・リプレイ・フィルタの追加および削除方法と、リプレイ・フィルタ・セットの作成および使用方法について説明します。

この項では、次の項目について説明します。

• ワークロード・リプレイ・フィルタの追加

• ワークロード・リプレイ・フィルタの削除

• リプレイ・フィルタ・セットの作成

• リプレイ・フィルタ・セットの使用

関連項目:

「ワークロード・リプレイ時のフィルタの使用」

ワークロード・リプレイ・フィルタの追加

この項では、リプレイ・フィルタ・セットで使用する新しいフィルタを追加する方法を説明します。

新しいフィルタを追加するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.ADD_FILTER (
                             fname => 'user_ichan',
                             fattribute => 'USER',
                             fvalue => 'ICHAN');
  END;
  /
  

  この例では、ADD_FILTERプロシージャは、user_ichanというフィルタを追加します。このフィルタは、ユーザー名ICHANに属するすべてのセッションを除外するために使用できます。

  この例のADD_FILTERプロシージャでは、次のパラメータを使用します。

  • fname: 追加するフィルタの名前を指定する必須パラメータ。

  • fattribute: フィルタを適用する属性を指定する必須パラメータ。有効値は、PROGRAM、MODULE、ACTION、SERVICE、USER、およびCONNECTION_STRINGです。CONNECTION_STRING属性として、リプレイ時に使用される有効な取得した接続文字列を指定する必要があります。

  • fvalue: フィルタを適用する属性に対応する値を指定する必須パラメータ。一部の属性(モジュールやアクションなど)では、%などのワイルドカードを使用できます。

  すべてのワークロード・リプレイ・フィルタを追加した後に、ワークロードのリプレイ時に使用できるリプレイ・フィルタ・セットを作成できます。

ワークロード・リプレイ・フィルタの削除

この項では、ワークロード・リプレイ・フィルタを削除する方法を説明します。

ワークロード・リプレイ・フィルタを削除するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.DELETE_FILTER (fname => 'user_ichan');
  END;
  /
  

  この例では、DELETE_FILTERプロシージャはuser_ichanというフィルタを削除しています。

  DELETE_FILTERプロシージャでは、削除するフィルタの名前を指定する必須パラメータfnameを使用します。

リプレイ・フィルタ・セットの作成

ワークロード・リプレイ・フィルタを追加した後に、ワークロード・リプレイで使用するリプレイ・フィルタのセットを作成することができます。リプレイ・フィルタ・セットを作成する際、前回のリプレイ・フィルタ・セットの作成以降に追加されたすべてのワークロード・リプレイ・フィルタが使用されます。

リプレイ・フィルタ・セットを作成するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.CREATE_FILTER_SET (
                             replay_dir => 'apr09',
                             filter_set => 'replayfilters',
                             default_action => 'INCLUDE');
  END;
  /
  

  この例のCREATE_FILTER_SETプロシージャは、replayfiltersという名前のリプレイ・フィルタ・セットを作成します。このリプレイ・フィルタ・セットは、リプレイ・フィルタで定義されたワークロードの部分は除いて、apr09ディレクトリに保存されているリプレイに対して取得されたすべてのコールをリプレイします。

  この例のCREATE_FILTER_SETプロシージャでは、次のパラメータを使用します。

  • replay_dir:フィルタ対象のリプレイが格納されているディレクトリを指定するパラメータ。

  • filter_set: 作成するフィルタ・セットの名前を指定するパラメータ。

  • default_action: 取得された各データベース・コールを再生するかどうか、およびワークロード・リプレイ・フィルタが包含フィルタと除外フィルタのどちらとみなされるかを決定するパラメータ。

    このパラメータをINCLUDEに設定すると、リプレイ・フィルタで定義されたワークロードの部分を除いて、取得されたすべてのデータベース・コールがリプレイされます。この場合、すべてのリプレイ・フィルタが除外フィルタとして処理され、これらのフィルタはリプレイされないワークロードの部分を定義することになります。これはデフォルトの動作です。

    このパラメータをEXCLUDEに設定すると、リプレイ・フィルタで定義されたワークロードの部分を除いて、取得されたすべてのデータベース・コールがリプレイされません。この場合、すべてのリプレイ・フィルタが包含フィルタとして処理され、これらのフィルタはリプレイされるワークロードの部分を定義することになります。

リプレイ・フィルタ・セットの使用

リプレイ・フィルタ・セットを作成してリプレイが初期化されると、リプレイ・フィルタ・セットを使用して、replay_dirディレクトリ内のリプレイをフィルタすることができます。

リプレイ・フィルタ・セットを使用するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.USE_FILTER_SET (filter_set => 'replayfilters');
  END;
  /
  

  この例では、USE_FILTER_SETプロシージャはreplayfiltersという名前のフィルタ・セットを使用します。

  この例のUSE_FILTER_SETプロシージャは、必須パラメータfilter_setを使用します。このパラメータは、リプレイで使用するフィルタ・セットの名前を指定します。

リプレイのタイムアウト・アクションの設定

この項では、ワークロード・リプレイのタイムアウト・アクションを設定する方法について説明します。リプレイのタイムアウト・アクションを設定すると、リプレイ時の極端に遅いユーザー・コールや、リプレイがハングする原因となるユーザー・コールを中断できます。リプレイのタイムアウト・アクションの設定が必要になるのは、たとえば、データベースのアップグレードの後で、最適でない実行計画によって生じるメモリー集中型問合せを中断するような場合です。

リプレイのタイムアウト・アクションが有効な場合、リプレイ・タイムアウト・アクションで指定された条件を超えてユーザー・コールが遅延すると、ORA-15569エラーでユーザー・コールが終了します。中断されたコールとそのエラーは、エラーの相違として報告されます。

リプレイ・タイムアウトを設定するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.SET_REPLAY_TIMEOUT (
                             enabled => TRUE,
                             min_delay => 20,
                             max_delay => 60,
                             delay_factor => 10);
  END;
  /
  

  この例のSET_REPLAY_TIMEOUTプロシージャで定義されるリプレイ・タイムアウト・アクションでは、リプレイ時の遅延が60分を超えるか、リプレイ時の遅延が20分を超えかつその経過時間が取得経過時間の10倍より大きいと、ユーザー・コールが中断されます。

  この例のSET_REPLAY_TIMEOUTプロシージャでは、次のパラメータを使用します。

  • enabled: リプレイのタイムアウト・アクションが有効か無効かを指定するパラメータ。デフォルト値はTRUEです。

  • min_delay: コールの遅延の下限を分単位で定義するパラメータ。リプレイのタイムアウト・アクションは、遅延がこの値を超えた場合にのみ実行されます。デフォルト値は10です。

  • max_delay: コールの遅延の上限を分単位で定義するパラメータ。遅延がこの値を超えると、リプレイのタイムアウト・アクションが実行され、エラーが発行されます。デフォルト値は120です。

  • delay_factor: min_delayとmax_delayの間のコール遅延について、その係数を定義するパラメータ。現在のリプレイの経過時間が、取得の経過時間とこの値を掛けた値より大きい場合、リプレイのタイムアウト・アクションがエラーを発行します。デフォルト値は8です。

リプレイ・タイムアウト・アクションを取得するには:

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

  DECLARE
    enabled        BOOLEAN;
    min_delay      NUMBER;
    max_delay      NUMBER;
    delay_factor   NUMBER;
  BEGIN
    DBMS_WORKLOAD_REPLAY.GET_REPLAY_TIMEOUT(enabled, min_delay, max_delay,
                             delay_factor);
  END;
  /
  

  この例のGET_REPLAY_TIMEOUTプロシージャは、次のパラメータを返します。

  • enabled: リプレイのタイムアウト・アクションが有効か無効かを返すパラメータ。

  • min_delay: コールの遅延の下限を分単位で返すパラメータ。

  • max_delay: コールの遅延の上限を分単位で返すパラメータ。

  • delay_factor: 遅延係数を返すパラメータ。

ワークロードのリプレイの開始

ワーク・リプレイを開始する前に実行するタスクがあります。たとえば:

• 取得されたワークロードの事前処理。詳細は、「APIを使用したデータベース・ワークロードの事前処理」を参照してください

• リプレイ・データの初期化。詳細は、「リプレイ・データの初期化」を参照してください

• リプレイ・オプションの指定。詳細は、「ワークロードのリプレイ・オプションの設定」を参照してください

• リプレイ・クライアントの起動。詳細は、「リプレイ・クライアントの起動」を参照してください

ノート:

ワークロード・リプレイを開始すると、新しいリプレイ・クライアントはデータベースに接続できなくなります。START_REPLAYプロシージャの実行前に起動されたリプレイ・クライアントのみ、取得したワークロードのリプレイに使用されます。

ワークロード・リプレイを開始するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.START_REPLAY ();
  END;
  /

ノート:

Oracle Databaseリリース19c以降では、DBA_RAT_CAPTURE_SCHEMA_INFOビューに、SQL文のlogin_schemaとcurrent_schemaの情報が示されます。拡張モードでのリプレイ中に、「ORA-00942: 表またはビューが存在しません」エラーが発生した場合は、DBA_RAT_CAPTURE_SCHEMA_INFOビューとDBA_WORKLOAD_CAPTURE_SQLTEXTビューを使用してエラーの原因になった表を調べます。その後で、該当する表に必要な権限をエラーが発生したユーザーに付与して、リプレイを再開してみます。通常は、これで問題が解決します。

ワークロード・リプレイの一時停止

ワークロード・リプレイを一時停止すると、それ以降にリプレイ・クライアントによって発行されるすべてのユーザー・コールは、ワークロード・リプレイが再開されるか取り消されるまで停止されます。すでに進行中のユーザー・コールは完了できます。このオプションを使用すると、リプレイを一時的に停止して変更を行い、その変更がリプレイの残りの部分に与える影響を確認することができます。

ワークロード・リプレイを一時停止するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.PAUSE_REPLAY ();
  END;
  /

ワークロード・リプレイの再開

この項では、一時停止されたワークロード・リプレイを再開する方法を説明します。

ワークロード・リプレイを再開するには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.RESUME_REPLAY ();
  END;
  /

ワークロード・リプレイの取消し

この項では、ワークロード・リプレイを取り消す方法を説明します。

ワークロード・リプレイを取り消すには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.CANCEL_REPLAY ();
  END;
  /

ワークロード・リプレイに関する情報の取得

リプレイ・ディレクトリ・オブジェクト内のワークロード取得に関する情報と、そのディレクトリからのワークロード・リプレイ試行の履歴に関する情報をすべて取得できます。デフォルトでは、ワークロード・リプレイ相違データはロードされませんが、このデータを選択的にロードする選択ができます。

ワークロード・リプレイに関する情報を取得するには:

• DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFOファンクションをコールします。

  GET_REPLAY_INFOファンクションはまず、ワークロードの取得に関する情報が含まれる行をDBA_WORKLOAD_CAPTURESビューにインポートします。デフォルトでは、これまでDBA_WORKLOAD_REPLAYSビューにロードされていないリプレイの情報のみがインポートされます。このファンクションは、DBA_WORKLOAD_REPLAYSビューのCAPTURE_ID列に関連付けられて、取得した情報にアクセスできる、キャプチャ・ディレクトリのcap_idを戻します(統合キャプチャ・ディレクトリの場合、cap_idは0を戻します)。

  GET_REPLAY_INFOファンクションでは、次のパラメータを使用します。

  • replay_dir: ワークロード・リプレイのディレクトリ・オブジェクト名を指定する必須パラメータ。

  • load_divergence: 相違データがロードされるかどうかを指定するオプション・パラメータ。このパラメータのデフォルト値はFALSEです。リプレイ・ディレクトリから取得した各リプレイ試行の行をDBA_WORKLOAD_REPLAY_DIVERGENCEビューにインポートして、相違データをロードするには、このパラメータをTRUEに設定します。あるいは、リプレイ情報が取得された後で、「ワークロード・リプレイの相違データのロード」で説明されているように、LOAD_DIVERGENCEプロシージャを使用して、ディレクトリ・オブジェクト内の1つのリプレイまたはすべてのリプレイの相違データを選択的にロードすることができます。

例12-1 ワークロード・リプレイに関する情報の取得

次の例に、ワークロード取得に関する情報と、jul14という名前のリプレイ・ディレクトリ・オブジェクトのワークロード・リプレイ試行の履歴に関する情報を取得する方法と、情報が取得されたことを確認する方法を示します。

DECLARE
  cap_id         NUMBER;
BEGIN
  cap_id := DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFO(replay_dir => 'jul14');
  SELECT capture_id
    FROM dba_workload_replays
   WHERE capture_id = cap_id;
END;
/

ワークロード・リプレイの相違データのロード

ワークロード・リプレイの相違データのロードは、リプレイ・ディレクトリから取得した各リプレイ試行の行をDBA_WORKLOAD_REPLAY_DIVERGENCEビューにインポートして、リプレイ試行中の相違のあるコールとエラーに関する情報を表示します。指定したディレクトリ・オブジェクト内の1つのワークロード・リプレイまたはすべてのワークロード・リプレイのいずれの相違データをロードするかを選択できます。

ワークロード・リプレイの相違データをロードするには:

1. 次のパラメータのいずれかを使用して、WORKLOAD_REPLAY.LOAD_DIVERGENCEプロシージャをコールします。

   • replay_id: 相違データをロードするワークロード・リプレイのIDを指定するパラメータ。このパラメータは、1つのワークロード・リプレイの相違データをロードする場合にのみ使用します。

   • replay_dir: ディレクトリ・オブジェクトの名前を指定するパラメータ(値の大/少文字は区別されます)。このパラメータは、指定したディレクトリ・オブジェクト内のすべてのワークロード・リプレイの相違データをロードする場合に使用します。

2. 相違データのロード・ステータスを確認するには、DBA_WORKLOAD_REPLAYSビューのDIVERGENCE_LOAD_STATUS列を問い合せます。

   TRUEの値は、相違データがロードされることを示し、FALSEの値はロードされないことを示します。

例12-2 1つのワークロード・リプレイの相違データのロード

次の例に、replay_idの値が12のワークロード・リプレイの相違データを取得する方法と、相違データがロードされたことを確認する方法を示します。

DECLARE
  rep_id         NUMBER;
BEGIN
  rep_id := DBMS_WORKLOAD_REPLAY.LOAD_DIVERGENCE (replay_id => 12);
  SELECT divergence_load_status
    FROM dba_workload_replays
   WHERE capture_id = rep_id;
END;
/

ワークロード・リプレイに関する情報の削除

指定したディレクトリ・オブジェクト内の1つのワークロード・リプレイまたはすべてのワークロード・リプレイのいずれかについて取得した情報を削除できます。「ワークロード・リプレイに関する情報の取得」で説明されているように、削除された情報は、GET_REPLAY_INFOファンクションを使用して取得できます。

ワークロード・リプレイに関する情報を削除するには:

1. replay_idパラメータを使用して、DBMS_WORKLOAD_REPLAY.DELETE_REPLAY_INFOプロシージャをコールします。

   • replay_id: リプレイ情報を削除するワークロード・リプレイのIDを指定するパラメータ。このパラメータは、1つのワークロード・リプレイの情報を削除する場合に使用します。

2. デフォルトでは、ワークロード・リプレイに関する情報を削除しても、そのデータはディスクからは削除されません。

例12-3 ワークロード・リプレイに関する情報の削除

次の例に、ワークロード取得に関する情報と、IDが2のワークロード・リプレイに対するワークロード・リプレイ試行の履歴に関する情報を削除する方法を示します。リプレイ・データはディスクから削除されないため、「ワークロード・リプレイに関する情報の取得」で説明されているように、GET_REPLAY_INFOファンクションのコールにより取得できます。

BEGIN
  DBMS_WORKLOAD_REPLAY.DELETE_REPLAY_INFO (replay_id => 2);
END;
/

ワークロードのリプレイのAWRデータのエクスポート

AWRデータをエクスポートすると、ワークロードの詳細な分析が可能になります。このデータは、2つのワークロードの取得(またはリプレイ)に対してAWR期間比較レポートを実行する場合には必須です。

AWRデータをエクスポートするには:

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

  BEGIN
    DBMS_WORKLOAD_REPLAY.EXPORT_AWR (replay_id => 1);
  END;
  /
  

  この例では、リプレイIDが1のワークロード・リプレイに対応するAWRスナップショットがエクスポートされ、また、ワークロードのリプレイ中に取得されたSQLチューニング・セットもエクスポートされます。

  EXPORT_AWRプロシージャでは、AWRスナップショットをエクスポートするリプレイのIDを指定する必須パラメータreplay_idを使用します。

ノート:

このプロシージャは、対応するワークロードのリプレイが現在のデータベースで実行され、元のリプレイ期間に対応するAWRスナップショットがまだ使用可能である場合にのみ、機能します。

ワークロードのリプレイのAWRデータのインポート

リプレイ・システムからAWRデータをエクスポートすると、AWRデータを別のシステムにインポートできます。AWRデータをインポートすると、ワークロードの詳細な分析が可能になります。このデータは、2つのワークロードの取得(またはリプレイ)に対してAWR期間比較レポートを実行する場合には必須です。

AWRデータをインポートするには:

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

  CREATE USER capture_awr
  SELECT DBMS_WORKLOAD_REPLAY.IMPORT_AWR (replay_id => 1,
                                          staging_schema => 'capture_awr')
    FROM DUAL;
  

  この例では、取得IDが1のワークロード・リプレイに対応するAWRスナップショットがcapture_awrという名前のステージング・スキーマを使用してインポートされます。

  この例のIMPORT_AWRプロシージャでは、次のパラメータを使用します。

  • 必須パラメータreplay_idでは、AWRスナップショットをインポートするリプレイのIDを指定します。

  • 必須パラメータstaging_schemaでは、リプレイ・ディレクトリからSYS AWRスキーマにAWRスナップショットをインポートする際に、ステージング領域として使用される現在のデータベースの既存のスキーマ名を指定します。

ノート:

staging_schemaパラメータで指定したスキーマにAWR表と同じ名前の表が含まれる場合、このファンクションは失敗します。

APIを使用したワークロードのリプレイの監視

この項では、APIおよびビューを使用したワークロード・リプレイの監視方法について説明します。また、「Enterprise Managerを使用したワークロードのリプレイの監視」で説明されているように、Oracle Enterprise Managerを使用してワークロードのリプレイを監視できます。

この項では、次の項目について説明します。

• 違いのあるコールに関する情報の取得

• ビューを使用したワークロードのリプレイの監視

違いのあるコールに関する情報の取得

リプレイ時に、リプレイ・システムと取得システムの間のエラーおよびデータに相違があった場合は、違いのあるコールとして記録されます。

違いのあるコールに関する情報(SQL識別子、SQLテキスト、バインド値など)を取得するには、次のパラメータを使用してGET_DIVERGING_STATEMENTファンクションをコールします。

• replay_idパラメータを違いのあるコールを含むリプレイのIDに設定します。

• stream_idパラメータを違いのあるコールのストリームIDに設定します。

• call_counterパラメータを違いのあるコールのコール・カウンタに設定します。

違いのあるコールに関するこれらの情報を表示するには、DBA_WORKLOAD_REPLAY_DIVERGENCEビューを使用します。次の例は、ファンクション・コールを示しています。

DECLARE
  r                   CLOB;
  ls_stream_id        NUMBER;
  ls_call_counter     NUMBER;
  ls_sql_cd           VARCHAR2(20);
  ls_sql_err          VARCHAR2(512);
  CURSOR c IS
  SELECT stream_id, call_counter
  FROM DBA_WORKLOAD_REPLAY_DIVERGENCE
  WHERE replay_id = 72;
BEGIN
  OPEN c;
  LOOP
  FETCH c INTO ls_stream_id, ls_call_counter;
  EXIT when c%notfound;
  DBMS_OUTPUT.PUT_LINE (ls_stream_id||''||ls_call_counter);
  r:=DBMS_WORKLOAD_REPLAY.GET_DIVERGING_STATEMENT(replay_id => 72,
  stream_id => ls_stream_id, call_counter => ls_call_counter);
  DBMS_OUTPUT.PUT_LINE (r);
  END LOOP;
END;
/

関連項目:

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

ビューを使用したワークロードのリプレイの監視

この項では、ワークロードのリプレイを監視するために表示できるビューの概要を示します。これらのビューにアクセスするには、DBA権限が必要です。

• DBA_WORKLOAD_CAPTURESビュー: 現在のデータベースで取得されたワークロードの取得をすべて示します。

• DBA_WORKLOAD_FILTERSビュー: 現在のデータベースに定義されたワークロードの取得に使用されるワークロード・フィルタをすべて示します。

• DBA_WORKLOAD_REPLAYSビュー: 現在のデータベースでリプレイされたワークロードのリプレイをすべて示します。

• DBA_WORKLOAD_REPLAY_DIVERGENCEビュー: 違いのあるコールに関する情報(リプレイID、ストリームID、コール・カウンタなど)を表示できます。

• DBA_WORKLOAD_DIV_SUMMARYビューには、DBA_WORKLOAD_REPLAY_DIVERGENCEビューのリプレイの相違情報のサマリーが表示されます。

• DBA_WORKLOAD_REPLAY_FILTER_SETビュー: 現在のデータベースで定義されたワークロード・リプレイに使用されるワークロード・フィルタをすべて示します。

• DBA_WORKLOAD_CONNECTION_MAPビュー: ワークロードのリプレイの接続マッピング情報を示します。

• V$WORKLOAD_REPLAY_THREADビュー: リプレイ・クライアントからのすべてのセッションに関する情報を示します。

関連項目:

• これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください