アプリケーション開発の手引き

動的 SQL の使用目的

動的 SQL は以下の場合に使用します。

動的 SQL サポート・ステートメント

動的 SQL サポート・ステートメントは、文字ストリング・ホスト変数とステートメント名を引き数として受け入れます。ホスト変数には、テキスト形式で動的に処理される SQL ステートメントが入っています。ステートメント・テキストは、アプリケーションのプリコンパイル時には処理されません。実際、ステートメント・テキストは、アプリケーションのプリコンパイル時には必要ありません。その代わりに、SQL ステートメントはプリコンパイルの段階でホスト変数とみなされ、その変数はアプリケーションを実行する間参照されます。このような SQL ステートメントを動的 SQL と呼びます。

動的 SQL サポート・ステートメントでは SQL テキストが入っているホスト変数を実行可能形式に変換し、ステートメント名を参照して操作しなければなりません。それらのステートメントは以下のとおりです。

EXECUTE IMMEDIATE
ホスト変数を使用しないステートメントを準備し実行します。アプリケーション内のすべての EXECUTE IMMEDIATE ステートメントは、実行時には同じ場所にキャッシュされるため、最後のステートメントのみが認識されます。このステートメントは PREPARE および EXECUTE ステートメントの代用として使います。

PREPARE
SQL ステートメントの文字ストリング式をステートメントの実行可能書式に変換し、ステートメント名を割り当て、任意選択でそのステートメントに関する情報を SQLDA 構造に入れます。

EXECUTE
前に準備した SQL ステートメントを実行します。このステートメントは、接続内で繰り返し実行することができます。

DESCRIBE
準備済みステートメントに関する情報を SQLDA に入れます。

アプリケーションは、ほとんどの SQL ステートメントを動的に実行することができます。サポートされている SQL ステートメントの全リストについては、 表 37 を参照してください。
注:動的 SQL ステートメントの内容は、静的 SQL ステートメントの場合と同じ構文に従っていますが、以下の点が異なります。
  • 注釈は使用できない。
  • ステートメントの先頭に EXEC SQL を使用してはならない。
  • ステートメントをステートメント終了記号で終了してはならない。これに対する例外は CREATE TRIGGER ステートメントで、このステートメントの場合はセミコロン (;) を入れることができます。

動的 SQL と静的 SQL との比較

パフォーマンスのために静的 SQL または動的 SQL のどちらを使用するかは、プログラマーにとって常に関心の高い問題です。もちろんこれは、ユーザーの状態に基づいて決定されます。静的 SQL と動的 SQL のどちらを使用するかを決めるときには、 表 6 を参考にしてください。セキュリティーなどの問題は静的 SQL に影響を与えますし、 DB2 CLI を使用するか CLP を使用するかなどの環境の問題は、動的 SQL に影響を与えます。

決定する際には、ある特定の状況下で静的 SQL または動的 SQL のどちらを選んだらよいかに関して、以下の提案を考慮してください。次の表に「両方」とある場合は、静的 SQL と動的 SQL のどちらでも変わりがないことを示します。この情報はあくまでも一般的な提案に過ぎないことに注意してください。どちらを選ぶにしても、ご使用のアプリケーションの本来の用途や作業環境を考慮に入れる必要があります。はっきりしない場合は、まずステートメントを静的 SQL としてプロトタイプ化してから、次に動的 SQL としてプロトタイプ化し、その違いを比較することが最善の方法です。

表 6. 静的 SQL と動的 SQL の比較
考慮事項 推奨 SQL
SQL ステートメントを実行する時間
  • 2 秒未満
  • 2〜10 秒
  • 11 秒以上
  • 静的
  • 両方
  • 動的
データの均一性
  • データ配分が均一
  • やや不均一
  • 非常に不均一な配分
  • 静的
  • 両方
  • 動的
範囲 (<、>、BETWEEN、LIKE) 述部
  • 非常に少ない
  • 随時
  • 頻繁
  • 静的
  • 両方
  • 動的
繰り返し実行
  • 何回も実行 (10 回以上)
  • 少数回実行 (10 回未満)
  • 1 回だけ実行
  • 両方
  • 両方
  • 静的
