取得されたワークロードの事前処理後に、Oracle Databaseの同じバージョンを稼働しているリプレイ・システムで繰り返しリプレイすることができます。通常は、事前処理されたワークロードがリプレイされるリプレイ・システムは、本番システムとは別のテスト・システムである必要があります。
この章では、テスト・システムでデータベース・ワークロードをリプレイする方法について説明します。内容は次のとおりです。
ヒント: データベース・ワークロードをリプレイする前に、次の操作を行う必要があります。
|
ワークロードのリプレイを適切に計画し、リプレイ・システムを適切に準備することで、リプレイを正確に行うことができます。データベースのワークロードをリプレイする前に、必要に応じて、次の手順を確認して実行します。
取得したワークロードは、事前処理してリプレイ・システムにコピーしておく必要があります。事前処理したワークロードのコピー先ディレクトリのディレクトリ・オブジェクトが、リプレイ・システムに存在している必要があります。
ワークロードをリプレイする前に、リプレイ・システムのアプリケーション・データの状態を、ワークロードの取得の開始時における取得システムのデータの状態と論理的に同じにする必要があります。これによって、リプレイ時のリプレイの相違が最小限に抑えられます。データベースのリストア方法は、ワークロードの取得前に使用したバックアップ方法に応じて異なります。たとえば、取得システムのバックアップにRMANを使用した場合は、テスト・データベースの作成にRMANのDUPLICATE
機能を使用できます。詳細は、「データベース・ワークロードの取得の前提条件」を参照してください。
リプレイ・システムで適切なアプリケーション・データを使用してデータベースを作成したら、テストするシステム変更(データベースやオペレーティング・システムのアップグレードなど)を行います。データベース・リプレイの主な目的は、取得したワークロードでシステム変更の影響をテストすることです。したがって、実行したシステム変更によって、取得したワークロードで実施するテストが定義されることになります。
取得したワークロードに、データベース・リンクや外部表などの外部システムへの参照が含まれている場合があります。通常、このような外部との対話は、リプレイ時に他の本番システムに影響が及ばないように再構成する必要があります。ワークロードのリプレイ前に解決する必要がある外部参照は、次のとおりです。
データベース・リンク
通常、リプレイ・システムが他のデータベースと相互作用するのは好ましくありません。したがって、リプレイに必要なデータが含まれている適切なデータベースを指すように、すべてのデータベース・リンクを再構成する必要があります。
外部表
外部表によって参照されるディレクトリ・オブジェクトを試用して指定されたすべての外部ファイルは、リプレイ時にデータベースに対して使用可能である必要があります。これらのファイルのコンテンツは、取得時と同一である必要があり、外部表の定義に使用されるファイル名およびディレクトリ・オブジェクトも有効である必要があります。
ディレクトリ・オブジェクト
本番システムのディレクトリへの参照は、データベースのリストア後にリプレイ・システムに存在するディレクトリ・オブジェクトを適切に再定義することによって再構成する必要があります。
URL
ワークロードの取得時にアクセスしたWebサービスがリプレイ時に適切なURLを指すように、データベースに格納されているURL/URIを構成する必要があります。ワークロードが本番システムに格納されているURLを参照する場合、リプレイ時にそのテスト・システム・ネットワークを切り離す必要があります。
電子メール
リプレイ時に電子メール通知が再送信されないようにするには、送信電子メールのリクエストを無視するように、リプレイ・システムにアクセス可能な電子メール・サーバーを構成する必要があります。
ヒント: リプレイ時に他の本番システムに影響が及ばないようにするために、リプレイは、本番環境のホストにアクセスできない切り離されたプライベート・ネットワーク内で実行することをお薦めします。 |
ワークロードの取得時に、本番システムへの接続に使用される接続文字列が取得されます。リプレイが正常に完了するには、この接続文字列をリプレイ・システムに再マッピングする必要があります。これによって、リプレイ・クライアントは再マッピングされた接続を使用してリプレイ・システムに接続できます。
Oracle Real Application Clusters(Oracle RAC)データベースの場合、すべての接続文字列をロード・バランシング接続文字列にマップできます。これは、リプレイ・システムのノード数が取得システムとは異なる場合に特に便利です。また、ワークロードを特定のインスタンスに適用する場合は、サービスを使用するか、または再マッピングした接続文字列でインスタンス識別子を明示的に指定することができます。
ワークロードの取得時、本番システムに接続するために使用されるデータベース・ユーザーまたはスキーマのユーザー名が取得されます。取得したユーザー名は、新しいユーザーまたはスキーマに再マッピングするよう選択できます。
データベースをリストアして接続を再マッピングした後で、必要に応じて次のリプレイ・オプションを設定できます。
synchronization
パラメータによって、取得したワークロード内のCOMMIT
の順序をリプレイ時に保持するかどうかが制御されます。
このパラメータをSCN
に設定すると、取得したワークロード内のCOMMIT
の順序がリプレイ時に保持され、すべてのリプレイ・アクションがすべての依存COMMIT
アクションの完了後にのみ実行されます。
このパラメータを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
という名の実行可能ファイル)で、スレッドごとに取得済セッションからワークロードを発行します。リプレイが開始される前に、データベースはリプレイ・クライアントの接続を待機します。この時点で、リプレイ・クライアントを設定して起動する必要があり、このリプレイ・クライアントがリプレイ・システムに接続し、ワークロードに取得された内容に基づいてリクエストを送信します。
リプレイ・クライアントを開始する前に、次の項目を確認します。
リプレイ・クライアント・ソフトウェアが実行場所のホストにインストールされていること
リプレイ・クライアントがリプレイ・ディレクトリにアクセスできること
リプレイ・ディレクトリに事前処理された取得済のワークロードが含まれていること
リプレイ・ユーザーが正しいユーザー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 11.2.0.0.2 - Production on Fri May 1 13:06:33 2009 Copyright (c) 1982, 2009, 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
ビューに格納されている接続の再マッピングを使用して接続します。これがデフォルト設定です。
次の例は、wrc
実行可能ファイルをリプレイ・モードで実行する方法を示しています。
%> wrc system/password@test mode=replay replaydir=./replay
この例では、wrc
実行可能ファイルによってリプレイ・クライアントが起動され、現在のディレクトリ内のreplay
サブディレクトリに格納されている取得済のワークロードがリプレイされます。
すべてのリプレイ・クライアントが接続すると、データベースによって取得済のワークロードのストリームがすべての使用可能なリプレイ・クライアントに自動的に配分され、ワークロードのリプレイが開始可能になります。V$WORKLOAD_REPLAY_THREAD
ビューで、リプレイ・クライアントのステータスを監視できます。リプレイが終了すると、すべてのリプレイ・クライアントの接続が自動的に切断されます。
wrc
実行可能ファイルをlist_hostsモードで実行すると、ワークロードの取得およびワークロードのリプレイに関連したホストを表示することができます。
list_hostsモードでは、wrc
実行型ファイルはキーワードreplaydir
を使用してリプレイ対象の前処理済ワークロードの取得を含むディレクトリを指定します。指定しない場合は、デフォルトで現在のディレクトリが使用されます。
次の例は、list_hostsモードでwrc
実行可能ファイルを実行する方法を示しています。
%> wrc mode=list_hosts replaydir=./replay
この例では、現在のディレクトリ内のreplay
サブディレクトリに格納されているワークロード取得またはリプレイに関連したすべてのホストを示すために、wrc
実行可能ファイルを実行しています。次の出力例では、ワークロードの取得およびその後の3回のリプレイに関連したホストが示されています。
Workload Replay Client: Release 11.2.0.0.2 - Production on Fri May 1 13:44:48 2009 Copyright (c) 1982, 2009, Oracle. All rights reserved. Hosts found: Capture: prod1 prod2 Replay 1: test1 Replay 2: test1 test2 Replay 3: testwin
この項では、Enterprise Managerを使用したデータベース・ワークロードのりプレイ方法について説明します。
データベース・ワークロードをリプレイするための主要ツールは、Oracle Enterprise Managerです。Oracle Enterprise Managerを使用できない場合、「APIを使用したデータベース・ワークロードのリプレイ」で説明されているように、APIを使用してデータベース・ワークロードをリプレイすることも可能です。
注意: 続行する前に、リプレイ・タスクが作成済でリプレイ・タスクからリプレイが作成されている必要があります。これを行う方法の詳細は、「Enterprise Managerを使用した単一のデータベース・ワークロードの準備」を参照してください。 |
Enterprise Managerを使用してデータベース・ワークロードをリプレイするには、次の手順を実行します。
Enterprise Manager Cloud Controlコンソールの「エンタープライズ」メニューで、「クオリティ管理」、「データベース・リプレイ」の順に選択します。
「データベース・ログイン」ページが表示されたら、管理者権限のあるユーザーとしてログインします。
「データベース・リプレイ」ページが表示されます。
「リプレイ・タスク」タブを選択し、表の希望のリプレイ・タスクのリンクをクリックします。
リプレイのリプレイ・タスク・ページが表示されます。
「リプレイ」セクションの「作成」をクリックしてリプレイを作成します。
「リプレイの作成」ポップアップが表示されます。
必要な名前と説明(オプション)を入力し、「ターゲット・データベース」アイコンをクリックします。
「検索と選択: ターゲット」ポップアップが表示されます。
適切なデータベースを選択し、「選択」をクリックします。
「リプレイの作成」ポップアップの「OK」をクリックします。
リプレイを実行するリンク付きの「タスク・リスト」が含まれるリプレイのデータベース・リプレイ・ページが表示されます。
「ワークロード・リプレイ」タスクのリンクをクリックします。
「ワークロード・リプレイ: ワークロードの検索」ページが表示されます。
必要なワークロードの場所オプションを選択します。
リプレイ・クライアントがアクセス可能なリプレイ場所に格納されている場所からワークロードをまだコピーしていない場合、ワークロードをコピーするオプションを選択します。それ以外の場合は、リプレイするワークロードを含む既存のリプレイ・ディレクトリを使用するオプションを選択します。
「次へ」をクリックして、ワークロード・リプレイ: ワークロードのコピー・ページを表示します。
必要な資格証明およびワークロードをコピーする新たなワークロード・ディレクトリの場所を指定して、「次へ」をクリックします。
統合されたリプレイには複数のソース・ワークロードがあるため、複数のソース資格証明をワークロード・ディレクトリの現在の場所に入力しなければならないことがあります。統合リプレイの詳細は、第13章「データベース統合リプレイの使用」の「Enterprise Managerを使用したデータベース統合リプレイ」を参照してください。
システムは処理中に進捗状況の棒グラフを表示して応答し、コピー操作が終了した後にワークロード・リプレイ: ディレクトリを選択ページが表示されます。
ディレクトリ・オブジェクトを指定するかワークロードが含まれる場所をポイントする新しいディレクトリ・オブジェクトを作成します。前の手順でワークロードを新しい場所にコピーするよう選択をした場合、ディレクトリ・オブジェクトが「ワークロード・ディレクトリの新しい場所」で指定した正しい場所を確実にポイントするようにします。
システムは取得サマリーを表示して応答します。「詳細の取得」セクションを展開して、ワークロード・プロファイルとワークロード・フィルタを表示できます。ワークロード取得アナライザ・レポートとデータベース取得レポートも生成できます。統合されたリプレイに取得サマリーは表示されません。
「次へ」をクリックして、ワークロード・リプレイ: 初期化オプション・ページを表示します。
「SQLパフォーマンス・アナライザ」セクションで、デフォルトでは有効になっており推奨されているSQL文の取得オプションを保持または無効化します。リプレイ終了時にSQLチューニング・セットを比較しない場合は、このオプションを無効化できます。
SQLパフォーマンス・アナライザでは、SQLチューニング・セット内のSQL文のパフォーマンスに関する環境の変更の影響の分析を開始できます。データベースのアップグレード、初期化パラメータの変更、Exadataシミュレーションまたはカスタム試験の結果をテストする、SQLパフォーマンス・アナライザ・タスクを作成および分析できます。このタスクでは、試行前の変更と試行後の変更の結果を比較します。
データベースのリプレイでは、変更がシステム全体に及ぼす影響が分析されますが、SQLパフォーマンス・アナライザとともにSQLチューニング・セットを使用すれば、変更がSQL文と実行計画にどのように影響するか、SQLを中心とした分析を行うことができます。
ワークロードのリプレイ中にSQLチューニング・セットを取得することで、SQLパフォーマンス・アナライザを使用して、そのSQLチューニング・セットとワークロードの取得時に取得された別のSQLチューニング・セットを比較できます(SQL文を再実行する必要はありません)。この方法では、データベース・リプレイの実行中に、SQLパフォーマンス・アナライザ・レポートを取得して、変更の前と後のSQLパフォーマンスを比較することができます。
「ソースを指定」セクションでは、リプレイの初期オプションはオプションのカスタマイズ・ページの接続マッピングおよびパラメータを参照しています。接続はワークロードとともに取得されます。
注意: このセクションは、統合リプレイまたはOracle RACでは表示されません。 |
「次へ」をクリックして、ワークロード・リプレイ: オプションのカスタマイズ・ページを表示します。
取得した接続文字列を、リプレイ・システムを指す接続文字列に再マッピングします。それぞれの取得の接続は再マッピングする必要があることに注意してください。たとえば、前述の図では、capture12_1およびcapture12_adcの両方の接続を再マッピングする必要があります。
(統合リプレイでは、ワークロードごとに接続を再マッピングできます。ワークロードを選択するには、「取得名」ドロップダウンを利用します。)
「接続マッピング」タブをクリックします。取得した接続文字列を再マッピングするには、複数の方法があります。次のいずれかを選択できます。
すべてのクライアント接続に単一の接続記述子を使用する: このオプションを選択して、使用する接続記述子を入力します。接続記述子が、リプレイ・システムを示す必要があります。
接続をテストするには、「接続のテスト」をクリックします。接続記述子が有効な場合は、正常に接続されたことを示す情報メッセージが表示されます。
すべてのクライアント接続に単一のTNSネット・サービス名を使用する: このオプションを選択して、使用するネット・サービス名を入力します。すべてのリプレイ・クライアントは、ローカルのtnsnames.ora
ファイルを使用してネット・サービス名を解決する必要があります。
ワークロード内の取得されたクライアント接続記述子ごとに個別の接続記述子またはネット・サービス名を使用する: このオプションを選択して、取得システムの値ごとに、リプレイ・クライアントが使用するリプレイ・システムの値を入力します。「初期化オプション」ステップで「前回のリプレイのオプションを使用」オプションを選択した場合、別の接続記述子の使用に関するオプションが選択され、前回のリプレイ・システムの値が次のテキスト・フィールドに表示されます。
注意: このオプションは、統合リプレイにはありません。 |
詳細は、「接続の再マッピング」を参照してください。
リプレイの一部を制御するリプレイ・オプションを、リプレイ・パラメータを使用して指定します。
リプレイの動作を変更するには、「リプレイ・パラメータ」タブをクリックし、リプレイ・パラメータごとに目的の値を入力します。デフォルト値を使用することをお薦めします。リプレイ・パラメータの設定については、「リプレイ・オプションの指定」を参照してください。
リプレイ・パラメータを設定したら、「次へ」をクリックします。
「ワークロード・リプレイ: リプレイ・クライアントの準備」ページが表示されます。
リプレイ・クライアントでリプレイの準備ができていることを確認します。
処理を行う前に、リプレイ・クライアントを設定する必要があります。詳細は、「リプレイ・クライアントの設定」を参照してください。
「見積り」をクリックして、リプレイに必要なリプレイ・クライアントとCPUの数を特定します。
「リプレイ・クライアント・ホストの追加」をクリックして、リプレイ・クライアントのホストを追加します。(リプレイ・クライアントのホストを追加しない場合は、Enterprise Managerを使用しないでコマンドラインからリプレイ・クライアントを開始して続行できます)。
「検索と選択: リプレイ・クライアント・ホスト」ポップアップが表示されます。
ターゲット名を指定して「実行」をクリックするか、「実行」をクリックして使用可能なホストのリスト全体を表示します。
ホストを選択して、「選択」をクリックします。
「リプレイ・クライアント・ホスト」表の「ターゲット」列にホスト名が表示されたら、見積り結果で推奨されたリプレイ・クライアント数を指定し、ホストにリストされたCPU数が見積り結果の最小推奨数を満たすことを確認します。取得されたワークロードごとに、少なくとも1つのリプレイ・クライアントを起動する必要があります。
構成済の列で、「いいえ」リンクをクリックして、表示されたポップアップ内でリプレイ・クライアントを構成します。
ポップアップに値を入力した後に、「適用」をクリックします。構成済の列の「リプレイ・クライアント・ホスト」表に「はい」と表示されます。
「次へ」をクリックして、リプレイ・クライアントを起動して、ワークロード・リプレイ: クライアント接続の待機ページを表示します。
リプレイ・クライアントの起動については、「リプレイ・クライアントの設定」を参照してください。
注意: プロセスのこの手順に「エンタープライズ」メニューからたどりついた場合は、リプレイ・ジョブおよびリプレイ結果記憶域ホスト用の資格証明も入力する必要があります。 |
リプレイ・クライアントを起動すると、リプレイ・クライアント接続が「クライアント接続」表に表示されます。
リプレイ・クライアントが接続されると、時計の下のテキストが変わります。
1つ以上のリプレイ・クライアントが接続されると、「クライアント接続」表が移入されます。
すべてのリプレイ・クライアントが接続されたら、ページ下部にホストの資格証明書を入力しリプレイ・ジョブを開始して、「次へ」をクリックして、ワークロード・リプレイ: 確認ページを表示します。
ワークロードのリプレイに関して定義したオプションおよびパラメータを確認します。
ワークロードのリプレイ・ジョブを正常に発行するには、「接続されているリプレイ・クライアント」の値を1以上にする必要があります。
「発行」ボタンは、1つ以上のリプレイ・クライアントが接続されている場合のみ有効です。
表示内容がすべてが意図したとおりである場合は、「発行」をクリックしてリプレイ・ジョブを発行します。
リプレイが開始された後、「ワークロード・リプレイは開始されました。」というシステム・メッセージが表示された状態で、このリプレイのデータベース・リプレイ・ページの「ホーム」タブが再表示されます。
アクティブなワークロードのリプレイの監視については、「アクティブなワークロードのリプレイの監視」を参照してください。
リプレイ・スケジュール機能では、統合リプレイに含める取得済ワークロードのインスタンスをスケール・アップし、リプレイ内のインスタンスの相対再生スケジューリングを制御できます。各インスタンスのアクティブ・セッション・チャートの配置を更新することで、取得済ワークロード・インスタンスの相対スケジューリングが視覚的に表示されます。
この機能は、Cloud Control Databaseプラグイン12.1.0.5以降のリリースで利用できます。
この機能では、次のタスクを実行できます。
様々な時間間隔で実行できるようにインスタンスをオフセット
各ワークロード・インスタンスの相対リプレイ開始時間を調整し、取得ワークロードのスケジュール済インスタンスにアクティブ・セッションの平均ピーク時間を配置できます。このワークロード・ピークの配置により、システムの負荷が最大化される可能性があり、その結果、様々なワークロード条件でテスト・システムがどのように反応するかを実験できます。
取得済ワークロードのインスタンスを追加してリプレイ・ワークロードをスケール・アップ
追加した各インスタンスは、他のインスタンスとは独立してリプレイされます。
ワークロードの複数のインスタンスを指定してワークロードをスケール・アップすると、デフォルトおよび推奨の構成では、インスタンスのいずれかでDML文がリプレイされます。追加のすべてのインスタンスは文の問合せ(読取り専用)をリプレイするのみです。
たとえば、ワークロードに従業員データベースへのSQL挿入がある場合、通常は挿入を実行するインスタンスを1つのみにし、それ以外のインスタンスでは、この挿入でデータベースを変更するユーザー・コールを省略します。ただし、「問合せのみリプレイ」チェック・ボックスの選択を解除して、ワークロードのすべての文をリプレイすることで、インスタンスのデフォルト設定をオーバーライドできます。
リプレイ・スケジュールの計画ページにアクセスするには、次の手順に従います。
「データベース・リプレイ」ホームページで、「リプレイ・タスク」タブをクリックします。
複数のワークロードについて既存のリプレイ・タスクの名前をクリックして、「リプレイ・タスク」ページに移動します。
「作成」をクリックして、新しいリプレイを作成します。
「リプレイの作成」ポップアップで必要な情報を指定して、「OK」をクリックします。
「リプレイ」表に新しいリプレイが表示されます。
「リプレイ」表の新しいリプレイの名前をクリックします。
「リプレイ」ページにタスク・リストが表示されます。
リプレイ・スケジュールの計画リンクをクリックします。
リプレイ・スケジュールの計画ページが表示されます。
リプレイをスケール・アップするには、次の手順に従います。
ワークロード・インスタンスの追加ボタンの横のドロップダウンで、インスタンスを追加する取得ワークロードを選択します。
ワークロード・インスタンスの追加をクリックしてインスタンスを追加します。
時間間隔をスケジュールするには、次の手順に従います。
リプレイ遅延列で、最初の取得インスタンスをデフォルト値の0のままにするか、インスタンスの実行が開始されるまでの必要な時間(分)を調整します。
テスト用にパフォーマンス・スパイクをどのように実行するかを表す値をすべて設定するまで、取得インスタンスごとに前述の手順を繰り返します。
ワークロード・ピークを自動配置するには、次の手順に従います。
自動配置ボタンをクリックします。
問合せのみのインスタンスを指定するには、次の手順に従います。
問合せのみにするインスタンスごとに、「問合せのみリプレイ」チェック・ボックスを有効にします。
更新済スケジュールを確認するには、次の手順に従います。
「データベース・リプレイ」ページの「リプレイ・タスク」タブで、スケジュール済リプレイを含む「リプレイ・タスク」リンクをクリックします。
「リプレイ・タスク」ページが表示されます。
「リプレイ・タスク」表でスケジュール済のタスクをクリックします。
「リプレイ」ページの「確認」タブをクリックします。
この項では、Enterprise Managerを使用したワークロード・リプレイの監視方法について説明します。ワークロードのリプレイを監視するための主要ツールは、Oracle Enterprise Managerです。Enterprise Managerを使用すると、次の操作を実行できます。
アクティブなワークロードのリプレイの監視または停止
完了したワークロードのリプレイの表示
Oracle Enterprise Managerを使用できない場合は、「APIを使用したワークロードのリプレイの監視」で説明されているように、APIおよびビューを使用してワークロードのリプレイを監視できます。
この項には次のトピックが含まれます:
この項では、Enterprise Managerを使用してアクティブなワークロードのリプレイを監視する方法について説明します。
アクティブなワークロードのリプレイを監視するには、次の手順を実行します。
データベース・リプレイ・ページで「リプレイ・タスク」タブをクリックします。
リプレイの進捗状況を監視するリプレイが含まれるリプレイ・タスクの名前をクリックします。
リプレイ・タスク・ページの「リプレイ」セクションから、リプレイの作成ウィザードで処理用に発行したリプレイの名前をクリックします。(このリプレイの「ステータス」列には「進行中」と表示されています。)
データベース・リプレイ・ページの「ホーム」タブが表示され、「リプレイ・サマリー」に実行のステータスが表示されます。
リプレイの進行中には、「リプレイの進捗状況」チャートのリプレイ線が動的に更新されます。「リフレッシュ」ボタンをクリックすると、チャートを更新できます。
「リプレイの進捗状況」チャートのユーザー・コール線は、同じ時期の取得と比較して、データベースがどの程度のワークロードを処理したかを示しています。
リプレイが完了するまで、「リプレイ相違サマリー」のデータは使用できません。
この項では、完了したワークロードのリプレイをEnterprise Managerを使用して表示する方法について説明します。
完了したワークロードのリプレイを表示するには、次の手順を実行します。
データベース・リプレイ・ページで「リプレイ・タスク」タブをクリックします。
表示する完了済リプレイが含まれるリプレイ・タスクの名前をクリックします。
リプレイ・タスク・ページの「リプレイ」セクションから、リプレイの作成ウィザードで処理用に発行したリプレイの名前をクリックします。(このリプレイの「ステータス」列には「完了」と表示されています。)
データベース・リプレイ・ページの「ホーム」タブが表示され、「リプレイ・サマリー」に完了のステータスが表示されます。
「ユーザー・コール」チャートのリプレイ線は、開始から完了までのリプレイ全体を通して、リプレイの進捗状況をグラフィカルに示します。「リプレイの進捗状況」チャートの経過時間は、関連する取得に設定された分数に一致します。
グラフに、ワークロードの取得中にユーザー・コールに関して経過した時間と比較して、同じワークロードのリプレイにかかった時間が表示されます。「リプレイ」の線が「取得」の線の上側または左側に表示される場合、リプレイ・システムは取得システムよりも高速にワークロードを処理しています。
「リプレイ相違サマリー」には、リプレイ・システムと取得システム間のエラーおよびデータの矛盾点が、リプレイ時に違いが出たデータベース・コールとして表示されます。リプレイの質の測定値として違いが出た合計コール数の割合を使用できます。
違いが出たコールの詳細を表示するには、「件数」列で違いが出たコールのタイプに対応するリンクをクリックし、リプレイ時に違いのあったコール・ページにアクセスします。「リプレイ時に違いのあったコール」ページには、取得されたワークロードと違いがあるリプレイ済コールの最も関連性が高いセットが、共通属性値および指定したフィルタ条件に基づいてグループ化されて表示されます。違いがある特定のコールに関する詳細(コールの属性、SQLテキスト、バインド変数など)を表示するには、「SQL ID」列の対応するリンクをクリックすると、違いの出た文をリプレイするページが表示されます。
データベース・リプレイ・ページに戻るには、「データベース・リプレイ」ブレッドクラムをクリックします。
Enterprise Manager外部のワークロードのインポートと同様に、リプレイをEnterprise Managerにインポートして管理できます。リプレイをインポートするには、1つ以上のワークロードおよびリプレイを含めることができるリプレイ・タスクからインポートします。リプレイ・タスクは、データベース・リプレイの階層の最上部にあり、これらの他の従属コンポーネントのコンテナとして機能します。
インポート対象のリプレイは、テスト・データベースで実行したり、リプレイを完了して、ファイル・システムにリプレイ・ディレクトリを格納できます。
この機能は、Cloud Control Databaseプラグイン12.1.0.5以降のリリースで利用できます。
Enterprise Manager外部のリプレイをインポートするには、次の手順に従います。
「データベース・リプレイ」ページの「リプレイ・タスク」タブをクリックし、目的のリプレイ・タスクを選択します。
「リプレイ・タスク」ページが表示されます。
「リプレイ」セクションの「インポート」をクリックします。
「リプレイのインポート: ソース」ページが表示されます。
次の3つの選択肢のいずれかを選択して、リプレイをインポートし、「次へ」をクリックします。
完了した1つ以上のリプレイをファイル・システムのディレクトリからインポート
このオプションは、通常APIを使用して作成されたリプレイに適用され、後続の処理用にEnterprise Managerにインポートします。この場合、Enterprise Managerは必ずしもリプレイ・データベースを管理していない可能性があります。
完了した1つ以上のリプレイをデータベース・ターゲットからインポート
この場合、Enterprise Managerはリプレイ・データベースをすでに管理している可能性があります。リプレイは、このデータベースで実行された可能性があるか、前述のオプションの場合と同様にロードされた可能性があります。
データベース・ターゲットで実行中のこのリプレイ・タスクのリプレイにアタッチ
このオプションは前述のオプションと似ていますが、すでに完了しているリプレイではなく、実行中のリプレイである点が異なります。
「リプレイのインポート: データベース」ページが表示されます。
「データベース・ターゲット」フィールドの横の検索アイコンをクリックして、表示されるポップアップからデータベースを選択します。
注意: リプレイを読み取るデータベースのターゲット・バージョンは、リプレイ・タスクで使用されるバージョン以上である必要があります。たとえば、Oracle Database 12xで使用されるリプレイ・タスクの場合、リプレイの読取りで選択するデータベースはバージョン12x以上である必要があります。 |
データベースおよびホスト資格証明が要求されます。
前述の手順で、完了した1つ以上のリプレイをファイル・システムのディレクトリからインポートを選択した場合は、ワークロードの場所も要求されます。
リプレイ・タスクでは、リプレイ・タスクに含まれるワークロードの数に基づいて、統合リプレイであるかどうかを判別できます。統合リプレイの場合は、ワークロードの場所に統合リプレイのディレクトリを入力するよう求められます。
前述の手順で必要な入力を行い、「次へ」をクリックします。
「リプレイのインポート: リプレイ」ページが表示されます。
手順3の選択に従って表示されるボタンに応じて、「リプレイのロード」または「リプレイの検出」のいずれかをクリックします。
リプレイが1つ以上見つかった場合は、検出されたリプレイ表に表示されます。
「次へ」をクリックして、リプレイをロードするか、リプレイを1つ以上選択し、「次へ」をクリックしてリプレイのインポートを継続します。
「リプレイのインポート: 確認」ページが表示されます。
すべてが目的どおりに表示されたら、「送信」をクリックします。
「データベース・リプレイ」ページには、ジョブが正常に送信されたことを示すメッセージが表示されます。表で、インポートしたリプレイの「ステータス」列に「進行中」と表示されます。
ヒント: 「確認」ステップで送信したリプレイ名をクリックして、ジョブの進行状況を確認できます。「リプレイ・サマリー」ページが表示され、データベース・リプレイ・インポート・ジョブ・リンクをクリックして、ジョブ実行ステップの進行状況を確認できます。 |
この項では、DBMS_WORKLOAD_REPLAY
パッケージを使用してデータベース・ワークロードをリプレイする方法について説明します。また、「Enterprise Managerを使用したデータベース・ワークロードのリプレイ」で説明されているように、Oracle Enterprise Managerを使用してデータベース・ワークロードをリプレイできます。
DBMS_WORKLOAD_REPLAY
パッケージを使用したデータベース・ワークロードのリプレイは、次に示す複数の手順で構成されているプロセスです。
関連項目:
|
取得したワークロードを事前処理し、テスト・システムを適切に準備したら、リプレイ・データを初期化できます。リプレイ・データの初期化では、必要なメタデータが、ワークロードのリプレイで必要な表にロードされます。たとえば、取得した接続文字列が、リプレイ用に再マッピング可能な表にロードされます。
リプレイ・データを初期化するには、次のようにINITIALIZE_REPLAY
プロシージャを使用します。
BEGIN DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY (replay_name => 'dec06_102', replay_dir => 'dec06'); END; /
この例では、INITIALIZE_REPLAY
プロシージャによって事前処理済のワークロード・データがdec06
ディレクトリからデータベースにロードされます。
この例のINITIALIZE_REPLAY
プロシージャでは、次のパラメータを使用します。
replay_name
: 以前のリプレイの設定およびフィルタを取得するために他のAPIで使用できるリプレイ名を指定する必須パラメータ。
replay_dir
: リプレイする取得済のワークロードを含むディレクトリを指定する必須パラメータ。
関連項目:
|
リプレイ・データを初期化したら、ユーザー・セッションが適切なデータベースに接続し、リプレイ時に取得される場合と同様に外部との対話を実行できるように、取得済のワークロードで使用されている接続文字列を再マッピングする必要があります。接続マッピングを表示するには、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
: ワークロードのリプレイ時に使用される新しい接続文字列を指定する必須パラメータ。
リプレイ・データを初期化し、接続を適切に再マッピングしたら、ワークロードのリプレイ用にデータベースを準備する必要があります。ワークロードのリプレイの準備については、「データベース・ワークロードのリプレイの手順」を参照してください。
リプレイ・システムでワークロードのリプレイを準備するには、次のように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
: ワークロードのリプレイ時に同期化を使用するかどうかを決定する必須パラメータ。
このパラメータをOBJECT_ID
(デフォルト値)に設定すると、関連するすべてのCOMMIT
アクションが完了するまで、すべてのリプレイ・アクションは実行されません。関連するCOMMIT
アクションは、次の条件を満たしている必要があります。
ワークロードの取得内の指定したアクションの前に発行されている。
指定したアクションが暗黙的または明示的に参照しているデータベース・オブジェクトが1つ以上修正されている。
このパラメータをOBJECT_ID
に設定すると、ワークロードの取得時に同じデータベース・オブジェクトを参照しないCOMMIT
アクションに関して、ワークロードのリプレイ時の同時実行性が向上します。
このパラメータをSCN
に設定すると、取得したワークロード内のCOMMIT
の順序がリプレイ時に保持され、すべてのリプレイ・アクションがすべての依存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; /
進行中のワークロード・リプレイを一時停止するには、次のように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; /
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スナップショットがまだ使用可能である場合にのみ、機能します。
この項では、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; /
関連項目:
|
この項では、ワークロードのリプレイを監視するために表示できるビューの概要を示します。これらのビューにアクセスするには、DBA権限が必要です。
DBA_WORKLOAD_CAPTURES
ビュー: 現在のデータベースで取得されたワークロードの取得をすべて示します。
DBA_WORKLOAD_FILTERS
ビュー: 現在のデータベースに定義されたワークロードの取得に使用されるワークロード・フィルタをすべて示します。
DBA_WORKLOAD_REPLAYS
ビュー: 現在のデータベースでリプレイされたワークロードのリプレイをすべて示します。
DBA_WORKLOAD_REPLAY_DIVERGENCE
ビュー: 違いのあるコールに関する情報(リプレイID、ストリームID、コール・カウンタなど)を表示できます。
DBA_WORKLOAD_REPLAY_FILTER_SET
ビュー: 現在のデータベースで定義されたワークロード・リプレイに使用されるワークロード・フィルタをすべて示します。
DBA_WORKLOAD_CONNECTION_MAP
ビュー: ワークロードのリプレイの接続マッピング情報を示します。
V$WORKLOAD_REPLAY_THREAD
ビュー: リプレイ・クライアントからのすべてのセッションに関する情報を示します。
関連項目:
|