管理の手引き


データベース・エージェント

DB2 サーバーは、 データベース・マネージャーとクライアント / ローカル・アプリケーションとの間のコミュニケーションを支援しなければなりません。 UNIX ベースの環境では、 プロセス を基本とするアーキテクチャーを使用します。 たとえば、DB2 コミュニケーション listener はプロセスとして作成されます。 OS/2 および Windows NT などの Intel オペレーティング・システムでは、 スレッド を基本とするアーキテクチャーを使用して、 パフォーマンスの最大化を図ります。 たとえば、DB2 コミュニケーション listener は、 DB2 サーバーのシステム制御装置プロセス内にスレッドとして作成されます。 アクセスされる各データベースごとに、さまざまなプロセス / スレッドが開始されて、 各種のデータベース・タスク (たとえば、事前取り出し、コミュニケーション、 ログ記録など) を処理します。

非常に重要なプロセス / スレッドの 1 つに、 データベースに関するアプリケーションの操作を支援するデータベース・エージェントのプロセス / スレッドがあります。

論理エージェント は、 データベース・マネージャーに接続されたアプリケーションを表します。 論理エージェントには、 アプリケーションに必要なすべての情報と制御ブロックがあります。 論理エージェントの最大数は、 データベース・マネージャー構成パラメーター max_logicagents により制御されます。 アプリケーションごとに 1 つの論理エージェントがあるので、 このパラメーターは、 インスタンスに接続できるアプリケーションの最大数を制御します。

作業エージェント は、 アプリケーション要求を実行しますが、 特定のアプリケーションに永続的に接続されるものではありません。 作業エージェントには、 アプリケーションが要求したデータベース・マネージャー内のアクションを完了するのに必要なすべての情報と制御ブロックがあります。

作業エージェントには、4 つのタイプがあります。 活動状態の調整エージェントサブエージェント非活動状態のエージェント 、 およびアイドル・エージェント です。

アイドル・エージェントは、 最も単純な形式の作業エージェントです。 このエージェントは、論理エージェントに結合されておらず、 アウトバウンド接続もありません。 また、ローカル・データベース接続も、インスタンス接続もありません。

非活動状態のエージェントは作業エージェントの一形式であり、活動状態のトランザクションにはありません。 このエージェントは論理エージェントに結合されておらず、アウトバウンド接続もありません。 また、ローカル・データベース接続も、インスタンス接続もありません。 非活動エージェントは自由に別の論理エージェントと結合され、 その論理エージェントによって表されるアプリケーションの提供を開始します。

クライアント・アプリケーションの各プロセス / スレッドにはそれぞれ、 データベース上で稼働する活動状態の調整エージェント が 1 つあります。 調整エージェントが作成されると、 そのエージェントが、アプリケーションに代わって、 すべてのデータベース要求を実行し、さらに、 プロセス間コミュニケーション (IPC) およびリモート・コミュニケーションのプロトコルを使用して、 他のエージェントとコミュニケーションします。 各エージェント・プロセスは自らの私用メモリーを使って操作を行いますが、 データベース・マネージャーおよびデータベース大域リソース (バッファー・プールなど) は他のエージェントと共用します。 トランザクションが完了すると、 活動状態の調整エージェントは論理エージェントから切り離され、 非活動状態のエージェントとなります。

区分データベース環境、および区画内並行処理が使用可能になっている環境では、 調整エージェントはデータベース要求をサブエージェント に分配し、 それらのサブエージェントがアプリケーションの要求を実行します。 調整エージェントが作成されると、このエージェントは、 データベースへの要求を実行するサブエージェントの調整を行うことによって、 アプリケーションに代わってすべてのデータベース要求の処理を行います。

クライアントがデータベースから切断されるか、またはインスタンスから切り離されると、 調整エージェントの状態は次のようになります。

どのアプリケーションの代理の作業も実行せず、 割り当てられるのを待っているエージェントは、 アイドル・エージェントとみなされ、 エージェント・プール に常駐します。 これらのエージェントは、 クライアント・プログラムの代理として作業を行う調整エージェントからの要求のために、 あるいは、既存の調整エージェントの代理として作業を行うサブエージェントのために、 使用することができます。 使用可能なエージェントの数は、 データベース・マネージャー構成パラメーター maxagents および num_poolagents によって変わります。

