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

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

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

最終回である今回は第5回で取得した2つのワークロードをConsolidated Replay機能を使用して同時に実行することでサーバー統合をシミュレートしてみたいと思います。

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

1. Replay結果

今回のReplay結果は下記の通りとなりました。結果から、ジョブ１とジョブ2は同時に実行しても大きな差は発生しないことが分かります。

Consolidated Replay時の負荷

上記のEnterprise Managerの画面から、ジョブを同時実行した際は、CPU負荷が倍になっていることがわかります。また前半のCPUを使用している時間帯は衝突し負荷が高くなっていますが、後半のI/Oを使用している時間帯は多少ずれて実行されていることが分かります。 I/Oを多く発行する処理の方が実行時間としては長いため、全体的な実行時間としては大きな差が出ていません。
これ以上の分析は本連載のスコープから逸脱するため割愛しますが、実際の案件ではなぜこのような結果となったかをOS/DB/APの観点から詳細に分析しサーバーを統合した際の影響を確認します。

コラム：RAC環境でDB Replayを使う際の注意 シンジ 今回の記事ではシングルデータベース環境でReplayデモを実施していますよね～、でも実際の商用環境ではRACデータベースも多いと思いますが、RAC環境で特に何か注意すべき点は有りますか？ アヤノ （流石、シンジ…運用試験の経験からして気がつくところが鋭い）そうですね～。RACデータベース環境でReplayを実施する際は、Replay用のファイルを全てのノードから参照出来る必要がありますね～。 シンジ ほ～～、では共有ディスクが必ず必要になると思っておいた方がいいってこと？ アヤノ 相変わらず鋭いご指摘、ありがたい！！ その通りです。何らかの共有ディスクが必要となります。例えばOracleが提供しているZFSストレージであったり、DBFSといった共有ストレージを使います。あっ、それらを使う際のライセンスは製品担当のオバタくんについでに聞いてみましょう！！ シンジ (やられた…) なるほど！！！流石アヤノ 。(ライセンスで攻めれないじゃん！！) アヤノ (危ない危ない…)

2. ワークロードのReplay方法

DB ReplayのワークロードのReplayはCapture同様に難しい作業ではありません。ただし、今回はConsolidated Replayを実施しているため、多少の追加作業が必要となりますので、基本操作と追加部分を順を追って説明いたします。

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

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

「リプレイ・タスク」タブをクリックし、「作成」をクリックすると下記のような画面となるので、Consolidated Replayを実施する際は同時に流すワークロードのチェックボックスをチェックします。データベースのログイン情報等を入力して「発行」をクリックします。

リプレイ・タスクに作成したタスクが追加されているのを確認し、リンクをクリックします。

遷移した画面で、リプレイ・タスクに紐づくリプレイ情報が確認できますが、リプレイ・タスクを作成した直後なので、何もリプレイがないことを確認し、「作成」をクリックします。
その後、Replayの環境情報を幾つか入力すると、Replayを実施するうえで必要な作業を表す画面に遷移します。

今回実施した作業は「ワークロードの事前処理」、そして「ワークロード・リプレイ」となります。実際はデータベースの準備が重要ですが、今回はテストなので同一データベースに対して処理を流しています。
ワークロードの事前処理は画面に従って進むので割愛します。

ここまででReplayの準備が完了したので、先ほどのメニュー画面の「ワークロード・リプレイ」をクリックして実際にReplayを実行します。

まずはReplay処理が実行される対象のデータベース情報を入力します。

先ほどの「ワークロードの事前処理」で実施した事前処理後のワークロードが格納されているディレクトリを指定します。その後リプレイオプションを指定した後に、リプレイクライアントの設定に移ります。

リプレイクライアントの設定画面で「作成」をクリックして、下記のように必要な情報を記載します。情報を元に必要なリプレイクライアントの数が計算されますので、それに合わせたリプレイクライアントが起動されることを確認します。

そして最後にReplayタスクを発行することでReplayが実行されます。

コラム：Web記事連載をおえて…　 アヤノ シンジ！ 今回は６回にわたり記事連載をご一緒出来て良かったです！ シンジ 私もですよ～。ご一緒出来て楽しかったです！どうですか？記事連載終了の慰労会として今夜一杯でも！ アヤノ あっ！いいですね～♪ 是非！！！っと言いたいのですが… 私今月自分へのご褒美に色々と買ってしまい、金欠なので… シンジ (良い先輩になるチャンスだな！)　そんなことですか！ 気にしないでください。お礼に私がおごりますよ。どこでも言ってくださいね！！ アヤノ (キラッ) え～～～本当ですか？？ ではOAC(Oracle 青山センター)の下にある 素敵なレストランに行きたいです！！製品担当のオバタさんも誘いましょうよ～。 シンジ いいですね！ 行きましょう！(あそこ結構高いんじゃなかったけ… 最後まで アヤノに翻弄されているな…俺)

3. まとめ

ここまでの全連載6回、いかがでしたでしょうか？SPA、DB Replayとその利用方法について紹介してきました。連載記事にここまでお付き合いいただきました読者の皆さま、ありがとうございました！

アヤノ	テストツールって準備が大変なイメージでしたけど、RATはEMの画面から実施できるのがとても簡単でしたね！
シンジ	実際にRATを利用することで、かなりの作業工数が削減できそうですね！

また最後に、この場をおかりして記事連載に関わっていただきました社内関係者の皆さま、ありがとうございました。
レビュー担当　製品担当 オバタさん、ナカジマさん
レビュー担当　テストツールコンサル　カワモトさん、イトウさん
写真担当　セキュリティコンサル　チャエンさん

<< 第5回へ戻る　 I 　連載トップページに戻る >>