使用者の手引き


接続のプール

DB2 コネクト エンタープライズ・エディション・サーバーは、しばしば、 同時に行われる何千ものクライアント要求に対するデータベース接続を提供します。 データベース・サーバーへの接続の確立と切断は、 リソースを集中的に使用するプロセスのため、 データベース・サーバーと DB2 コネクト・サーバーの両方のパフォーマンスに悪影響を及ぼす場合があります。 このことは、Web ページにアクセスするたびにデータベース・サーバーへの新規接続を行い、 照会を実行してから接続を終了する必要のある Web 環境で顕著に見られます。 このオーバーヘッドを減らすため、 DB2 コネクト エンタープライズ・エディションは、 接続プール を使用して、 即座にアクセス可能なプールでデータベースへのオープン接続を維持します。

接続プールの働き

接続プールの存在は、 DB2 コネクトを介してホストに接続するアプリケーションからは認識されません。 アプリケーションでホストからの切断が要求されると、 DB2 コネクトではアプリケーションとのインバウンド接続は切断されますが、 ホストとのアウトバウンド接続はプール内に保持されます。 新しいアプリケーションが接続を要求すると、 DB2 コネクトは既存のプールからの接続を使用します。 すでに存在している接続を使用すると、 全体の接続時間が短縮されるだけでなく、 ホストでの高い CPU 接続コストも削減されます。

接続プールを使用するには、 次の APAR が DB2 (OS/390 版) バージョン 6.1 に適用されている必要があります。

     APAR PQ33473

DB2 コネクト・エージェントは、 アイドルまたはアクティブの 2 つの状態のいずれかになっています。 エージェントがアプリケーションの作業を実行している場合、 そのエージェントはアクティブです。 この作業が完了すると、エージェントはアイドル状態になり、 同じアプリケーションまたは別のアプリケーションからの次の作業を待ちます。 すべてのアイドル・エージェントは、 アイドル・エージェント・プールとして知られている場所に一緒に保持されます。 このプールのサイズは、NUM_POOLAGENTS 構成パラメーターを使用して構成できます。 このパラメーターは、 システムが保守するアイドル・エージェントの最大数と同じです。 このパラメーターをゼロに設定すると、 接続プール機能はオフになります。

DB2 コネクトは、最初のクライアント要求を受け取る前に、 データベースへの接続を確立することはありません。 しかし、望むなら、クライアントが要求を出す前に、 アイドル・エージェントのプールを満たすことができます。 NUM_INITAGENTS 構成パラメーターを使用すると、 開始時にプールを満たすことができます。 このパラメーターは、始動時に作成されるアイドル・エージェントの数を決定します。 これらのアイドル・エージェントが、 ホスト・データベース・サーバーに最初に接続することはありません。

クライアントがホストへの接続を要求すると、 DB2 コネクトはホスト・データベース・サーバーに接続しているプールの中からエージェントを取得しようとします。 それが失敗すると、アイドル・プールで使用可能なエージェントを検索します。 プールが空の場合、DB2 コネクトは新しいエージェントを作成します。

MAX_COORDAGENTS 構成パラメーターを使用して、 同時にアクティブにできるエージェントの最大数を制御することができます。 この数字を超えると、新しい接続はエラー SQL コード SQL1226 を発行して失敗します。 (このコードは、同時に行うアウトバウンド接続の最大数を超過したことを意味します。)

DB2 登録変数 DB2CONNECT_IN_APP_PROCESS を使用すると、 DB2 コネクト EE と同じマシンで稼働しているアプリケーションが、 アプリケーション・プロセス内で DB2 コネクトを実行するか (省略時の動作)、 アプリケーションが DB2 コネクト EE サーバーに接続してから、 エージェント内でホスト接続を実行するかのいずれかを行うことができます。 アプリケーションが接続プールを使用するには、 DB2 コネクト EE サーバーのエージェント内からホストに接続し、 DB2CONNECT_IN_APP_PROCESS を NO に設定する必要があります。

DB2 コネクトの接続コンセントレーター

