SQL ステートメントの静的実行と動的実行の違いは、コンパイルされたプログラミング言語とインタープリットされたプログラミング言語で記述された実行中のアプリケーションの間の違いに似ています。コンパイルされた言語を使用する場合、実行可能コードは実行時の前に生成されます。インタープリットされた言語を使用する場合、実行可能コードは実行時に生成されます。インタープリットされた言語の実行と同様、SQL ステートメントの分析とアクセス・プランの作成に関連する CPU コストがかかります。動的 SQL 実行は、アプリケーションのパフォーマンスを低下させる可能性があります。静的と動的の SQL 実行の主な違いは、静的 SQL 実行は、アプリケーションを最終的に実行する前にプログラムの準備とバインドが必要であるという点です。動的 SQL 実行の準備は実行時に行われます。動的 SQL 実行では、実行のたびに PREPARE と DESCRIBE の追加の処理オーバーヘッドが発生する可能性があります。
動的 SQL ステートメント・キャッシュを、SQL ステートメントの PREPARE と DESCRIBE の追加のオーバーヘッドの回避に役立てることができます。 SQL ステートメント・キャッシュは、アプリケーション・サーバーまたは DB2 データベース、またはその両方に置くことができます。ただし、キャッシュのヒット率が高くなった場合、通常は慎重なチューニングが必要になります。キャッシュ・メモリーのスペースを浪費することなくキャッシュ・ヒット率を最大にするには、SQL ステートメントを正しくコード化する必要があります。一般的な環境では、完全な最適化の達成は困難です。
多くの場合、静的 SQL 実行のほうが、より高速なパフォーマンス、より一貫性のある応答時間、および大幅なセキュリティー上の利点を提供することができます。SQL ステートメントは、すべてが DB2 データベース・パッケージにバインドされるため、個々の SQL ステートメントに対するキャッシュ・ミスは発生しません。パッケージに実行権限が与えられるため、基礎となるデータベース・オブジェクトに対する権限をすべてのユーザーに付与する必要はありません。また、静的パッケージ用に定義されたワークロード管理の目的に基づいたリソース割り振りと、パッケージのバインド時に定義されるアクセス・パスが、一貫性のある応答時間の達成に役立ちます。
プロセス・プランによっては、動的な SQL ベースの JDBC アプリケーションと静的な SQL ベースの JDBC アプリケーションの相対的な違いに備えた準備が必要になることがあります。 pureQuery クライアント最適化は新しい用語とツールを取り入れていますが、COBOL や SQLJ アプリケーションなどの従来の静的アプリケーションのデプロイメントの管理という基本的な前提と概念は、pureQuery クライアント最適化を使用した静的アプリケーションにも当てはまります。デプロイメントの成功には、アプリケーションのシナリオによってはデプロイメントに影響する可能性がある多くのオプションと、それらのオプションについて注意深く計画し検討することが必要です。
実行時には、ロケーション名の値が、実行時のアプリケーション接続情報によって決定されます。DB2 for z/OS® のロケーション名は、DB2 for Linux, UNIX, and Windows のデータベース名に相当します。
実行時に、コレクション ID の値を、接続の獲得に使用されるデータ・ソースのプロパティーとして設定できます。アプリケーションでは、CURRENT PACKAGESET または CURRENT PACKAGE PATH 特殊レジスターを設定して、デフォルト値をオーバーライドすることができます。アプリケーションでこれらの特殊レジスターを使用する場合は、パッケージを特殊レジスター設定によって指定されたコレクションにバインドする際に注意を払う必要があります。
pureQueryXML ファイルを構成する際は、pureQuery Configure ユーティリティーの -rootPkgName オプションを付けて SQL ステートメント・セット名を作成するために使用する、基本ストリングを指定します。
実行時には、構成プロセス中に作成されたパッケージ名を変更することはできません。
同じ pureQueryXML ファイルを使用して、異なるターゲット・データベース上にパッケージを作成できます。同じ pureQueryXML ファイルを使用して異なるターゲット・データベース上にパッケージを作成すると、実行時にパッケージを識別するために、異なるターゲット・データベースで同じ整合性トークンが使用されます。
ターゲット・データベース上にパッケージを作成した後で pureQueryXML ファイル内の整合性トークンが変更されると、pureQuery Runtime は、このデータベース上のパッケージを使用して SQL ステートメントを静的に実行することはなくなります。
この値は実行時に修正されます。pureQueryXML ファイルを使用して StaticBinder ユーティリティーを実行することによってデータベースにパッケージを作成した後は、pureQueryXML ファイル内の整合性トークンを変更しないでください。 トークンを変更すると、pureQuery Runtime がファイル内の SQL ステートメントに関連するパッケージを識別できなくなります。
pureQuery Runtime は、SQL ステートメントと SQL 情報 (SQL のストリング、カーソル、および結果セット・タイプ、並行性、保持機能などの prepare 属性など) を比較することによって、SQL ステートメントの静的実行をいつ行うかを決定します。SQL ステートメントの静的実行中に、pureQuery Runtime は、アプリケーションによって発行された SQL ステートメントを、pureQueryXML ファイル内のロケーション、コレクション ID、パッケージ名、および整合性トークン情報にマッピングします。pureQuery Runtime はそのマッピングを使用して、SQL ステートメントを含む DB2 パッケージにアクセスし、SQL ステートメントを静的に実行します。
pureQuery Configure ユーティリティーを使用して、作成する SQL ステートメントを含む DB2 パッケージの特性を指定します。特性には、コレクション ID と、ステートメントが属しているステートメント・セットが含まれます。これらの特性は pureQueryXML ファイルに保管されます。Configure ユーティリティーも、パッケージ情報を含む整合性トークンを保管します。
pureQuery StaticBinder ユーティリティーは、pureQueryXML ファイル内のステートメント・セット名、コレクション ID、および整合性トークンを使用して、DB2 データベース上にパッケージ ID を作成します。 ロケーションは、StaticBinder ユーティリティーを実行するときに指定するターゲット・サーバーによって決定されます。パッケージ名はステートメント・セット名に基づきます。StaticBinder ユーティリティーがステートメント・セット名からパッケージを作成する方法については、Configure ユーティリティー の -rootPkgName オプションを参照してください。
DB2 データベース・サーバー上にパッケージを作成する場合は、Configure ユーティリティーと StaticBinder ユーティリティーを使用します。Configure および StaticBinder オプションを指定して、DB2 データベース・サーバー上のパッケージを管理するためのパッケージ・コレクションとパッケージ・バージョンを作成することができます。