System i スペシャリストが教えるV5 ちょっと、イイ話

データベース（以下DB）において複数CPUを使用したパラレル処理(並列処理)というと、QUERYなどの照会処理時間が短縮できる、と考えられると思います。

DB2 UDB for System i(以下DB2 for System i)では、インデックスの更新処理(索引処理)についてもパラレル処理が可能です。インデックスのパラレル処理を使用すると、インデックスの作成や更新処理等の更新系処理も、より高速に実行することができます。

DB2 UDB for System iでインデックスのパラレル処理を実行するには、前提ソフトウェアとして有料のOS/400オプション27 DB2マルチ・プロセス（SMPフィーチャー）が必要です。

図1は、インデックス作成においてパラレル処理を行なわない場合と、パラレル処理を行なった場合の比較例です。

DB2 for System iでは、パラレル処理のレベルを3段階に設定できます。図1はパラレル処理を最大化した例です。パラレル処理を行なうと、図1に示されるようにインデックス作成時間を大幅に短縮できることが分かります。インデックスはSQLで作成したもの、CRTLFコマンドで作成した論理ファイルのインデックスのどちらに対しても有効です。

インデックス作成のパラレル処理は、大規模DB環境でのパフォーマンス向上だけでなく、DB障害からのリカバリーを迅速にしたい要件に対しても非常に有効です。

インデックスのパラレル処理は、基になるテーブルを複数のデータ・セグメントに論理的に分割して行なわれます。その後、各プロセスが、各プロセスに割り当てられたセグメントのインデックスのキー値を構築します。次に、各プロセスにより実行された作業結果をマージして、最終的なインデックスが完成します。

インデックスの更新処理は、DBに対するレコード行の更新（挿入、変更、削除）結果をインデックス・キーに反映させるために必要です。例えば、受注ファイルと顧客マスターという2つのファイルがあり、どちらのファイルにも最新受注番号フィールドがキーとして定義されているとします。受注ファイルに新しい受注レコードが追加されると、受注ファイルのインデックス・キーの更新と、顧客マスターのインデックス・キーの更新という2つの更新処理が発生します。

複数の更新処理が発生する場合、デフォルト状態では受注ファイルのインデックス更新処理が実行され、次に顧客マスターのインデックス更新処理、というように一度に1ファイルずつ順番に更新処理が発生します。（この更新処理時間は、ユーザーから見た応答時間に含まれています。）インデックスのパラレル処理では、このような場合、2つのファイルのインデックスを同時並行的に更新することも可能です。その結果、トータルの処理時間を劇的に短縮できるケースもあります。
図2は複数のインデックスを持つ一つのテーブルに、数千万単位のレコードを新たにロードする場合の処理時間例です。インデックスのパラレル更新処理を行なうと、ロード時間を1/2 ? 1/3 に短縮可能なことが分かります。

DB2 for System iがインデックスのパラレル更新処理を行なうのは、以下の場合です。

• アプリケーションが8行以上のブロック挿入（またはブロック書き込み）を実行する場合
• 関連するテーブルに2つ以上のインデックスが定義されている場合

ブロック挿入は、バッチ更新処理、データウェアハウスのロード・プロセスなどで多用されるため、このような環境においてはインデックスのパラレル処理の効果を最大限に享受することができます。

パラレル処理をアクティブにするためのシステム値設定や、ジョブ単位でのパラレル処理のレベルの設定方法等、より詳細な情報があります。
以下のURLをご覧下さい。
http://www.ibm.com/jp/software/data/developer/library/techdoc/
parallel.html

英語の原文はこちら
http://www7b.boulder.ibm.com/dmdd/library/techarticle/0301milligan/
0301milligan.html（US）