DB2 コネクトの接続コンセントレーター 技術を使用すると、 DB2 コネクト エンタープライズ・エディション・サーバーは、 商取引を行う何千人ものユーザーをサポートすると共に、 S/390 ホストまたは AS/400 データベース・サーバーで必要とされるリソースを大幅に削減することができます。 この技術は、 すべてのアプリケーションからの作業負荷を、 より少ない数の S/390 ホスト接続または AS/400 データベース・サーバー接続に集中することにより、 このことを成し遂げます。 これは前述の接続プール機能とよく似ているように思われるかもしれませんが、 実際には非常にボリュームの大きい OLTP (オンライン・トランザクション処理) アプリケーションのリソース使用量を減らすためのさらに洗練された方法です。

接続プールは、アプリケーションが終了して接続が必要なくなるときに、 接続を確立するのに必要なコストを節約します。 言い換えると、プールした接続を別のアプリケーションが再使用するには、 その前にアプリケーションが接続を切断する必要があります。

一方、接続コンセントレーターを使用すると、 DB2 コネクトはアプリケーションがトランザクションを終了するとすぐ、 別のアプリケーションで利用可能にすることができます。 このとき、そのアプリケーションは接続を切断する必要はありません。 本来、データベース・サーバー接続とそれに関連付けられたホストおよび DB2コネクトのリソースがアプリケーションで使用されるのは、 アクティブなトランザクションがある場合だけです。 トランザクションが完了するとすぐ、接続とそれに関連付けられているリソースは、 トランザクションを実行する必要のある他のアプリケーションで使用できるようになります。

接続コンセントレーターの実装方法

DB2 コネクトの以前のバージョンでは、 すべてのアクティブ・アプリケーションに、 データベース接続に加えてアプリケーション要求を管理するエンジン・ディスパッチ可能単位 (EDU) がありました。 この EDU は通常、調整エージェント と呼ばれていました。 それぞれの調整エージェントは、 アプリケーションと EDU の状態またはコンテキストを追跡しました。 各 EDU は、接続数の増加時に相当量のメモリーを必要とするため、 エージェント間でのコンテキスト切り替えではさらにオーバーヘッドが増えてしまいます。

上記のアーキテクチャーでは、 接続と EDU は 1 対 1 の関係にあります。 しかし、接続コンセントレーターを使用すると、 接続と EDU の関係を複数対 1 にすることができます。 つまり、接続 (X) と EDU (Y) の関係は X >= Y になります。

接続コンセントレーターは、エージェントを 2 つのエンティティー (論理エージェント作業エージェント) に分割します。 論理エージェントはアプリケーションを表しますが、 特定の EDU を参照することはありません。 論理エージェントには、アプリケーションが必要とするすべての情報と制御ブロックが含まれています。 n 個のアプリケーションがサーバーに接続している場合、 そのサーバーには n 個の論理エージェントがあります。 作業エージェントは、アプリケーションの要求を実行する物理 EDU ですが、 指定したアプリケーションへの永久接続は持ちません。 作業エージェントは論理エージェントと連携して、トランザクションを実行します。 それから、その連携をトランザクション境界で終了し、使用可能なプールに戻ります。

論理エージェント・スケジューラー として知られるエンティティーが、 作業エージェントを論理エージェントに割り当てます。 特定のコンピューティング・プラットフォームで開くことができるファイル・ハンドルの数が制限されている場合、 論理エージェントの数がファイル・ハンドルの限度を超えたときにスケジューラー・インスタンスが複数になる場合があります。

コンセントレーターの活動化

接続コンセントレーターを使用するには、 次の APAR が DB2 (OS/390 版) バージョン 6.1 に適用されている必要があります。

     APAR PQ33473

