管理の手引き


第 21 章 アーキテクチャーとプロセスの概要

DB2 のデータベース操作のパフォーマンスを処理する際には、 DB2 のアーキテクチャーとプロセスについての基本的な理解が必要になります。 この章では、 DB2 ユニバーサル・データベースの機能についての情報が十分に提供されています。 ここで説明されているトピックのいくつかは後の章で詳しく扱われますが、 この章にある情報は、後で理解するための背景として重要です。

最初の図に、DB2 UDB のアーキテクチャーとプロセスの概要を示します。

図 67. アーキテクチャーとプロセスの概要


ARCOVE

クライアント側では、 ローカル・アプリケーションやリモート・アプリケーションが、 DB2 ユニバーサル・データベース・クライアント・ライブラリーにリンクされています。

クライアントと DB2 ユニバーサル・データベース・サーバーの間には"雲"があります。 これは、ローカルまたはリモート・クライアントとサーバーとの間の通信を意味します。 ローカル・クライアントは、 共用メモリーおよびセマフォーを使用して通信します。 リモート・クライアントは、 名前付きパイプ (NPIPE)、TCP/IP、NetBIOS、IPX/SPX、または SNA などのプロトコルを使用します。

サーバー側では、アクティビティーはエンジン・ディスパッチャブル・ユニット (EDU) により制御されます。 この章のすべての図で、 EDU は、円または円グループとして示されています。 EDU は、 Windows NT および OS/2 (すべて単一プロセス内) ではスレッドとして、 UNIX ではプロセスとして実装されています。 最も一般的なタイプの EDU は、DB2 エージェントです。 これらの EDU は、アプリケーションに代わって大量の SQL 処理を実行します。 他の EDU としては、各種の入出力処理を実行する DB2 プリフェッチャーおよびページ・クリーナーがあります。 詳しくは、データベース・エージェントを参照してください。

それぞれのクライアント・アプリケーションには "調整エージェント" と呼ばれる固有の EDU が割り当てられます。 これは、アプリケーションの処理を調整し、アプリケーションと通信します。 また、クライアント・アプリケーション要求を処理するために割り当てられるサブエージェントのセットもあります。 サブエージェントは複数割り当てることができます。 こうすると、対称マルチプロセス環境のように、 サーバーが存在するマシンに複数のプロセッサーがある場合に、 クライアント・アプリケーション要求でこれらのプロセッサーを利用できます。

すべてのエージェントおよびサブエージェントは、 プール・アルゴリズムを使用して管理されます。 これにより、EDU の作成や破棄の数を最小限にとどめることができます。

バッファー・プールは、記憶域メモリーの 1 つのエリアであり、 ここで、ユーザー表データ、索引データ、およびカタログ・データが一時的に移動されたり、 あるいは変更されたりします。 データはディスクからよりもメモリーからの方がずっと速くアクセスできるため、 バッファー・プールは、データベースの全体のパフォーマンスに影響を与える主要なものとなります。 アプリケーションが必要とするデータのうち、バッファー・プールに存在しているものが多いほど、 データにアクセスしてディスク記憶装置からデータを見つけるのにかかる時間は短くなります。 詳しくは、データベース・バッファー・プールの管理を参照してください。

バッファー・プールの構成は、 プリフェッチャーおよびページ・クリーナー EDU と共に、 アプリケーションで必要なデータの可用性を制御します。

プリフェッチャーは、 データをディスクから取り出し、 アプリケーションがそのデータを必要とする前にこれをバッファー・プールに移動するために存在しています。 たとえば、データ・プリフェッチャーが存在しなければ、 大量のデータ全体を走査する必要のあるアプリケーションは、 データがディスクからバッファー・プールに移動するのを待機しなければなりません。 アプリケーションのエージェントは、 非同期読み取り先行要求を共通事前取り出し待ち行列に送信します。 使用可能になると、 プリフェッチャーは大きなブロックを使用してこれらの要求を実装するか、 または読み取り入力操作を分散させてディスクからバッファー・プールに要求されたページを移動します。 データベース・データの記憶域に複数のディスクがあれば、 データを複数ディスク間でストライピングすることができます。 このデータ・ストライピングにより、 プリフェッチャーは同時に複数のディスクを使用してデータを取り出すことができます。 詳しくは、バッファー・プールへのデータの事前取り出しおよび 事前取り出しおよび並列入出力を行うための入出力サーバーの構成を参照してください。

