～オラクルコンサルタントが語る～

シンジ＆アヤノの
実践データベース性能テストの極意：
Oracle Real Application Testingを使ってみよう

第5回　DB Replayでサーバー統合をシミュレートしてみよう Capture編

第4回まではSPAの使用方法をお伝えしてきましたが、今回からはDatabase Replay(DB Replay)の使用方法とちょっとしたTipsをお伝えします。
第5回ではCaptureを第6回ではReplayに焦点を当てて、DB Replayを使用した負荷試験をお届けします。ただ負荷を掛けるだけでは面白みが無いので、今回は最近のバージョンで追加された「Consolidated Replay」*1を使用して、別々にCaptureされた2つのワークロードを同時にReplayして、サーバー統合時の負荷試験をシミュレートしてみたいと思います。
*1. Consolidated Replayとは…
Consolidated Replayでは複数のCaptureを同時にReplayすることができる機能です。通常のReplayと比較して一度に複数のCaptureを同時にReplayすることができるので、今回のケースのように、サーバー統合やジョブの追加をシミュレートすることができます。

※注意
本記事に記載している内容は、Oracle Enterprise Manager Cloud Control 12cを用いたReal Application Testing機能のおおまかな操作手順とその動作結果イメージを理解していただくことを目的としています。使用するOracle Enterprise Manager のバージョンによって、操作手順が異なることがあります。システムおよびパッケージの開発や実行環境で使用する際には、関連ドキュメントを参照の上、実施してください。また、本記事は単に情報として提供されるものであり、内容に誤りがないことの保証や弊社サポート部門へのお問い合わせはできませんのでご理解ください。

1. 今回使用する処理

Consolidated Replayをしてサーバー統合をシミュレートするために、今回は2つの擬似的なバッチ処理を用意しました。
それぞれのバッチ処理をEnterprise Managerの「トップアクティビティ」画面で確認した結果が下記のグラフとなりますが、どちらも前半はCPUを使用した処理が実行されており、後半はディスクI/O（「direct path read temp」と「direct path write temp」の待機イベントが出ており、Hash結合を実施している処理となります）が多い処理が流れていることが分かります。

これら２つの処理を同時に実行することで、全体の負荷がどのようになるか、またそれぞれのジョブの実行時間がどのように変化するかを、次回のReplay編で確認します。

各処理の実行時間は下記のとおりとなります。

コラム：Consolidated Replayを使用する為の条件 シンジ 今回、Consolidated Replayを使用しようとしているけど、何か使うために必要な条件ってあるの？ アヤノ Consolidated Replayはデータベースのバージョンに制限があるので、注意してくださいね。11.2.0.3以降＋RATバンドルパッチ、または12cが必要です。 シンジ なるほど、 EMでは特に気にすることはない？？ アヤノ （おおっ、さすがシンジ。鋭い！）EMのバージョンにも気をつけなくちゃいけなくて、今最新の12.1.0.4以上かつデータベースのプラグインが必要なんです。 シンジ ふむふむ、やっぱりアヤノはDBReplayのことよく知ってるな～。 じゃあついでに、Consolidated Replayを使う際に追加のライセンス費用がかかるかどうかも教えて欲しいなー。 アヤノ (うっ！！) ライセンスですか。。。 えっと。。。 あの～。。。(どうしよう。知らないって言ったら、シンジの期待を裏切ってしまう。。。) まぁそれはわたしが答えるより、製品担当のオバタさんに聞いてみたらいいんじゃないですか～？ シンジ (あ・・なんかいけないこと聞いちゃったかな。。) うん、そうだね！       ※Consolidated Replayを使用するのに追加ライセンスは不要です

2. ワークロードのCapture

DB ReplayのワークロードのCaptureは決して難しい作業ではありません。また2つのジョブをCaptureする必要がありますが、今回の記事ではCaptureの全体観を理解して頂くために、1つの処理ワークロードをEnterprise Managerを使用してCaptureした際の動作を説明します。

※本記事ではCapture作業をイメージしていただくことを目的としており、一部のEnterprise Managerでの作業は割愛しております。

Enterprise Managerのツールバーにある「Enterprise(E)」から、「クオリティ管理」にマウスカーソルをあわせ、「データベース・リプレイ」をクリックし、データベースリプレイ画面へ移動します。

「作成」をクリックし、前提条件に合意した後にワークロードを取得する対象のデータベースを追加します。

Captureする時にSPAを同時に取得するか、またフィルタを変更するかを指定します。

ジョブの発行タイミングを決定します。

一連の設定内容を確認して、ジョブを発行しCaptureを開始します。

ジョブが正常終了したことを確認すると、Capture処理は終了となります。

コラム：DB Replayを使用する際は「In-flight Transaction」に注意！ シンジ Captureを開始した時点ですでに実行中だったトランザクションってどうなるの？ アヤノ (よし、ここで名誉挽回っ！！) それはですね！ In-flight Transactionって呼ばれていて、Captureすることが出来ないんです。だからCaptureする前にはCapture対象の処理が流れていないことを確実に保証する必要があって、最もよいのはデータベースを再起動することだけど、商用環境ではなかなか難しいから、時間帯やv$session/v$transaction等を確認して、Capture対象の処理が流れる前にCaptureを開始することが大切になんです！（・・ふう、どうだ。） シンジ なるほど、そうなのかー。 さすがアヤノ！ アヤノ (よ～～し、やった！！) いやいやそうでもないですよ。

3. まとめ

今回は擬似的なジョブの追加のCapture部分のみとなります。次回はついにConsolidated Replayを使用して2つのワークロードをいっきに流し、サーバー統合をシミュレートしてみたいと思います。

アヤノ	次回は、ついにConsolidated Replayを使用して結果を見ることが出来ます！
シンジ	おぉー、楽しみー♪

次回は、「第６回　DB Replayでサーバー統合をシミュレートしてみよう Replay編」です。 是非ご覧ください。

<< 第4回へ戻る　I　第6回へ進む >>

>> 連載トップページに戻る