データベース・マネージャー構成パラメーター MAX_LOGICAGENTS は、 論理エージェントの最大数を設定します。 MAX_LOGICAGENTS の値を省略時値よりも大きい任意の値に設定することにより、 コンセントレーター機能をアクティブにすることができます。 MAX_LOGICAGENTS の省略時値は、MAX_COORDAGENTS の省略時値と同じです。 アプリケーションごとに 1 つの論理エージェントがあるため、 MAX_LOGICAGENTS は実際にはデータベース・インスタンスに接続できるアプリケーションの数を制御し、 MAX_COORDAGENTS は同時にアクティブになれるインバウンド接続の数を制御します。 MAX_LOGICAGENTS は、MAX_COORDAGENTS 〜 64,000 までの範囲の数値を取ります。 省略時の論理エージェントの数は、MAX_COORDAGENTS と同じです。

既存の構成パラメーターの中にも、 エージェントを構成するために使われるものがあります。 それには、以下のパラメーターが含まれます。

MAXAGENTS
作業エージェントの最大数。

MAX_COORDAGENTS
アクティブな調整エージェントの最大数。

NUM_POOLAGENTS
エージェント・プールのサイズ。 エージェント・プールには、 アクティブでないエージェントやアイドル状態のエージェントが含まれています。

NUM_INITAGENTS
プール内の作業エージェントの初期数。 これらはアイドル状態のエージェントです。

XA トランザクション・サポート

接続コンセントレーターのアーキテクチャーを使用すると、 DB2 コネクトは DB2 (OS/390 版) および DB2 (AS/400 版) と密接な関係にある XA トランザクション・サポートを提供することができます。 コンセントレーターは、他のすべてのトランザクションの場合と同じように、 作業エージェントを特定の XA トランザクション (単一の XID) に関連付けます。 しかし、XA トランザクションが xa_end() (分岐境界) によって終了する場合、 作業エージェントが汎用プールに解放されることはありません。 作業エージェントはその XA トランザクションに関連付けられたままです。 別のアプリケーションが同じ XA トランザクションと結合すると、 作業エージェントはそのアプリケーションに関連付けられます。

トランザクション境界を呼び出すと、 エージェントはプールに戻されます。 たとえば、xa_prepare() (読み取り専用)、 xa_rollback()xa_recover()xa_forget()xa_commit()、 またはロールバックを引き起こすすべての XA エラーは、 エージェントを通常のプールに戻します。 xa_end() が終わらせるのはトランザクションの分岐だけです。 これは XID との関連付けを終わらせるには不十分です。

  1. 4,000 以上の同時接続を必要とする環境について考えてみます。 CGI アプリケーションを使用する Web サーバー、 または多くのデスクトップ・ユーザーが存在するオフィス・システムでは、 両方ともこの要件を超えてしまう可能性があります。 こういう場合、効率的な処理には、 通常は DB2 コネクトがスタンドアロン・ゲートウェイとして動作することが求められます。 すなわち、データベースと DB2 コネクトを別々のマシンに置く必要があります。

    DB2 コネクト・サーバー・システムは、 データベース・マシンに対する 4,000 もの同時に行われるオープン接続を維持できない場合があります。 たいていの場合、特定の瞬間に生じるトランザクション数は、 同時接続の数よりもかなり小さくなります。 そのため、システム管理者は、 データベース構成パラメーターを以下のように設定することにより、 システムの効率を最大にすることができます。

         MAX_LOGICAGENTS =  4,000
         MAX_AGENTS      =  1,000
         MAX_COORDAGENTS =  1,000
         NUM_POOLAGENTS  =  1,000
    

    ゲートウェイが同時に処理しているトランザクション数が 1,000 しかない場合でも、 コンセントレーターは最大 4,000 の並行セッションをオープンし続けます。

  2. 上記の例では、 作業エージェントと論理エージェントの関連付けは、常に形成されたり解除されたりしています。 アイドル状態でないそれらのエージェントは、 データベースへの接続は維持していますが、特定のトランザクションに関与してはいません。 そのため、接続を要求する任意の論理エージェント (アプリケーション) が使用することができます。

    XA トランザクションの場合は、いくらか異なっています。 この例では、DB2 コネクト・ゲートウェイと OS/390 または AS/400 データベースで TP モニターを使用していることを想定しています。 アプリケーションが接続を要求すると、 コンセントレーターは、その要求に応じるためアクティブでないエージェントをアクティブにするか、 新しい作業エージェントを作成します。 アプリケーションが XA トランザクションを要求するものとします。 このトランザクションに応じて XID が作成され、 作業エージェントがそれに関連付けられます。

    アプリケーションの要求が処理されると、 xa_end() が発行され、作業エージェントから切り離されます。 作業エージェントと、トランザクションの XID との関連付けは残ります。 このとき、このエージェントは、 関連付けられている XID を持つトランザクション要求にのみ応じることができます。

    この時点で、別のアプリケーションが非 XA トランザクションを要求する場合があります。 他に使用可能な作業エージェントがない場合でも、 XID に関連付けられたエージェントは 2 番目のアプリケーションで使用可能にされることはありません。 それは、アクティブであるとみなされます。 2 番目のアプリケーション用には、新しい作業エージェントが作成されます。 2 番目のアプリケーションがトランザクションを終了すると、 そのアプリケーションの作業エージェントは使用可能なプールに解放されます。

    一方、最初のエージェントの XID に関連付けられたトランザクションを要求している他のアプリケーションが、 そのエージェントに接続したりエージェントから切断されたりする場合は、 そのエージェント専用の XA トランザクションが実行されます。 そのトランザクションを要求するアプリケーションはすべて、 この作業エージェント (空き状態であれば) に送信されます。

    作業エージェントは、 アプリケーションがトランザクション境界呼び出し (xa_end() ではない) を発行するまでは、 汎用プールに解放されることはありません。 たとえば、アプリケーションが xa_commit() でトランザクションを終了する場合、 その時点で作業エージェントは XID との関連付けを解除し、 使用可能なプールに戻ります。 この時点で、要求元のアプリケーションはすべて、 別の XA トランザクションか非 XA トランザクションのいずれかの作業エージェントを使用することができます。