プリフェッチャーは、データをバッファー・プールに入れるために使用されます。 ページ・クリーナーは、データをバッファー・プールからディスクに戻すために使用されます。

ページ・クリーナーはバックグラウンド EDU であり、 アプリケーション・エージェントからは独立して、 バッファー・プールで必要でなくなったページを探して消去します。 ページ・クリーナーにより、 プリフェッチャーが取り出すページのスペースがバッファー・プール内に確保されます。

独立したプリフェッチャーやページ・クリーナー EDU がない場合には、 バッファー・プールとディスク記憶域との間のデータの読み書きすべてをアプリケーション・エージェントが実行しなければなりません。

複数のアプリケーションがデータベースからのデータを処理している場合には、 2 つ以上のアプリケーションの間で "デッドロック" が発生する可能性があります。 デッドロックについて、次の図に示します。

図 68. デッドロック検出機能


DDLOCK

"デッドロック" とは、 複数のアプリケーションが、別のアプリケーションがデータのロックを解放するのを待機している状況です。 待機しているアプリケーションのそれぞれが、 他のアプリケーションで必要なデータをロックして保持しています。 このロックされたデータが他の複数のアプリケーションで必要になっており、 同時に、それらのアプリケーションも他のアプリケーションで必要なデータを保持しています。 他のアプリケーションが保持しているデータを解放するのを互いに待機している状態がデッドロックです。 アプリケーションは、 "他の"アプリケーションが保持データのロックを解放するのを永久に待機する可能性があります。 他のアプリケーションは、自分の必要なデータを自発的には解放しません。 これらのデッドロック状況を断ち切るプロセスが必要になります。

この名前で示すとおり、 デッドロック検出機能は、 ロックを待機しているエージェントについての情報をモニターします。 デッドロック検出機能は、デッドロック状態のアプリケーションの 1 つを無作為に選択し、 この "志願した" アプリケーションが保持しているロックを解放します。 アプリケーションのロックを解放すると、 他の待機しているアプリケーションで必要なデータが使用可能になります。 これで、以前は待機中だったアプリケーションは、 データベースでアクションを実行するのに必要なデータを自由に使用できるようになります。

バッファー・プールでのデータ・ページの変更はログに記録されます。 ログ・バッファーが存在し、ロガー EDU に関連付けられます。 データベースにあるデータ・レコードを更新しているエージェントは、 バッファー・プールで関連するページを更新し、ログ・レコードを書き込みます。 ログ・レコードには、変更の再実行または取り消しに必要な情報が含まれています。 バッファー・プールのページも、 ログ・バッファーにあるログ・レコードも、 パフォーマンスを最適化するために即座にはディスクに書き込まれません。 ロガー EDU およびバッファー・プール・マネージャーが協働して書き込み先行ロギング (WAL) プロトコルを実装し、 関連するログ・レコードがログに書き込まれる前にデータ・ページがディスクに書き込まれないようにします。 WAL プロトコルを使用すると、 破損から回復し、データベース整合性を復元するのに必要な情報が確実に用意されることになります。 ページでの非コミット更新がディスクに書き込まれた場合、 破損回復では、関連するログ・レコードにある取り消し情報を使用して、更新を取り消します。 コミット更新がこれをディスクに作成しなかった場合、 破損回復では、関連するログ・レコードにある再実行情報を使用して、更新を再実行します。
注:COMMIT 時には、トランザクションにあるすべてのログ・レコードがディスクにフラッシュされます (まだフラッシュされていない場合)。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]