 |
Oracle Database 11g：
DBAと開発者のための主要な新機能
by Arup Nanda
|
Database Replay
Database Replayは、データベース・ワークロードをすべて取得し、自由に"再現"できるOracle Database 11gの優れた新しいツールです。ここでは、Database Replayの使用方法を学習します。
データベースの変更（初期化パラメータやデータベース属性の変更といったわずかな変更から、パッチセットの適用といった必須の変更まで）をおこなう上で、最大の問題とは何でしょうか。Oracle Database 11gへのアップグレードについてはどうでしょうか。
最大の問題は、変更によって何かが破損するリスクです。わずかな変更でも連鎖反応によって明らかな影響が生じる可能性があります。
このリスクを最小限に抑えるには、本番環境と同様に制御可能な環境で変更をおこない、本番システムと同様のワークロードを適用して影響を確認する場合がほとんどです。本番システムを技術的にレプリケートすることは簡単ですが、ワークロードの再現は別問題です。まさに、"言うは易しおこなうは難し"なのです。
多くの企業は、実際のユーザー・アクティビティを自動的にシミュレートできるサード・パーティ製のロード生成ツールを使用し、この処理を行います。ほとんどの場合においてこの方法は有効ですが、本番データベースのワークロードが忠実に再現されるわけではありません。これらのサード・パーティ製ツールは、事前に記述された問合せを異なるパラメータで何度も実行するだけです。ツールに問合せとともに、ランダムに使用できる一連のパラメータを引き渡しても、これは本番システムの代表的なワークロードではなく、一部の本番ワークロードを何度も実行しているに過ぎません。この結果、アプリケーション・コードの1%しかテストできません。また、これらのツールは、本番ワークロードのすべての問合せを要求するため、小規模なアプリケーションで数週間から数ヶ月、複雑なアプリケーションでは1年を要する場合があります。
データベース内部のすべてのデータベース操作（DML関連など）を記録して、発生した順番に忠実に再生することができるなら、効率的ではないでしょうか。
Database Replayの概要
Oracle Database 11gを使用するとこの目的が達成され、それ以上の恩恵も得られます。新しいDatabase Replayツールは、データベース内のDVR（デジタル・ビデオ・レコーダー）のように動作します。独自の方法を使用して、データベース・アクティビティをすべてバイナリ形式で忠実に取得し、同じデータベースまたは異なるデータベースで再生します。また、取得プロセスをカスタマイズして、特定のタイプのアクティビティを挿入または除外することもできます。
Database Replayは、Oracle Database 11gの"Real Application Testing"オプションの半分を提供します。もう半分は、別のツールのSQL Performance Analyzerによって提供されます。
2つのツールのおもな違いは、その対象範囲です。Database Replayは、データベースの（フィルタリングした）アクティビティをすべて取得・再生し、SQL Performance Analyzerは、特定のSQL文を取得して再生します（Database Replayで取得した特定のSQLは参照・アクセスできませんが、SQL Performance Analyzerではそれが可能です）。つまりアプリケーションが発行したSQL文を微調整してその影響を評価できるため、SQL Performance AnalyzerはSQLチューニングに大きな利点をもたらします。
Database Replayは、概念的には以下の図のような順番で動作します。
- データベースのアクティビティを記録する取得プロセスを開始します。
- 取得プロセスは、/capture directory/と呼ばれるディレクトリの"取得ファイル"という特殊なファイルにアクティビティを書き込みます。
- その後、取得プロセスを停止し、これらの取得ファイルをテスト・システムの/replay directory/と呼ばれるディレクトリに移動します。
- 再生プロセスと複数の再生クライアントを開始して、これらのすべての取得ファイルを再生します。
- 取得ファイルは、テスト・データベースに適用されます。
では、サード・パーティ製のツールが提供しないDatabase Replayの機能とはどういったものでしょうか。まず、他のツールは、提供した複数の合成SQL文を再生するだけです。それに対し、Database ReplayはSQL文を提供する必要がありません。データベース・アクティビティをすべて取得するので、パフォーマンスの問題の原因となる主要な操作を欠落するリスクがありません。
また、特定のユーザーやプログラムなどに応じて選択して取得でき、ワークロードを取得する期間まで指定できます。データベース全体ではなく、問題が発生している特定のワークロードを再生することができます。
たとえば、月末の利子計算プログラムで問題が発生し、パラメータを変更すればプロセスが簡素化されるとします。実行する作業は、月末プログラムを実行中のワークロードを取得し、テスト・システムでパラメータの変更をおこなって、そのシステムで取得ファイルを再生するだけです。パフォーマンスが向上すれば問題は解決しますが、パフォーマンスが向上しなくても、テスト・システムなので影響ありません。本番データベースの操作を妨げることはありません。
このツールだけでも、Oracle Database 11gにアップグレードする価値があります。
次に、このツールの動作を説明します。
ワークロードの取得
最初のタスクは、データベースからのワークロードの取得です。
コマンドラインまたはOracle Enterprise Manager Database Controlですべてのタスクが実行できますが、ここではOracle Enterprise Manager Database Controlを使用します。
- 取得したワークロードは、ファイルに保存されます。このファイルを保存するディレクトリは空にする必要があります。ディレクトリが存在しない場合は、それを作成することが最初のタスクになります。この例では、/home/oracle/dbcaptureというディレクトリを作成します。
$ cd /home/oracle
$ mkdir dbcapture
- データベースにこのディレクトリ用のディレクトリ・オブジェクトを作成します。
SQL> create directory dbcapture as '/home/oracle/dbcapture';
Directory created.
- これで、取得を開始できます。実際の例として、多くのINSERT文を生成してTRANS表に挿入する簡単なテスト例を作成します。
create table trans (
trans_id number,
cust_name varchar2(20),
trans_dt date,
trans_amt number(8,2),
store_id number(2)
)
/
有効なPL/SQLコードの断片を以下に示します。
1,000の挿入文を生成して実行します（1,000の異なる挿入文を生成するのであって、同じ文またはプログラムで1,000回挿入するわけではありません）。
declare
l_stmt varchar2(2000);
begin
for ctr in 1..1000 loop
l_stmt := 'insert into trans values ('||
trans_id_seq.nextval||','||
''''||dbms_random.string('U',20)||''','||
'sysdate - '||
round(dbms_random.value(1,365))||','||
round(dbms_random.value(1,99999999),2)||','||
round(dbms_random.value(1,99))||')';
dbms_output.put_line(l_stmt);
execute immediate l_stmt;
commit;
end loop;
end;
上記の内容でファイルを作成するだけで、実行はしないでください。このファイルをins_trans.sqlとします。（上記のすべての手順は、学習用です。ディレクトリ・オブジェクト以外、本番の操作では必要ありません。）
- 実際には、異なるデータベースで再生を実行しますが、ここでは同じデータベースをフラッシュバックしてそこでアクティビティを再生します。GOLDと呼ばれるリストア・ポイントを作成して、この場所をマークします。
SQL> create restore point gold;
これで、取得を開始できます。Oracle Enterprise Manager Database ControlでDatabase Replayメイン・ページへ移動します。Homeページから、「
Software and Support」を選択します。
- Real Application Testingの下の「
Database Replay」をクリックして、
Database Replayページ（以下を参照）を起動します。
- 左側の枠で一連のアクティビティを確認できます。
Task 1: Capture Workloadの「
Go to Task」アイコンをクリックして、最初のアクティビティを選択します。
- 次の画面では、取得プロセスを開始する前に確認する必要がある3つの前提条件が表示されます。
- ワークロードの取得が開始される際、現在のデータベースがそのSCNまで再生システムでリストアできること
- 取得したワークロードを保持する十分なディスク領域が存在すること
- ワークロードの取得を開始する前にデータベースを再起動できる状態であること
- 確認ができた項目のチェック・ボックスをチェックします。
- 「
Next」をクリックします。
- 次の画面には、2つの異なるアクション項目があります。取得プロセスの前にデータベースを再起動する場合に選択する2つのラジオ・ボタンが画面の上部に表示されます。
取得プロセスを開始する際、一部が取得されない可能性のある実行中のトランザクションが存在することがあります。データベースを再起動すると、これら実行中のトランザクションは無効になり、この"ノイズ"はクリアされます。また、データベースを再起動すると、テスト・システムでリストアするクリーン・バックアップが提供されます。これによって、本番システムと同じSCN番号を持つシステムでアクティビティを再生できます。
このような理由（特に最初の理由）から、オラクルは取得前にデータベースを再起動することを推奨しています（こちらがデフォルトで選択されています）。ただし、再起動しなくても構いません。再起動しない場合は他のラジオ・ボタンを選択してください。
- 画面の下部は、以下のように表示されます。
-
次に、取得プロセスが使用するフィルタを記録し、アクティビティを取得します。
デフォルトで2つのフィルタがあります。Oracle Management Serviceのすべてのアクティビティを除外するフィルタとOracle Management Agentのすべてのアクティビティを除外するフィルタです。
なお、フィルタを追加することもできます。たとえば、すべてのPerlプログラムを除外するフィルタを追加するには、「
Add Another Row」をクリックし、"Filter Name"および"Value"フィールドにそれぞれ"perl"と"%perl%"を入力します。同様に、デフォルトのパラメータの小さなミスを訂正します。Oracle Management Agentフィルタの値は、"emagent%"ではなく"%emagent%"にする必要があります。
また、すべてのSYSユーザー・アクションを除外すると仮定します。Session Attributeドロップダウン・ボックスから「
USER」を選択し、"Value"列にSYSと入力する必要があります。
- 「
Next」をクリックします。以下のような画面が表示されます。
- この画面で、取得ファイルが格納されるディレクトリ名をドロップダウン・ボックスから選択します。ここでは、DBCAPTUREディレクトリを使用しています。前の手順でこのディレクトリを作成していない場合、「
Create Directory Object」をクリックして作成できます。「
Next」をクリックします。
- 次の画面で、実行する時間などジョブの詳細を参照します。「
Immediate」ラジオ・ボタンを選択して直ちに実行します。
- OSユーザー名、SYSパスワードなど、ページ内の項目の詳細を設定して、「
Next」をクリックします。
- 次の画面（"Step 5 of 5"）には、ジョブ名や除外フィルタなど、入力したすべての情報が表示されます。すべてが設定したとおりであれば、「
Submit」をクリックします。それ以外の場合は、戻って変更を行うことができます。
- 「
Submit」を押すと、ワークロードの取得が開始され、以下のような確認画面が表示されます。
ステータスが"In Progress"になっていることに注意してください。
- ワークロードが取得されるので、SQL*Plusプロンプトからシミュレーション・ワークロードを実行します。実際のシステムでシミュレーションを実行する必要はありません。すべてのワークロードを取得するため、しばらくの間、キャプチャ処理を実行します。
SQL> connect arup/arup
SQL> @ins_trans
これによって、TRANS表への1,000の挿入文が実行されます。
- ワークロードが完了した後、上の画面に示されている「
Stop Capture」ボタンをクリックすると、確認が求められます。
- Oracleは、ワークロード取得の前後にAutomated Workload Repository（AWR）スナップショットを自動的に取得します。次の画面で、AWRデータをエクスポートするかどうかが求められます。以下の画面のように、異なるシステムで再生してこのデータベースからターゲット・データベースにAWRデータをエクスポートする場合、この操作は重要です。「
Yes」をクリックします。
- これによって、AWRをエクスポートするスケジューラ・ジョブが作成されます。ジョブが
Runningタブからなくなるまで、ジョブ名をクリックしてステータス画面をリフレッシュします。
これで、/home/oracle/dbcaptureディレクトリのファイルにワークロードを取得できました。
前処理
取得したワークロードを再生します。通常、別のテスト・システムで再生します。このため、/home/oracle/dbcaptureディレクトリのファイルを新しいホストにコピーする必要があります。ファイルをコピーする前にディレクトリが空であることを確認してください。学習のために、ここでは同じデータベースで再生をおこないます。
再生する前に取得したワークロードの前処理を実行する必要があります。前処理によって、取得したこれらのファイルを再生できます。
- Database Replayメイン・ページに移動します。
- 「
Step 2: Preprocess Workload」を選択します。
- ドロップダウン・リスト・ボックスからディレクトリ・オブジェクトを選択します。取得したワークロードが表示されますので、ここではDBCAPTUREを選択します。ディレクトリ・オブジェクトを作成していない場合、適切なボタンをクリックしてディレクトリを簡単に作成できます。
- 「
Preprocess Workload」をクリックします。
- 次のページでは、Job Nameと関連するホスト・ユーザー名やパスワードなど、詳細情報の設定が求められます。特定のJob Nameを使用しない限り、デフォルトのままとします。このジョブをすぐに実行する選択を行います。ホストのユーザーIDおよびパスワードはすでに表示されています。表示されていない場合、適切な値を入力して、「
Submit」をクリックします。
- 次のページで、確認内容とJob Statusを参照するリンクが表示されます。リンクをクリックします。
- ステータスが"Succeeded"になるまで、この画面をリフレッシュします。
ワークロードの前処理が行われたので、再生を実行できます。
再生
ワークロードが取得されて前処理が実行された後、テスト・データベースでワークロードを再生できます。今回は学習を目的として、同じデータベースでワークロードの前処理を実行しましたが、アクティビティの再生にも同じデータベースを使用します。実行するには、データベースを起点に再設定する必要があります。取得プロセス中に作成したGOLDリストア・ポイントにフラッシュバックして、簡単にこの処理を実行できます。
SQL> shutdown immediate;
... database shuts down ...
SQL> startup mount
... instance starts and mounts the database ...
SQL> flashback database to restore point gold;
... database will be flashed back ...
SQL> alter database open resetlogs;
... database is opened ...
これで、ワークロードを開始する前のポイントに戻ったので、先に取得したワークロードを再生できます。以下の手順を実行して、ワークロードを再生します。
- Databaseホームページから"Capturing"の項に示されているDatabase Replayメイン画面へ移動します。
- メニューから「
Step 3: Replay Workload」を選択すると、Replayメイン画面が表示されます。
- ディレクトリを選択するドロップダウン・ボックスが表示されます。再生ファイルを配置したディレクトリを選択します。これは、実際のUNIXディレクトリではなくディレクトリ・オブジェクトです。先の例でDBCAPTUREディレクトリ・オブジェクトを使用したのでそれを選択します。まだディレクトリを作成していない場合は、「
Create Directory」をクリックしてディレクトリ・オブジェクトを作成します。
- 右上隅の「
Setup Replay」をクリックします。
- 次の画面には、発生する処理に関する情報のリストが表示されます。これらの各情報項目の詳細は、以下のとおりです。
-
- 「
Continue」をクリックすると、次のような画面が表示されます。
ページに表示されたリンクをクリックして、参照されていないすべてのパラメータを変更できます。いずれかをクリックするとDatabase Replayページから離れるので注意してください。 （SQL*Plusで個別に変更することを推奨します。）「
Continue」をクリックします。
- Replay Nameと入力するか、デフォルトのままとします。
- 次の画面には、データベース・リンクやディレクトリなどへの未解決の参照による潜在的な問題が表示されます。
画面の右側で再生システムへの変更を任意で行うことができます。なお、この例では同じデータベースで実行しているので、この手順は必要ありません。
- 「
Next」をクリックすると、以下のような画面が表示されます。
この画面は、再生プロセスが再生クライアントを待機していることを示します。再生クライアントは、Database Control画面の外部から実行されます。これらは、取得したワークロードを読み取って再生するクライアント・プログラムです。プログラム名はwrcです。（UNIXおよびWindowsシステムで共通。）再生クライアントを開始するには、UNIXプロンプトへ移動して次の行を実行する必要があります。
$ wrc userid=system password=* replaydir=/home/oracle/dbcapture
SYSTEMの正しいパスワードを入力する必要があります。取得したファイルを異なる場所に保存した場合、ディレクトリ名を変更してください。次のメッセージが返されます。
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Sep 4 19:50:44 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Wait for the replay to start (19:50:44)
この時点で、再生クライアントは再生ガバナー（Database Control）による起動を待機します。複数のクライアントを起動して並行してワークロードを処理できます。
- Database Control画面にすぐに移動します。画面が変更されて、再生クライアントの接続が 表示されます。接続元のホスト名やOSプロセスIDなどが表示されます。
- 「
Next」をクリックし、次に「
Submit」をクリックして再生プロセスを開始します。UNIXセッションに移動する場合、追加のメッセージ（"Replay started (01:49:56)"）が表示されます。現在のデータの処理量を示すプログレス・バーが画面に表示されます。
- この後、UNIXセッションで"Replay finished (01:50:35)"が表示されます。この時点でDatabase Control画面を確認すると、次のような画面が表示されます。
- これは、再生ジョブの詳細なステータスを示しています。左上の主要なフィールドの"Status"に、ジョブが完了したことを示す"Completed"が表示されます。
- これで実行を分析できます。画面の下部の"Comparison"の見出しの下にメトリックスが表示されます。この例では、再生が取得時間の39.08%で完了したことを示しています。実装した変更に効果はあったのでしょうか。
必ずしもそうとは限りません。次のメトリックスにおいて取得の割合が180％となっているDatabase Timeを見てください。詳細は、「
Report」タブをクリックしてください。次の画面が表示されます。
- この画面は、レポートのさまざまなオプションを示しています。もっともシンプルな
ワークロード・レポートを開始します。このレポートはパフォーマンスを比較しませんが、"相違"（再生でどれだけデータが異なるか）を示します。たとえば、ID3のレコードを使用し、更新された後で削除したとします。再生中にまず削除され、それから更新されると相違とみなされます。相違が少ないほど、再生の正確性が高くなります。
- ここで終わりではありません。明確な分析には、取得および再生の最中に以下に示されているAWR Compare Period Reportを調査して、ラッチ競合、ロック、REDO生成、consistent getsなど、他の多くのメトリックスの相違を確認します。これによって、変更の影響をさらに明確に把握できます。
このレポートは、取得と再生のロードの相違を示しています。再生中の物理的な書込みと読み取りは、それぞれ取得中の367%と111%に増加しました。ソートや論理読み取りなどの他のパラメータも大きくはありませんが増加しました。これによって、変更が行われるとパフォーマンスが低下することがわかります。
ユースケース
データベース・パラメータの変更 - 次のシナリオを検討します。
db_file_multiblock_read_countパラメータのデフォルト値を16から256に変更する予定です。256は適切な値でしょうか。128に設定したほうがよいでしょうか。あるいは、64や32の値が適切でしょうか。選択は限られますが影響には限りがありません。
値を変更するとオプティマイザに重大な影響を与えるので、ある問合せをサポートするものが他の100の問合せを損なう可能性があります。パラメータの最適な値をどのように決定すればよいでしょうか。
この場合、Database Replayが非常に有効です。本番システムからワークロードを取得し、取得したロードを異なるテスト・システムに移動します。db_file_multiblock_read_countを32に設定して、ワークロードを再生します。
次に、元の状態にデータベースをフラッシュバックし、値を64に設定して、同じワークロードを再生します。パラメータに使用できるすべての値でこのサイクル（フラッシュバック、値の設定、取得したロードの再生）を再実行できます。再生ごとに再生の前後のAWRレポートを実行して比較します。全体的に最適な結果を生成するパラメータの値を選択できます。Database Replayを使用しなければ、最適な値を決定することはできないでしょう。
OSのアップグレード - OSをアップグレードするか、小規模なパッチを適用してI/O問題を修正する予定です。何も損なわずに他の問題を発生させないことを保証するにはどうすればよいでしょうか。ワークロードを取得してパッチが適用されたテスト・システムで再生するだけで済みます。この方法は、カーネル・パラメータの変更にも適用されます。
パッチの適用 - たとえば、バグを検出しそれに対応するパッチが存在するとします。ただし、既存の操作に対する影響がわかりません。あなたと組織に従事する1,000人が発見した情報を提供する方法もありますが、Database Replayが解決してくれます。
デバッグ - 予期しない結果を生成する厄介なプログラムが常に存在します。しかし、Database Replayのデバッグは非常に簡単です。プログラムの実行中にワークロードを取得し、新しいシステムへ移動し、プログラム・ロジックを変更してデバッグ情報を配置します。さらに、ワークロードを再生し、出力を分析すればうまくいきます。最初にうまくいかなくても、落胆しないでください。ソリューションを発見するまで、プロセスを繰り返してください。（再生以降の処理であり、取得を再実行する必要はありません。）
オブジェクトの変更 - 索引を追加するか、Bツリーからビットマップに索引を変換します。INSERT文への影響はどこでどのように発生するでしょうか。推測せずに、取得したワークロードをテスト・システムで再生してみてください。
データベースのアップグレード - これは変更の保証に関して非常に困難な目標です。Oracle Database 11gにアップグレードする時が来ました。すべてのアプリケーションが正常に、あるいはさらに効率的に動作するかが重大な問題です。Oracle Database 10gからワークロードを取得して、Oracle Database 11gで再生してください。新しいバージョンの合成トランザクションをテストするのではなく、アプリケーションが日常的に使用する完全に同一のSQLをテストします。計画どおりに進まない場合、結果に納得するまで新しいシステムで調整してください。
（注：この原稿の執筆時点でOracle Database 10gからのワークロードの取得はサポートされていません。この機能は、Oracle Database 11gの今後の製品バージョンで使用可能になる予定です。）
プラットフォームの変更 - SolarisからHP-UXへ、ファイル・システムで非同期I/Oを使用できないデータベース・プラットフォームに移行する場合について検討します。パフォーマンスは同じでしょうか。Solarisからワークロードを取得してHP-UXで再生してください。
Oracle Real Application Clusters（RAC）への変換 - これは一般的な質問です。単一のインスタンスからRACインスタンスにデータベースを変換する予定です。アプリケーションは同じように動作しますか。回答を得る唯一の方法は、実際のワークロードを実行して取得し、RACデータベースで再生することです。
結論
変更は簡単ではありませんがそれほど難しくもありません。エンド・ユーザーが新しいDatabase Replayツールを使用してシステムに配置したアクティビティを取得し、テスト・システムで再生して変更の影響を正確に評価すると、多くのリスクを緩和できます。すべての処理が少しのマウス・クリックとキー・ストロークで済みます。パフォーマンスだけではなくアプリケーションの機能もテストできることを覚えておいてください。
Back to "Oracle Database 11g: Top Features for DBAs and Developers" homepage
Arup Nanda (
arup@proligence.com)氏は、Oracle Databaseテクノロジー全般に関し12年以上の経験を持つOracle DBAであり、2003年にOracle Magazineによる「DBA of the Year」を受賞。
Oracle ACE Directorでもあり、オラクル関連のイベントにしばしば講演者として招かれている。「
RMAN Recipes for Oracle Database 11g: A Problem Solution Approach」など4冊の本を共同執筆しているほか、雑誌への寄稿も多数。
|
Articles
Printer View