制約事項

ゲートウェイ・コンセントレーターの使用については、 重要な制約事項がいくつかあります。 システムで接続コンセントレーターの使用を試みる前に、 以下の情報をすべて検討してください。

データベースのチューニング

システム・パフォーマンスは、ホストまたは AS/400 データベース・サーバーのデータベースのパフォーマンスによって影響を受けます。

それぞれのデータベース管理システムによって、異なるパフォーマンス機能が備わっています。 各種システムの SQL 最適化プログラムは、たとえば、 同じアプリケーションを使用しても異なる挙動をとることがあり得ます。 詳細については、ホストまたは AS/400 データベース・サーバーのシステム・パフォーマンス資料を参照してください。

DB2 ユニバーサル・データベース (AS/400 版) 用については、非コミット読み取り (UR) またはジャーナルを避けるための「コミットなし」(NC) バインド・オプションを使用することによって、パフォーマンスを改善することができます。

注:UR を使用する場合、ジャーナルされていないデータは、 読み取りはされますが更新されません (これは、 ブロッキングを ALL に設定している場合です)。

アプリケーション・サーバーおよびそれが提供するロックの細分性により、 照会またはアプリケーションに使用される分離レベルは、パフォーマンスに有効な影響を与えることがあります。

データベースは、適切なレベルの正規化、索引の効果的な使用、 およびデータベース・スペースの適切な割り振りを行う必要があります。 また、パフォーマンスは、以下のセクションで説明するとおり、 使用するデータ・タイプによって影響を受けます。

DB2 (OS/390 版) のチューニング

OS/390 V1R3 は、TCP/IP サポートの最小要件です。 OS/390 V2R5 以降の使用を強くお勧めします。

分散アプリケーションを DB2 (OS/390 版) に接続する処理は、 分散データ機能 (DDF) によって行われます。 DDF はアプリケーション・サーバーとしてセットアップする必要があります。 これを行うには、リモート・システムの LU 名を SYSIBM.LUNAMES 表に挿入するか、または LUNAME、 SYSMODENAME、 USERSECURITY、ENCRYPTPSWDS、 MODESELECT、および USERNAMES 値を SYSIBM.SYSLUNAME 表に挿入します。 続いてブートストラップ・データ・セット (BSDS) に対して DDF 更新を実行します。 たとえば、次のようにします。

   DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001