照会の種類
  • ランダム
  • 永久的
  • 動的
  • 両方
実行時環境 (DML/DDL)
  • トランザクション処理 (DML のみ)
  • 混合 (DML および DDL - DDL はパッケージに影響を及ぼす)
  • 混合 (DML および DDL - DDL はパッケージに影響を及ぼさない)
  • 両方
  • 動的
  • 両方
RUNSTATS の使用頻度
  • 非常にまれ
  • 普通
  • 頻繁
  • 静的
  • 両方
  • 動的

一般に、動的 SQL を使用したアプリケーションは、使用前に SQL ステートメントをコンパイルする必要があるため、 SQL ステートメント当たりの始動 (初期) コストが大きくなります。コンパイルを行うと、動的 SQL の実行時間は静的 SQL の場合と同じですが、最適化プログラムがより優れたアクセス・プランを選択することによりもっと速くなることがあります。初期のコンパイル・コストは、動的ステートメントを実行するたびに低減されます。複数のユーザーが同じステートメントを用いて同じアプリケーションを実行しているなら、ステートメントを発行した最初のアプリケーションだけにステートメントのコンパイル・コストが生じます。

DML と DDL が混在している環境では、アプリケーションの実行中にシステムがステートメントを暗黙のうちに再コンパイルすることがあるため、動的 SQL ステートメントのコンパイル・コストが変わる可能性があります。混合環境では、静的 SQL と動的 SQL との間の選択はパッケージが無効にされる頻度にも影響してきます。 DDL によってパッケージが無効にされる場合は、動的 SQL のほうが便利でしょう。実際に実行する照会だけが次回の使用時に再コンパイルされ、その他の照会は再コンパイルされないからです。静的 SQL の場合は、いったん無効にされるとパッケージ全体が再バインドされます。

特定のアプリケーションが上記の特性の混合したものであり、一方の特性には静的 SQL が適しており、他方の特性には動的 SQL が適していることがあります。この場合、明確な決定方法はありませんので、最も慣れていて使用しやすい手法を用いてください。前の表の考慮事項は、重要性の高い順におおまかに掲載してあることに注意してください。
注:静的および動的 SQL はそれぞれ、DB2 最適化プログラムにとって重要な 2 種類に分けられます。それらは以下のとおりです。

  1. ホスト変数を含まない静的 SQL

    これは、以下の場合にしか見られない、まれな状態です。

    実際これは、実行時のパフォーマンスのオーバーヘッドがなく、 DB2 最適化プログラムの機能を十分に活用しているため、パフォーマンスの観点からは最善の組み合わせです。

  2. ホスト変数を含む静的 SQL

    これは DB2 アプリケーションの従来の継承 スタイルです。ステートメントのコンパイル中に獲得する PREPARE およびカタログ・ロックの実行時オーバーヘッドがなくなります。最適化プログラムは SQL ステートメント全体を認識しないため、残念ながら、最適化プログラムの全性能を活用することはできません。高度に均一化されていないデータ配分の場合には、特殊な問題があります。

  3. パラメーター・マーカーを含まない動的 SQL

    これはランダム照会インターフェース (CLP など) 用の標準的なスタイルで、最適化プログラムに好まれるタイプの SQL です。複雑な照会の場合は、 PREPARE ステートメントにオーバーヘッドがあると実行時間が短縮されるという利点があります。パラメーター・マーカーに関する詳細については、 パラメーター・マーカーの使用を参照してください。

  4. パラメーター・マーカーを含む動的 SQL

    これは CLI アプリケーション用の最も一般的なタイプの SQL です。主な利点は、パラメーター・マーカーがあるために、 PREPARE ステートメント (主に選択または挿入) を繰り返し実行するうちに、 PREPARE ステートメントのコストを償却できるという点です。この償却は、すべての反復性のある動的 SQL アプリケーションに当てはまります。残念なことに、ホスト変数を含む静的 SQL と同様に、 DB2 最適化プログラムの一部は、情報のすべてを利用することができないために作動しません。最も効率的な方法としては、 ホスト変数を指定して静的 SQL を使用すること または パラメーター・マーカーなしで動的 SQL を使用すること をお勧めします。


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