分散アプリケーションでの SQL ステートメントのパフォーマンスの向上

多くの場合、特定の方式を使用して、 分散システムで実行される SQL ステートメントのパフォーマンスを向上させることができます。

プロシージャー

プログラム固有のプログラミングインターフェース情報の開始。分散アプリケーションにアクセスするSQLステートメントを改善するには、以下の方法を使用します。

  • サーバー側のリソースを保持したままになるのを避けるため、頻繁にコミットするようにします。
  • よくチューニングされた 1 つの SQL ステートメントで目的の結果を取得できるのであれば、複数の SQL ステートメントは使用しないようにします。
    あるいは、SQL ステートメントをストアード・プロシージャーに 入れて、ストアード・プロシージャーを介してサーバー側で SQL ステートメントを 出し、その結果を戻すようにします。 ストアード・プロシージャーを使用すれば、SQL ステートメントごとに送受信操作を行なうのではなく、(CALL ステートメント用の) 送受信操作が 1 つだけ作成されることになります。

    アプリケーション内にある SQL ステートメントの数によっては、ストアード・プロシージャーを使用することで、経過時間を大幅に短縮し、プロセッサー・コストを削減することができます。

  • RELEASE ステートメントとバインド・オプションを使用します。
    RELEASE ステートメントは、コミット時にリモート接続を解放するために必要なネットワーク・トラフィックを最小限に抑えます。 例えば、アプリケーションが複数の別のサーバーに接続している場合、 アプリケーションがそれぞれのサーバーでの処理を完了した時に、RELEASE ステートメントを指定します。 RELEASE ステートメントは、COMMIT が出されるまで、カーソルをクローズせず、 リソースを解放せず、その後での接続の使用を妨げることがありません。 これは単に、COMMIT 時の処理をより効率的にするだけのステートメントです。

    バインド・オプション DISCONNECT(EXPLICIT) は、RELEASE が指定されたすべてのリモート接続を破棄します。

  • CREATE PROCEDURE 文のCOMMIT ON RETURN YES 節を使用して、 Db2 が CALL 文からの復帰時にストアドプロシージャに代わって暗黙のCOMMIT を発行することを指示することを検討してください。 この文節を使用すれば、ロックが保持される時間を短縮し、ネットワーク・トラフィックを減らすことができます。 COMMIT ON RETURN YES を指定すると、ストアード・プロシージャーを呼び出す前にクライアントが行った更新はすべて、 ストアード・プロシージャーを変更するとコミットされます。
  • CURRENT RULES 特別レジスタの値を DB2 に設定します。
    LOBデータの要求を行う際には、CONNECTを実行する前に、CURRENT RULES特殊レジスタを DB2 CONNECTを実行する前に、STDではなくに設定します。 DB2 という値 (これがデフォルトです) を使用すると、パフォーマンス上の利点が得られます。 Db2 for z/OS®サーバーがカーソルに対するOPEN要求を受け取ると、サーバーはCURRENT RULES特殊レジスターの値を使用して、カーソル内で異なる行をフェッチするときに、アプリケーションがLOB値とLOBロケーター値の間で切り替えを行うかどうかを判別します。 CURRENT RULES に値 DB2 を指定すると、 最初の FETCH 要求が応答セット内の各 LOB 列ごとにそのフォーマットを指定し、 さらにそのフォーマットは後続の FETCH 要求で変更されないことを、アプリケーションが指示します。 ただし、CURRENT RULES の値を STD に設定した場合には、アプリケーションは LOB 列 を LOB ロケーターのホスト変数または LOB ホスト変数の中にフェッチすることを指示します。

    「現在のルールに対するSTD」の値を使用すると、LOBデータを取得する際により柔軟なプログラミングが可能になりますが、 DB2。 STD オプションを指定すると、サーバーはカーソルをブロックしません。 このオプションにより、 DB2 オプションにより、カーソルをブロックできる場所では、カーソルがブロックされる場合があります。汎用プログラミングインターフェース情報の終了。