最高のパフォーマンスを得るには、推奨されている DDF アドレス空間の優先順位を使用する必要があります (COMPAT モードの場合は DBM1 と同じか多少小さい値)。VLF 内では許可の RACF キャッシングを使用してください。 また、使用できる場合は V5 パッケージ許可のキャッシングを使用してください。 ほとんどの操作では CACHEPAC=32768 の値で十分です。

DDF では VTAM に対する接続が試行されるので、 DDF を開始する際には VTAM をアクティブにしていなければなりません。 VTAM APPL 定義の例を以下に示します。

   SYD51TC* APPL  AUTH=(ACQ),                                  X
              PARSESS=YES,                                     X
              HAVAIL=YES,                                      X
              EAS=1600,                                        X
              APPC=YES,                                        X
              DSESLIM=1024,                                    X
              DMINWNL=512,                                     X
              DMINWNR=512,                                     X
              AUTOSES=1,                                       X
              SECACPT=ALREADYV,                                X
              SRBEXIT=YES,                                     X
              SYNCLVL=SYNCPT,                                  X
              MODETAB=DB2MODET,                                X
              VPACING=63                                       X

OS/390 では非アクティブなスレッド処理を最適化できます。 V3 では最大 10,000 までクライアントを並行接続でき、 V4 と V5 では最大 25,000 まで並行接続できます。 ただし、いずれの場合も並行してアクティブにできる最大数は 1999 です。 個々のワークステーション・クライアントは非アクティブになっても接続したままにしておくことができます。 そのスレッドは、コミットのたびに非アクティブ・チェーンに組み込まれます。

DSNZPARM パラメーターの CMTSTATCONDBAT、および MAXDBAT はスレッド処理に影響を与えます。 最高のパフォーマンスを得るには、 CMTSTATINACTIVEに設定し、 良好なパフォーマンスが得られる DBAT の最大接続数に CONDBAT を調整し、 受け入れられるアクティブな DBAT の最大数に MAXDBAT を調整してください。

VTAM 構成を含めて、 DRDA ネットワーク内で DB2 (OS/390 版) を接続することに関する完全な説明については、 オンラインのコネクティビティー 補足を参照してください。

データ変換

データを 1 つの環境から別の環境へ転送する時、それを変換する必要があり得ます。 この変換はパフォーマンスに影響を与えることがあります。

次のプラットフォームについて考慮してみます。

そして、以下の数値データ・タイプについて考慮してみます。

表 8 は、いつ変換が行われるかを示します。

表 8. データ変換




Intel


IEEE


S/370 & S/390


OS/400


パック 10 進数データ


Intel
IEEE
S/370/390
OS/400


No
No
No
No


No
No
No
No


No
No
No
No


No
No
No
No


ゾーン 10 進数データ


Intel
IEEE
S/370/390
OS/400


No
No
Yes
Yes


No
No
Yes
Yes


Yes
Yes
No
No


Yes
Yes
No
No


整数データ


Intel
IEEE
S/370/390
OS/400


No
Yes
Yes
Yes


Yes
No
No
No


Yes
No
No
No


Yes
No
No
No


浮動小数点データ


Intel
IEEE
S/370/390
OS/400


No
Yes
Yes
Yes


Yes
No
Yes
No


Yes
Yes
No
Yes


Yes
No
Yes
No

1 バイト文字のデータ変換の CPU コストは、 数値データの変換コストよりも一般に小さいといえます (データ変換が必要な場合)。

DATE/TIME/TIMESTAMP のデータ変換コストは、1 バイト CHAR の場合とほぼ同じです。 浮動小数点データの変換コストが最大です。 アプリケーション設計者は、DB2 コネクト・ベースのアプリケーションを設計するときは、 これらの事実の利点を取り入れることができます。

