使用者の手引き

アプリケーションの設計

アプリケーションを作成するとき、いくつかの方法でパフォーマンスを改善することができます。 たとえば以下のものが含まれます。

複合 SQL およびストアード・プロシージャー

多くのコマンドと応答を受け渡しするアプリケーションでは、 ネットワークのオーバーヘッドが重要になります。 複合 SQL とストアード・プロシージャーは、 このオーバーヘッドを軽減する 2 つの方策です。

1 つのアプリケーションがいくつかの SQL ステートメントをプログラミング論理の介入なしに送信する場合、 複合 SQL を使用することができます。 プログラミング論理が SQL ステートメントのグループ内で必要な場合は、 ストアード・プロシージャーを使用することができます。

以下のものを除き実行可能なステートメントはすべて、 複合 SQL ステートメント内に含めることができます。

       CALL                                                    
       FETCH                                                   
       CLOSE                                                   
       OPEN                                                    
       Compound SQL                                            
       Connect                                                 
       Prepare                                                 
       Release
       Describe                                                
       Rollback                                                
       Disconnect                                              
       Set connection                                          
       execute immediate                                       

詳細については、SQL 解説書 を参照してください。

複合 SQL をアプリケーション内で使用するときの情報については、 NOT ATOMIC 複合 SQL を参照してください。 複合 SQL をインポート・ユーティリティーとともに使用するときの情報につ いては、 インポートおよびエクスポート・ユーティリティーの使用を参照してください。

ストアード・プロシージャーを使用すると、プログラム論理がサーバーに入れられるので、 ネットワーク通信量を削減するのに役立ちます。バージョン 5.0 より前の DB2 では、 ストアード・プロシージャーで出力パラメーターを戻すことしかできなかったので、 アプリケーションでコミット・コマンドを別に発行する必要がありました。 したがって、ネットワーク通信が 2 回行われました。 DB2 バージョン 5.0 以降では、 プロシージャーの終了時に自動的にコミットできます。また、結果セットを戻すこともできます。 こうするとクライアントのアプリケーション論理を最小化できます。

ストアード・プロシージャーの使用に関する情報については、 ストアード・プロシージャーを参照してください。

要求のグループ化

関連する複数のデータベース要求 (SQL ステートメント) を 1 つのデータベース要求にグループ化すれば、 ネットワークを通して伝送する要求と応答の数を減らすことができます。 たとえば、以下のステートメントをグループ化して、

   SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1
   SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=2

次のようにすると、

   SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 OR ROW_ID=2

ネットワークを通して送られる要求の数が減ります。

また、IN および BETWEEN のようなキーワードを使用することにより、 戻される行数を減らすことができます。 さらに、UPDATE および DELETE ステートメントについて、WHERE、IN、 および BETWEEN キーワードを使用することができます。

述部論理

必要な行および列だけを要求する場合に、述部論理を使用することができます。 これは、ネットワーク通信量およびデータ伝送の CPU オーバーヘッドを最小化します。

たとえば、次の照会は使用しないようにします。

   SELECT * FROM TABLEA

ROW_ID=1 を持つ TABLEA の 1 番目の行だけが実際に必要な場合や、 1 番目と 2 番目の列だけが必要な場合には、上の照会は使用しません。

データのブロック化

サーバーからの大量のデータが予想される場合は、データ・ブロックを使用します。 このブロック化によって、ネットワーク帯域幅の使用は改善され、 ホストまたは AS/400 データベース・サーバーと DB2 コネクト・ワークステーションの両方の CPU オーバーヘッドが減少します。

サイズに関係なく、 送受信される各メッセージについて一定量の CPU とネットワークのオーバーヘッドがかかります。 データ・ブロックは、同じ量のデータ転送に必要とされるメッセージの数を減らします。

ブロック化を使用すると、照会からのデータの 1 番目の行は、1 番目の ブロックが受け取られるまではアプリケーションに送 達されません。ブロック化は、1 番目の行を探す検索時間を増加させますが、 その後に続く行については検索時間を短縮できます。

別の考慮事項は、使用される記憶容量です。 メモリー作業セットは、ブロック化がオンになると通常は増加します。 SNA 使用時のブロック化に関する十分な説明については、 分散関係データベース体系 接続の手引き を参照してください。

DB2 コネクト内では、RQRIOBLK で説明するとおり、 各ブロック内で転送されるデータの量を制御することができます。

ブロック化を呼び出すには、 prep または bind コマンドの BLOCKING オプションを使用します。 (詳細については、BIND コマンドをご覧ください。) ブロック化は、次の場合にオンになります。

読み取り専用、更新可能、未確定カーソルの定義については、 アプリケーション開発の手引き を参照してください。
注:動的 SQL を使用している場合は、カーソルは常に未確定です。

BLOCKING を伴う SQL ステートメント

更新可能な SELECT ステートメント (UPDATE/DELETE WHERE CURRENT OF ステートメントを使用する) は、 非ブロック化の照会です。したがって、絶対に必要なときだけそれを使ってください。

更新可能な SELECT は、 SELECT が完了した時と UPDATE/DELETE が発行される時との間にその行が決して変更されないようにします。 このレベルの並行性がアプリケーションにとって重要でない場合は、 別の方法として、非更新可能な SELECT から戻される値に基づく探索基準を用いて、 DELETE または UPDATE を使用します。

読み取り専用の SELECT については、 FOR FETCH ONLY を指定します (VM および VSE の場合を除きます。 この場合、サポートされていません)。

静的 SQL と動的 SQL

静的 SQL をできるだけ使用してください。それは、実行時 SQL セクション準備および未確定カーソルを回避します。動的 SQL の使用が避けられない場合は、 ネットワーク通信量を最小にしてパフォーマンスを改善するために、 以下のことを行うことができます。

その他の SQL 考慮事項

コマンド行プロセッサーを使用すると、一般に、プログラム内に動的 SQL を有する場合より動作が遅くなります。 なぜならコマンド行プロセッサーは、 SQL をデータベース・エンジンへ発信する前に入力を構文解析する必要があるからです。 また、コマンド行プロセッサーは、データを受け取った時にそれを形式化しますが、 アプリケーションにとっては不必要なことです。

インタープリター言語 (たとえば REXX) による SQL ステートメントは、 コンパイル言語 (たとえば C 言語) による同じ SQL ステートメントよりかなり処理が遅くなります。

CONNECT ステートメントについては、 タイプ 1 およびタイプ 2 と呼ばれる 2 つのタイプがあります。 タイプ 2 の接続を使用してデータベースへ接続した場合は、 以前の接続を休止状態にしますが、ドロップはしません。 その後で休止状態の接続に切り換えれば、 ライブラリーのロードおよび内部データ構造のセットアップのオーバーヘッドを避けることができます。 この理由から、タイプ 2 の接続を使用すれば、 複数のデータベースにアクセスするアプリケーションについてはパフォーマンスを改善することができます。 タイプ 2 接続の詳細については、 管理の手引き および SQL 解説書 を参照してください。


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