次の場合に、エージェント・プール (num_poolagents ) のエージェントは、 調整エージェントとして再使用されます。

それ以外の場合、 リモート・アプリケーションは常に新規エージェントを作成します。

エージェントが必要なときにアイドル状態のエージェントがない場合には、 新しいエージェントが動的に作成されます。 ただし、新規のエージェントを作成すると、一定のオーバーヘッドが生じます。 このように、 クライアントのために活動化できるアイドル状態のエージェントがある方が CONNECT および ATTACH のパフォーマンスは向上します。

あるサブエージェントがアプリケーションの代理として作業を行うときには、 そのサブエージェントはそのアプリケーションに関連付けられている とみなされます。 割り当てられた作業が完了すると、サブエージェントはエージェント・プールに入れられますが、 元のアプリケーションとの関連付けはそのまま残されます。 そのアプリケーションが追加の作業を要求した場合、 そのアプリケーションのために作業を行うエージェントを探すときには、データベース・マネージャーは、 まずアイドル・プール内にそのアプリケーションと関連するエージェントがないかどうかを検査します。

接続済みアプリケーションの数と、 処理可能なアプリケーション要求の数とを別々に制御する (前者は、 max_logicagents により定義される論理エージェントの数を使用して制御し、 後者は、 max_coordagents により定義される活動調整エージェントの数を使用して制御する) 機能により、 柔軟にデータベースで作業負荷を処理することが可能となります。 接続済みアプリケーションの数と、 処理可能なアプリケーション要求の数の間の 1 対 1 関係は、 アプリケーションがデータベースを使用して作業する際の一般的な状態です。 ただし、作業環境によっては、 接続済みアプリケーションの数と処理可能アプリケーション要求の数の間で多数対 1 の関係が必要です。

データベース大域リソースのオーバーヘッドは活動状態の調整エージェントと関連しているので、 このエージェントの数が多ければ、 使用可能なデータベース大域リソースの上限に達する可能性も多くなります。 活動状態の調整エージェントよりも接続済みアプリケーションを多くすれば、 使用可能なデータベース大域リソースの上限に達しないようにすることができます。 max_logicagentsmax_coordagents の値より大きい値を設定すれば、 データベースの作業に集中できます。

DB2 コネクトを XA トランザクション・サポート・コンセントレーターとして使用する方法の詳細と例については、 DB2 コネクト 使用者の手引き を参照してください。

リモート・システムに接続するのに DB2 コネクトを使用する必要がある環境で作業している場合には、 アウトバウンド接続プール が使用されます。 この接続プールにより、ホストへの (最初の接続の後の) 接続時間は減少します。 ホストからの切断が要求されると、DB2 コネクトはインバウンド接続を除去しますが、 プール内のホストへのアウトバウンド接続を保持します。 ホストへの接続が新しく要求されると、 DB2 コネクトは既存のアウトバウンド接続 (使用可能な場合) をプールから再使用します。
注:接続プールを使用する場合、 DB2 コネクトはインバウンド TCP/IP 接続およびアウトバウンド TCP/IP および SNA 接続だけを使用できます。 SNA を使って作業している場合は、接続がプールに入れられるよう、 機密保護タイプを NONE にする必要があります。

接続プールを使用する場合、 活動状態のエージェントは切断後にアウトバウンド接続をクローズせず、 リモート・ホストへの活動状態の接続を使ってエージェント・プールに入ります。 このタイプのエージェントは、 非活動 DRDA エージェント と呼ばれます。 非活動 DRDA エージェントのプールは、アウトバウンド接続プールと同じものです。