データベース表が 'FOR BIT DATA' と定義される列を持っている場合、 アプリケーションとデータベースとの間で転送される文字データはデータ変換をなんら必要としません。 このことは、 ホストまたは AS/400 データベース・サーバー上でデータを保存するときに利用することができます。

文字データのデータ・タイプ

文字データは、CHAR または VARCHAR のどちらかのデータ・タイプを持つことができます。 どのデータ・タイプがより効率的かは、フィールド内のデータの代表的な長さによります。

ネットワークのチューニング

分散データベース環境で全体のパフォーマンスを向上させるには、 ネットワークからの遅延をなくすことが最善の方法です。 一般に、ネットワーク管理者にとって効率的なネットワークとは、 伝送と伝送の間にできる限り多くのデータが収集されるネットワークです。 この考え方は、分散データベースなどのアプリケーションには当てはまりません。 この種のアプリケーションはネットワーク内で遅延が発生するからです。 エンド・ユーザーにはネットワークの効率がよいとは思えず、 遅延していることだけが分かります。

ほとんどのネットワーク装置には遅延パラメーターがありますが、 その大部分の省略時値は分散データベースにとっては非常に不適切なものです。 パフォーマンスを改善するには、この種のパラメーターを見付けて、 可能であればゼロに設定する必要があります。 また、装置のバッファー・サイズが十分で、 データが脱落して再送が行われたりしないことを確認する必要があります。 たとえば、UNIX システムでは送信または受信待ち行列の深さの省略時値は通常 32です。 パフォーマンスを向上させるには、待ち行列の深さを 150 に設定してください。 DLC の設定でこれに対応するパラメーターは Receive Depth で、 この値も 150 に設定する必要があります。

ほとんどの場合、IOBUF パラメーターは低過ぎる値に設定されています。 この値は普通は 500 に設定されていますが、経験が示すところによると、 特に ESCON や 3172 などのチャネル接続の場合に、 大量のデータを移動するには 3992 の値が最適です。

SNA 接続の場合、 ワークステーション・ソフトウェアのモード・プロファイルを 63 に設定する必要があります。 一般的には、 ネットワーク全体の受信ページングの値を最大値に設定する必要があるので、 DB2 APPL ステートメントの VPACING パラメーターと PACING パラメーター、 および交換回線大ノードのワークステーションの PU/LU も 63 に設定する必要があります。 このように設定すると、 送信側が応答を待機する状態になるまでに流れるメッセージの量を、 継続的に増やすことができます。

LAN システムでは、 DLC や LLC の送信ウィンドウや受信ウィンドウのサイズにより パフォーマンスはかなり左右されます。 送信値は 7 以上に設定する必要があります。また、 ほとんどの構成では受信値を 4 以下に設定するのが最適です。

イーサネットを実行している場合は、 TCP セグメントのサイズを 1500 バイトに設定する必要があります。 トークンリングや FDDI ネットワークの場合はこの値を 4400 バイトにする必要があり、 TCP/IP で ESCON アダプターを使用している場合はセグメントのサイズを常に 4096 にする必要があります。

最後に TCP/IP ネットワークの場合は、 TCP 送信および受信バッファー・サイズを 32768 より大きな値に設定する必要があります。 通常は 65536 の値が最適です。
注:ゲートウェイからサーバーへの接続 (アウトバウンド接続) を確立するには、 クライアントからゲートウェイへの接続 (インバウンド接続) を確立する場合よりコストがかかります。 数千ものクライアントがゲートウェイを介してサーバーに対し接続と切断を頻繁に繰り返す環境では、 アウトバウンド接続を確立するのに相当の処理時間を要します。 DB2 コネクトでは TCP/IP 上で接続プーリングが行われます。 クライアントでサーバーからの切断が要求されると、 ゲートウェイではクライアントとのインバウンド接続は除去されますが、 サーバーとのアウトバウンド接続はプール内に保持されます。 新しいクライアントでゲートウェイに対して接続要求がなされると、 ゲートウェイによりプールから既存の接続が提供されるので、 接続時間が全体として短縮され、高コストのサーバーへの CPU 接続が節約されます。

