接続コンセントレーター
接続コンセントレーター を使用すると、多数のワークステーションや Web ユーザーをサポートするために Db2® for z/OS® データベース・サーバーで必要なリソースを削減できます。 この機能により、 Db2 for z/OS および Db2 Connect ソリューションのスケーラビリティーを大幅に向上させると同時に、 Db2 for z/OS データ共用環境でのフェイルセーフ動作およびトランザクション・レベルのロード・バランシングを実現できます。
接続コンセントレーターを使用すると、 Db2 ホスト・サーバーでリソースを消費せずに複数のアプリケーションを接続したままにしておくことができます。 アプリケーションでは何千人ものユーザーをアクティブに、 そして Db2 ホスト・サーバーでは少数のスレッドのみをアクティブにすることができます。
接続コンセントレーター・テクノロジーにより、 Db2 Connect Server 製品 ( Db2 Connect Enterprise Editionなど) は、 System z ® ホストまたは IBM® Power Systems データベース・サーバーで必要なリソースを大幅に削減しながら、ビジネス・トランザクションを同時に実行する数千人のユーザーにサポートを提供できます。 System z ホストまたは IBM Power Systems データベース・サーバー接続の数がはるかに少ないすべてのアプリケーションからのワークロードを集中させることで、この目標を達成します。 これは前述の接続プール機能とよく似ているように思われるかもしれませんが、 実際には非常にボリュームの大きい OLTP (オンライン・トランザクション処理) アプリケーションのリソース使用量を減らすためのさらに洗練された方法です。
- 「論理エージェント」はアプリケーション接続を表します。
- 「コーディネーター・エージェント」は Db2 接続とスレッドを保持し、アプリケーションの要求を実行します。
- 論理エージェントとの関連がなくなった
- コミットまたはロールバックによりトランザクションが完了すると、プールに戻される
接続プールは、アプリケーションが終了して接続が必要なくなるときに、 接続を確立するのに必要なコストを節約します。 言い換えると、プールした接続を別のアプリケーションが再使用するには、 その前にアプリケーションが接続を切断する必要があります。
また、接続コンセントレーターを使用すると、Db2 Connect はアプリケーションがトランザクションを終了するとすぐ、別のアプリケーションで接続可能にすることができます。このとき、そのアプリケーションは接続を切断する必要はありません。 本来、データベース・サーバー接続とそれに関連付けられたホストおよび Db2 Connect のリソースがアプリケーションで使用されるのは、 アクティブなトランザクションがある場合だけです。 トランザクションが完了するとすぐ、接続とそれに関連付けられているリソースは、 トランザクションを実行する必要のある他のアプリケーションで使用できるようになります。
Db2 Connect の以前のバージョンでは、すべてのアクティブ・アプリケーションに、データベース接続だけでなくアプリケーション要求も管理するエンジン・ディスパッチ可能単位 (EDU) がありました。 この EDU は通常、コーディネーター・エージェント と呼ばれていました。 それぞれのコーディネーター・エージェントは、 アプリケーションと EDU の状態またはコンテキストを追跡しました。 接続数が増加すると、各 EDU は相当量のメモリーを必要とし、 エージェント間でのコンテキスト切り替えではさらに処理使用量が増えてしまいます。
前述のアーキテクチャーでは、接続と EDU は 1 対 1 のリレーションシップにあります。 しかし、接続コンセントレーターを使用すると、接続と EDU の関係を複数対 1 にすることができます。 つまり、接続 (X) と EDU (Y) の関係が X >= Y となります。
接続コンセントレーターは、エージェントを 2 つのエンティティー (論理エージェント と作業エージェント) に分割します。 論理エージェントはアプリケーションを表しますが、特定の EDU を参照することはありません。 論理エージェントには、アプリケーションが必要とするすべての情報と制御ブロックが含まれています。 n 個のアプリケーションがサーバーに接続している場合、 そのサーバーには n 個の論理エージェントがあります。 作業エージェントは、アプリケーションの要求を実行する物理 EDU ですが、 指定されたアプリケーションへの永久接続は持ちません。 作業エージェントは論理エージェントと連携して、トランザクションを実行します。 さらに、その連携をトランザクション境界で終了し、使用可能なプールに戻ります。
ディスパッチャー として知られるエンティティーが、 作業エージェントを論理エージェントに割り当てます。 特定のコンピューティング・プラットフォームで開くことができるファイル・ハンドルの数が制限されている場合、 スケジューラー・インスタンスが複数になる場合があります。
接続コンセントレーターの制限
Db2 Connect Server コンセントレーターの使用には、いくつかの重要な制約事項があります。 システムで接続コンセントレーターの使用を試みる前に、以下の情報をすべて検討してください。
- コンセントレーターは、 ローカル・クライアントからリモート・クライアントへのインバウンド接続を確立するに際し、 TCP/IP プロトコルに依存します。 TCP/IP またはローカル (IPC) を使用するインバウンド接続だけが、 プールされたアウトバウンド接続を利用することができます。 コンセントレーターは、Named PIPE などの他の通信プロトコルを経由した接続を受け入れますが、 その接続で XA 集中フィーチャーを使用することはできません。
- XA 密結合トランザクション・サポートの場合、同じ XA トランザクションに参加するすべてのアプリケーションは、ホストに接続するために同じ Db2 Connect Server インスタンスを使用する必要があります。
- トランザクション境界で保留リソース (保留カーソルなど) を閉じるアプリケーションのみ、 コンセントレーターの利点を享受することができます。 保留中のカーソルをクローズしないトランザクションは引き続き実行されますが、専用のワーカー・エージェントが割り当てられるため、コンセントレーターのすべての機能セットを使用することはできません。
- 一時表を宣言する場合、その表はトランザクションまたは分岐境界で明示的にドロップする必要があります。 表をドロップしないと、接続集中がオフになります。 ただし、アプリケーションは処理を続行します。
- 同じ XA トランザクションに関与するすべてのアプリケーションに、同じ CCSID が必要です。また、同じユーザー ID を使用して接続する必要があります。
- 2 フェーズ接続をサポートするためにアウトバウンド接続が確立された場合、 その接続のエージェントは 2 フェーズ接続をサポートするためにのみ使用することができます。 同様に、1 フェーズ接続をサポートするために確立されたエージェントは、 1 フェーズ接続だけをサポートします。
- コンセントレーターは、 IBM Data Server Driver for JDBC and SQLJ を使用するアプリケーション、および動的 SQL を使用するコール・レベル・インターフェース (CLI) アプリケーションをサポートします。 コンセントレーターは各トランザクション境界で再度準備されるステートメントに依存するので、CLI アプリケーションは KEEPDYNAMIC も使用するべきではありません。
- 組み込み動的 SQL アプリケーションからの動的準備要求はリジェクトされます。 静的 SQL を使用するか、動的 SQL ステートメント用の CLI を使用するよう、 アプリケーションを変更する必要があります。
- 接続コンセントレーターが ON の場合、 Db2 Connect サーバー へのインバウンド要求は SSL を使用できません。 ただし、ターゲット・データベース・サーバーへのアウトバウンド要求では、SSL を使用できます。 接続コンセントレーターがオフの場合、インバウンドおよびアウトバウンド要求の両方で SSL を使用することができます。
Db2 バージョン 9 またはバージョン 8 FixPak 13 (またはそれ以上) で作業する場合、 Db2 Connect コンセントレーター・サポートを有効にするには、 IBM Power Systems バージョン 5 リリース 4 (PTF SI23726) が必要です。 それがない場合には、接続コンセントレーターの XA 部分だけがサポートされます。
接続コンセントレーターの活動化
データベース・マネージャー構成パラメーター max_coordagents は、論理エージェントの最大数を設定します。 max_connections の値をデフォルトよりも大きい任意の値に設定することにより、 コンセントレーター・フィーチャーをアクティブにすることができます。 max_connections のデフォルト値は、max_coordagents の値と同じです。 アプリケーションごとに 1 つの論理エージェントがあるため、 max_connections は実際にはデータベース・インスタンスに接続できるアプリケーションの数を制御し、 max_coordagents は同時にアクティブになれるインバウンド接続の数を制御します。 max_connections は、max_coordagents ~ 64,000 までの範囲の数値を取ります。 デフォルトの論理エージェントの数は、max_coordagents と同じです。
max_connections および max_coordagents を両方とも AUTOMATIC に設定することもできます。 max_connections が AUTOMATIC に設定された場合、接続の数は基本の構成値を超えて増加します。 max_connections と max_coordagents が両方とも AUTOMATIC に設定された場合、max_connections は基本値を超えて増加でき、max_coordagents は自動的に増加して、接続とコーディネーター・エージェントの間の集中率を維持します。
- max_coordagents
- アクティブなコーディネーター・エージェントの最大数。
- num_poolagents
- エージェント・プールのサイズ。 エージェント・プールには、 アクティブでないエージェントやアイドル状態のエージェントが含まれています。 パフォーマンスを改善するために、num_poolagents はクライアントの平均値と同じ値で構成します。
- num_initagents
- プール内の作業エージェントの初期数。 これらはアイドル状態のエージェントです。
XA トランザクション・サポート
接続コンセントレーターのアーキテクチャーにより、 Db2 Connect は、 Db2 for z/OS および IBM Db2 for IBM iに対して密結合 XA トランザクション・サポートを提供できます。 コンセントレーターは、他のすべてのトランザクションの場合と同じように、
作業エージェントを特定の XA トランザクション (単一の XID) に関連付けます。 しかし、XA トランザクションが xa_end()
(分岐境界) によって終了する場合、
作業エージェントが汎用プールに解放されることはありません。 作業エージェントはその XA トランザクションに関連付けられたままです。 別のアプリケーションが同じ XA トランザクションと結合すると、
作業エージェントはそのアプリケーションに関連付けられます。
トランザクション境界を呼び出すと、エージェントはプールに戻されます。 例えば、xa_prepare()
(読み取り専用)、
xa_rollback()
、xa_recover()
、
xa_forget()
、xa_commit()
、
またはロールバックを引き起こすすべての XA エラーは、エージェントを通常のプールに戻します。 Xa_end()
自体はトランザクション・ブランチを終了するだけで、XID との関連付けを終了するには十分ではありません。
XA トランザクション・サポートの例
- 4,000 以上の同時接続を必要とする環境について考えてみます。 CGI アプリケーションを使用する Web サーバー、
または多くのデスクトップ・ユーザーが存在するオフィス・システムでは、
両方ともこの要件を超えてしまう可能性があります。 このような場合、効率的な処理には、
通常は Db2 Connect がスタンドアロン・ゲートウェイとして動作することが求められます。
すなわち、データベースと Db2 Connect を別々のマシンに置く必要があります。Db2 Connect サーバー ・システムは、データベース・マシンへの 4 000 の同時オープン接続を維持できない可能性があります。 たいていの場合、特定の瞬間に生じるトランザクション数は、同時接続の数よりもかなり小さくなります。 そのため、システム管理者は、データベース構成パラメーターを以下のように設定することにより、 システムの効率を最大にすることができます。
ゲートウェイが同時に処理しているトランザクション数が 1,000 しかない場合でも、コンセントレーターは最大 4,000 の並行セッションをオープンし続けます。MAX_CONNECTIONS = 4,000 MAX_COORDAGENTS = 1,000 NUM_POOLAGENTS = 1,000
- 上記の例では、作業エージェントと論理エージェントの関連付けは、常に形成されたり解除されたりしています。 アイドル状態でないそれらのエージェントは、
データベースへの接続は維持していますが、特定のトランザクションに関与してはいません。
そのため、接続を要求する任意の論理エージェント (アプリケーション)で使用することができます。
XA トランザクションの場合は、いくらか異なっています。 この例では、 Db2 Connect ゲートウェイおよび System z または IBM Power Systems データベースで TP モニターが使用されているとします。 アプリケーションが接続を要求すると、 コンセントレーターは、その要求に応じるためアクティブでないエージェントをアクティブにするか、 新しい作業エージェントを作成します。 アプリケーションが XA トランザクションを要求するものとします。 このトランザクションに応じて XID が作成され、作業エージェントがそれに関連付けられます。
アプリケーションの要求が処理されると、
xa_end()
が発行され、作業エージェントからデタッチされます。 作業エージェントと、トランザクションの XID との関連付けは残ります。 このとき、このエージェントは、 関連付けられている XID を持つトランザクション要求にのみ応じることができます。この時点で、別のアプリケーションが非 XA トランザクションを要求する場合があります。 他に使用可能な作業エージェントがない場合でも、 XID に関連付けられたエージェントは 2 番目のアプリケーションで使用可能にされることはありません。 それは、アクティブであると見なされます。 2 番目のアプリケーション用には、新しい作業エージェントが作成されます。 2 番目のアプリケーションがトランザクションを終了すると、 そのアプリケーションの作業エージェントは使用可能なプールに解放されます。
一方、最初のエージェントの XID に関連付けられたトランザクションを要求している他のアプリケーションが、 そのエージェントにアタッチしたりエージェントからデタッチされたりする場合は、 そのエージェント専用の XA トランザクションが実行されます。 そのトランザクションを要求するアプリケーションはすべて、 この作業エージェント (空き状態であれば) に送信されます。
作業エージェントは、 アプリケーションがトランザクション境界呼び出し (
xa_end()
ではない) を発行するまでは、 汎用プールに解放されることはありません。 例えば、アプリケーションがxa_commit()
でトランザクションを終了する場合、 その時点で作業エージェントは XID との関連付けを解除し、 使用可能なプールに戻ります。 この時点で、要求元のアプリケーションはすべて、 別の XA トランザクションか非 XA トランザクションのいずれかの作業エージェントを使用することができます。