4 つの異なる使用法および作業負荷要件に基づく、 次の例を考慮してください。

  1. 最初の例では、 平均 40 人のユーザーが同時に DB2 コネクトを介してリモート・ホスト・データベースに接続します。 ときどき、同時に接続する人の数は 50 に達しますが、 55 を超えることはありません。 トランザクションの所要時間は短く、 ユーザーは頻繁に接続と切断を行います。

    これらの条件により、 同時に DB2 コネクトを介して接続を試行するユーザーの最大数が 55 であることが分かっているので、 システム管理者は MAX_COORDAGENTS を 55 に構成する必要があります。 NUM_POOLAGENTS (エージェント・プールのサイズ) は、 常に、接続中または接続試行中のユーザーの平均数なので、40 に設定する必要があります。 作業負荷がピークになる場合を除いて、このプール・サイズにより、 新しい接続を確立せずにすべてのインバウンド・クライアントを満たすことのできる十分な数のリモート・データベース接続の存在が保証されます。

  2. この 2 番目の例には約 1 000 のインバウンド・クライアントが存在し、 作業負荷はかなり高くなっています。 ユーザー接続は、最初の例と同じく短期間のものとなっています。 システム管理者が、これ以上の同時接続を許可したくないとします。 それで、システム管理者は MAX_COORDAGENTS と NUM_POOLAGENTS を両方とも 1 000 に設定します。 これにより、 リモート・データベースに同時に接続するインバウンド・クライアントの最大数は 1 000 になります。 すべてのクライアントが切断するとき、 プールには 1 000 の接続されたエージェントが存在し、 新しいインバウンド・クライアントの処理を待機しています。
  3. 3 番目の例は、DB2 コネクトを介して 1 つのリモート・データベースに接続する単一のアプリケーションに関するものです。 アプリケーションは、長い期間接続されたままになります。 このシナリオでは、接続するクライアントが最大でも 1 人であることが分かっているので、 エージェントと接続プールの最善の構成は MAX_COORDAGENTS を 11 に設定することです。 この例では、リモート・ホストから接続と切断が頻繁に繰り返されることがないので、 NUM_POOLAGENTS をゼロに設定することができます。 リモート・データベースにアクティブな接続を行うエージェントがプールに保持されないため、 NUM_POOLAGENTS をゼロに設定すると、事実上接続プールは使用できなくなります。 新しいインバウンド・クライアントが接続するたびに、 新しいエージェントが作成され、その処理を行う新しいリモート接続が確立されます。
  4. 4 番目の例は、これまでの 3 つの作業負荷のシナリオすべてを応用したものです。 この例では、システム管理者は、 リモート・データベースへの同時アクセスをちょうど 100 に制限したいと思っています。 それで、MAX_COORDAGENTS を 100 に設定し、 接続パフォーマンスを最大にするため NUM_POOLAGENTS を 100 に設定します。 ただし、DB2 コネクトがインストールされているシステムの作業負荷をモニターするため、 後にローカル接続を行わなければならない可能性もあります。 例外は、発生する同時モニターのスナップショットの数が常に 5 以下である場合です。 この場合は、MAX_COORDAGENTS を 105 に設定します。 この新しい構成値により、同時に接続するアプリケーションの最大数は以前の上限 100 を超え、 偶発的なモニター・スナップショットまたはインスタンス接続 (あるいはその両方) に対応できるようになります。

区分データベース環境、および区画内並行処理が使用可能になっている環境の場合には、 各区画 (つまり、 各データベース・サーバーまたはノード) が独自のエージェント・プールを持っていて、 そこからサブエージェントを引き出すことができます。 このプールがあるので、必要になったり作業を終了したりするたびに、 サブエージェントを作成したり破棄したりする必要がありません。 サブエージェントはプール内に関連エージェントとして残されるので、 それらが関連付けされたアプリケーションから新しい要求が出された場合には、 データベース・マネージャーによってそれらのサブエージェントが使用されます。

データベース・エージェントの数に影響を与えるデータベース・マネージャー構成パラメーターは、 以下のとおりです。

区分データベース環境および区画内並行処理が使用可能になっている環境の場合、 システム内のパフォーマンスとメモリー・コストへの影響は、 以下に示すエージェント・プールのチューニング方法に強く関係しています。

データベース・マネージャーがプロセス (すなわちスレッド) として実行する非同期アクティビティーは、 データベース・エージェント以外にもあります。 たとえば、次のようなアクティビティーです。

各種の DB2 プロセスの指定方法の詳細については、問題判別の手引き を参照してください。


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