DB2 での接続プールについて詳しくは、 管理の手引き を参照してください。

次の表に、ネットワーク・パフォーマンスのチューニング方式を要約してあります。


参照するもの 設定 注意
意図的な遅延 ネットワーク装置の遅延パラメーター 0 に設定します。 通常、省略時値は大き過ぎます。
バッファー IOBUF パラメーター 3992 にセットアップします。 ESCON や他のチャネル・アダプターの場合に特に有効です。
RUSIZE 最適なサイズは 4096 です。 RUSIZE と RQRIOBLK を同サイズに設定すると最善のパフォーマンスが得られます。
ペーシング VPACING、PACING、および Mode Profiles を 63 に設定します。 適切な場合は適応ペーシングを使用します。
アダプターの設定 送信受信待ち行列の長さ 推奨値は 150。 通常、省略時値は 32 です。
SNA での DLC ウィンドウ 送信ウィンドウ・サイズは大きい値 (8 以上) に設定します。 受信ウィンドウ・サイズは小さい値 (1 など) に設定して、繰り返しテストしながら値を大きくし、理想的な値を見つけます。 それぞれの論理装置により遅延が追加されます。 ネットワーク・トポロジーをできるだけ単純なものにしてください。
TCP の設定 セグメント・サイズ イーサネットでは 1500、トークンリングおよび FDDI では 4400 です。 TCP/IP 接続に ESCON アダプターを使用する場合は必ず 4096 に設定する必要があります。
送信 / 受信スペースのサイズ 両方とも 64K にする必要があります。 Windows の場合、省略時値はほんの 8192 です。 Windows レジストリーで設定できます。

ネットワーク・ハードウェア

以下の考慮事項は、ハードウェアに関係するものです。

システム・リソースの競合

システム内の多くのタスクがシステム・リソースを求めて競合する場合は、 パフォーマンスの劣化があり得ます。以下の質問を考慮してください。

パフォーマンスのトラブルシューティング

DB2 コネクト・ユーザーが、ホストまたは AS/400 サーバーから大きな照会をしていて長い時間待っても応答がない場合、以下の領域を考慮して、 考えられるパフォーマンス上の問題の原因を調べてください。

  1. ホストまたは AS/400 サーバーから多数のデータ・ブロックが戻ってしまうような照会に関しては (通常は 32K かそれ以上のデータ)、 データベース・マネージャー構成パラメーター RQRIOBLK を 32767 に設定しているか確認してください。これは、コマンド行プロセッサー (CLP) を以下のように使用して行います。
       db2 update database manager configuration using RQRIOBLK 32767
    
  2. ホストまたは AS/400 サーバーへの接続に VTAM を使用している場合、 「交換回線大ノード (switched major node)」構成の下の PACING パラメーターの値を見てください。 DB2 コネクト・ワークステーション上で、 IBMRDB モード定義用の「LU 6.2 モード・プロファイル (LU 6.2 Mode Profile)」の通信設定を検査してください。 この定義において、 「受信ペーシングウィンドウ (Receive pacing window)」パラメーターの値が VTAM で定義した PACING 値以下になっているかを確認してください。 DB2 コネクト・ワークステーションの「歩調合わせウィンドウ (Receive pacing window)」と VTAM の "PACING" の共通の値は、8 です。
  3. IBMRDB モード定義で定義した最大 RU サイズが適切な値に設定されているか確認してください。 トークンリング・ハードウェアを使用して接続する場合、 4K を下回らない値に設定することをお勧めします。 イーサネット・ハードウェアを使用して接続する場合、 イーサネット・フレーム・サイズの最大値は 1536 バイトであることに注意してください。 その値が限界要因になります。
  4. 使用している環境の VTAM 管理者と相談して、 VTAM が DB2 コネクト・ワークステーションとの LU-LU セッションで「適応歩調合わせ」を使用しているか確認してください。


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