コンパイル済みホスト言語で記述されたアプリケーションを実行するには、データベース・マネージャーが実行時に必要とするパッケージを作成しなければなりません。これには、図 1 で示している以下のステップが含まれます。
この節では、その他にも以下のトピックについて説明します。
SQLJ アプリケーションが必要とするパッケージを作成するには、 SQLJ 変換プログラムと db2profc コマンドが必要です。 SQLJ 変換プログラムの使用に関する詳細については、 SQLJ プログラミングを参照してください。
ソース・ファイルを作成してから、 SQL ステートメントが入っているそれぞれのホスト言語ファイルを、ホスト言語ソース・ファイル用の PREP コマンドを使ってプリコンパイルする必要があります。プリコンパイラーはソース・ファイルに含まれている SQL ステートメントを注釈に変換し、そのステートメントについて DB2 実行時 API 呼び出しを生成します。
アプリケーションをプリコンパイルする前に、明示的または暗黙に、サーバーに接続する必要があります。アプリケーション・プログラムをクライアント・ワークステーションでプリコンパイルして、プリコンパイラーが変更されたソースとメッセージをクライアント上で生成しても、プリコンパイラーはサーバー接続を使用していくらかの妥当性検査を実行します。
さらに、プリコンパイラーは、データベース・マネージャーがデータベースに対する SQL ステートメントを処理する上で必要な情報も作成します。この情報は、選択したプリコンパイラー・オプションによって、パッケージ、バインド・ファイル、またはその両方に保管されます。
プリコンパイラーの使用の一般的な例を以下に示します。 filename.sqc という C 組み込み SQL ソース・ファイルをプリコンパイルするために、以下のコマンドを発行して、省略時名 filename.c の C ソース・ファイルと、省略時名 filename.bnd のバインド・ファイルを作成することができます。
DB2 PREP filename.sqc BINDFILE
プリコンパイラー構文およびオプションの詳細については、 コマンド解説書 を参照してください。
プリコンパイラーは、最大で 4 タイプまでの出力を生成します。
PACKAGE オプションを使用する場合、プリコンパイル処理中に使用するデータベースには、ソース・ファイル内の静的 SQL が参照するデータベース・オブジェクトがすべて含まれていなければなりません。たとえば、SELECT ステートメントは、参照する表がデータベースに入っていない限り、プリコンパイルすることはできません。
PACKAGE を指定せずに、プリコンパイル時にバインド・ファイルを要求すると、パッケージは作成されず、特定のオブジェクトの存在や許可 SQLCODE はエラーではなく警告として扱われます。これにより、参照するオブジェクトが存在しない場合や、プリコンパイルする SQL ステートメントを実行するための許可を持たない場合でも、プログラムをコンパイルしてバインド・ファイルを作成できます。エラーではなく警告として扱われる特定の SQLCODE のリストについては、 コマンド解説書 を参照してください。
ソース・ファイルは必ず、特定のデータベースに対してプリコンパイルしなければなりません。そのデータベースは、最終的にそのアプリケーションとともに使用されることのないデータベースであってもかまいません。実際に、テスト・データベースを開発用に使用することができます。そして、アプリケーションを十分にテストしてから、バインド・ファイルを 1 つまたは複数の製品データベースにバインドすることができます。この機能を使用する別の方法については、バインドの実行据え置きの利点を参照してください。
アプリケーションが使用しているコード・ページがデータベースのコード・ページと異なる場合、プリコンパイル時にどのコード・ページを使用するのかを考慮する必要があります。 異なるコード・ページ間での変換を参照してください。
アプリケーションでユーザー定義関数 (UDF) またはユーザー定義特殊タイプ (UDT) を使用している場合は、アプリケーションをコンパイルする際に FUNCPATH オプションを使用する必要があります。このオプションは、静的 SQL を含むアプリケーションで UDF と UDT を使用できるようにするための関数パスを指定します。 FUNCPATH を指定しない場合、省略時の関数パスは SYSIBM、SYSFUN、USER になります ("USER" は現行のユーザー ID のことです)。バインド・オプションの詳細については、 コマンド解説書 を参照してください。
複数のサーバーにアクセスするアプリケーション・プログラムをプリコンパイルするには、以下のいずれかを行ってください。
アプリケーションが DB2 コネクトを介して AS/400 アプリケーション・サーバーへアクセスするとしても、同じプロシージャーが適用されます。サーバーで使用可能な PREP オプションを使用して、接続する予定のサーバーに対してアプリケーションをプリコンパイルしてください。
DB2 ユニバーサル・データベース (OS/390 版) で稼働するアプリケーションをプリコンパイルしている場合、 SQL ステートメントの構文の検査に標識機能を使用することを考慮してください。標識機能は、DB2 ユニバーサル・データベースでサポートされていても、 DB2 ユニバーサル・データベース (OS/390 版) ではサポートされていない SQL 構文を示します。また標識機能を使用して、作成した SQL 構文が SQL92 Entry Level 構文に従っているかも検査できます。 PREP コマンドの SQLFLAG オプションを使用して、標識機能を呼び出し、比較する DB2 ユニバーサル・データベース (OS/390 版) の SQL 構文のバージョンを指定できます。標識機能を使用しても、必ずしも SQL の使用を変更する必要はありません。これは、構文の不適合に関する通知または警告メッセージを出すだけで、前処理が異常終了することはありません。
PREP コマンドの詳細については、 コマンド解説書 を参照してください。
修正済みソース・ファイルと、SQL ステートメントが含まれていない追加ソース・ファイルを、適切なホスト言語コンパイラーでコンパイルしてください。言語コンパイラーは、それぞれの修正済みソース・ファイルをオブジェクト・モジュール に変換します。
省略時のコンパイル・オプションに対するいくつかの例外に関しては、 アプリケーション構築の手引き、またはご使用のオペレーティング・プラットフォーム用のプログラミング資料などを参照してください。使用可能なコンパイル・オプションの完全な説明については、コンパイラーの資料を参照してください。
ホスト言語リンカーは実行可能アプリケーションを作成します。以下はその例です。
注: | Windows 32 ビット オペレーティング・システム上ではアプリケーションを DLL にすることはできますが、 DLL は DB2 データベース・マネージャーではなく、アプリケーションにより直接ロードされます。 Windows 32 ビット オペレーティング・システム上で、データベース・マネージャーが DLL をロードすることも可能です。ストアード・プロシージャーは、通常は DLL または共用ライブラリーとして作成されます。ストアード・プロシージャーの使用については、 ストアード・プロシージャーを参照してください。 |
DB2 でサポートされているその他のプラットフォームで実行可能ファイルを作成する方法については、 アプリケーション構築の手引き を参照してください。
実行可能ファイルを作成するには、以下のものにリンクします。
バインドとは、データベース・マネージャーがアプリケーションの実行時にデータベースをアクセスするために必要とするパッケージを作成する処理です。バインドは、プリコンパイル中に PACKAGE オプションを指定して暗黙に行うことも、プリコンパイル中に作成されたバインド・ファイルに対して BIND コマンドを使用することにより明示的に行うこともできます。
BIND コマンドの使用の一般的な例を以下に示します。 filename.bnd という名前のバインド・ファイルをデータベースにバインドするには、以下のコマンドを発行することができます。
DB2 BIND filename.bnd
BIND コマンドの構文およびオプションの詳細については、 コマンド解説書 を参照してください。
個別にプリコンパイルされたソース・コード・モジュールごとに 1 つのパッケージが作成されます。アプリケーションに 5 つのソース・ファイルがあって、そのうちの 3 ファイルにプリコンパイルが必要な場合、 3 つのパッケージまたはバインド・ファイルが作成されます。省略時の解釈では、それぞれのパッケージには .bnd ファイルの作成元となったソース・モジュールの名前と同じ名前が付けられますが、8 文字で切り捨てられます。新しく作成されたパッケージの名前が宛先データベースに現在存在しているパッケージの名前と同じ場合、既存パッケージに代わって新規のパッケージが使用されます。異なるパッケージ名を明示的に指定するには、 PREP コマンドの PACKAGE USING オプションを使用しなければなりません。詳細については、コマンド解説書 を参照してください。
アプリケーションのバージョンを複数作成する場合、パッケージの名前を変更して、名前が重複するのを避けてください。たとえば、foo というアプリケーション (foo.sqc からコンパイルされたもの) がある場合、これをプリコンパイルして、アプリケーションの全ユーザーに送ります。ユーザーはアプリケーションをデータベースにバインドして、これを実行します。変更が必要な場合には、続けて foo の新しいバージョンを作成し、このアプリケーションとそのバインド・ファイルを、新しいバージョンを必要とするユーザーに送ります。新しいバージョンのユーザーは foo.bnd をバインドし、新しいアプリケーションは問題なく実行されます。ただし、ユーザーが以前のバージョンのアプリケーションを使おうとすると、 FOO パッケージ上のタイム・スタンプに矛盾が生じ (データベース内のパッケージが実行中のアプリケーションと一致しないことになります)、クライアントを再バインドしなければならなくなります。 (パッケージのタイム・スタンプの詳細については、 タイム・スタンプを参照してください。) 新しいアプリケーションのユーザーは、タイム・スタンプが矛盾していることを通知されます。これは、両方のアプリケーションに同じ名前が使用されているために発生する問題です。
この問題を解決するには、パッケージの名前を変更します。 FOO の最初のバージョンの作成時に、以下のコマンドを使用してこれをプリコンパイルします。
DB2 PREP FOO.SQC BINDFILE PACKAGE USING FOO1
このアプリケーションが配布されると、ユーザーはこのアプリケーションを問題なくバインドおよび実行できます。新しいバージョンを作成する際には、以下のコマンドを使用してこれをプリコンパイルします。
DB2 PREP FOO.SQC BINDFILE PACKAGE USING FOO2
このアプリケーションも、配布後に問題なくバインドおよび実行されます。最初のバージョンのパッケージ名は FOO1 で、新しいバージョンは FOO2 になるので名前は重複せず、どのバージョンのアプリケーションも使用できます。
動的に作成されたステートメントについては、特殊レジスターの数によってステートメントのコンパイル環境が決定されます。
以下の方法の一つを使用すると、アプリケーション内で非修飾表名を処理することができます。
CONNECT TO db_name USER user_name BIND file_name COLLECTION schema_name
上記の例では、db_name はデータベース名、user_name はユーザー名、そして file_name はバインドされるアプリケーション名を表しています。 user_name と schema_name は普通は同じ値です。その後、SET CURRENT PACKAGESET ステートメントを使用して、使用するパッケージ、すなわち使用する修飾子を指定します。その省略時修飾子が、パッケージをバインドするときに使用する許可識別子になります。 SET CURRENT PACKAGESET ステートメントの使用方法の例は、 SQL 解説書 を参照してください。
アプリケーションのコード・ページがデータベースのコード・ページと異なる場合、バインド時にどちらのコード・ページを使用するかを考慮する必要があります。 異なるコード・ページ間での変換を参照してください。
アプリケーションが IMPORT または EXPORT のようなデータベース・マネージャー・ユーティリティー API に呼び出しを発行する場合、提供されるユーティリティー・バインド・ファイルをデータベースにバインドしておくことが必要です。詳細については、ご使用のプラットフォームの概説およびインストール を参照してください。
バインド・オプションを使用して、バインド中に発生する一定の操作を制御することができます。
バインド・オプションについては、 コマンド解説書 の BIND コマンドの節を参照してください。
バインド処理を開始しても応答がない場合、データベースに接続している他のアプリケーションが、必要なロックを保持している可能性があります。この場合には、どのアプリケーションもデータベースに接続されていないことを確認してください。接続されていることがわかったなら、サーバー上のすべてのアプリケーションを切り離して、バインド処理を継続します。
アプリケーションが DB2 コネクトを使用してサーバーにアクセスする場合、そのサーバーで使用可能な BIND オプションを使用できます。 BIND コマンドとそのオプションに関する詳細については、 コマンド解説書 を参照してください。
バインド・ファイルは、以前の DB2 ユニバーサル・データベースのバージョンとの下位互換性はありません。レベルが混合した環境では、 DB2 は最下位レベルのデータベース環境で使用できる機能しか使用できません。たとえば、V5.2 クライアントが V5.0 サーバーと接続している場合、そのクライアントは V5.0 の機能しか使用できません。バインド・ファイルはデータベースの機能を伝えるので、それらは混合レベルの制限に従います。
下位レベルのシステムで、上位レベルのバインド・ファイルを再バインドする必要がある場合は、以下のようにすることができます。
バインドを実行可能にしてプリコンパイルを行うと、アプリケーションはプリコンパイル処理中に使用されたデータベースだけにアクセスできます。バインドを実行据え置きにしてプリコンパイルすると、 BIND ファイルを各データベースにバインドできるので、多数のデータベースにアクセスできます。このアプリケーション開発方法は、アプリケーションを 1 回だけプリコンパイルするという点で本来柔軟性のあるものですが、アプリケーションはデータベースにいつでもバインドすることができます。
実行中に BIND API を使用すると、アプリケーションはそれ自体をバインドすることができます。これはおそらく導入手順の一部として、または関連モジュールが実行される前に行われます。たとえば、アプリケーションは複数のタスクを実行することができますが、そのうちで SQL ステートメントを使用する必要があるのは 1 つだけです。アプリケーションは、SQL ステートメントを必要とするタスクが呼び出されるとき、および関連パッケージが存在しない場合にだけ、それ自体をデータベースにバインドできるように設計することができます。
バインドの実行据え置きのもう 1 つの利点は、エンド・ユーザーにソース・コードを提供しなくてもパッケージを作成できるという点です。関連したバインド・ファイルをアプリケーションと共に搬出することができます。
DB2 バインド・ファイル記述 (db2bfd) ユーティリティーを使用することにより、バインド・ファイルを作成するのに使用するプリコンパイル・オプションを表示するだけでなく、バインド・ファイルの内容を簡単に表示して、ファイル内部の SQL ステートメントを調査および検証することができます。これは、アプリケーションのバインド・ファイルに関連する問題の判別に役立ちます。
db2bfd ユーティリティーは、インスタンスの sqllib ディレクトリー内にある bin サブディレクトリーに入っています。
構文は以下のとおりです。
.--------------. V (1) | (5) >>-db2bfd----+--h------+--+---filespec------------------------->< | (2) | +--b------+ | (3) | +--s------+ | (4) | '--v------'
注:
db2bfd の詳細については、コマンド解説書 を参照してください。
パッケージはデータベースに保管されたオブジェクトで、単一のソース・ファイル内の特定の SQL ステートメントを実行するために必要な情報を含んでいます。データベース・アプリケーションは、そのアプリケーションを作成するのに使用するプリコンパイルされたすべてのソース・ファイルに対して、 1 つのパッケージを用います。それぞれのパッケージは個別のエンティティーであり、同じアプリケーションまたは他のアプリケーションで使用される別のパッケージとは関係ありません。パッケージを作成するには、バインドを実行可能にしてソース・ファイルに対してプリコンパイラーを実行するか、 1 つまたは複数のバインド・ファイルで後からバインダーを実行します。
データベース・アプリケーションはパフォーマンスの向上とサイズを小さくするためにパッケージを使用しますが、これはアプリケーションをコンパイルする理由と同じものです。 SQL ステートメントをプリコンパイルすることによって、このステートメントはアプリケーションの実行時ではなく作成時にコンパイルされてパッケージとなります。それぞれのステートメントが構文解析され、さらに効率的に解釈されたオペランド・ストリングがパッケージに保管されます。実行時に、プリコンパイラーにより生成されるコードにより、入出力データに必要な変数情報を指定した実行時サービス・データベース・マネージャー API が呼び出され、パッケージに保管されている情報が実行されます。
プリコンパイルの利点は静的 SQL ステートメントにだけ当てはまります。動的に実行される SQL ステートメント (PREPARE と、EXECUTE か EXECUTE IMMEDIATE を用いる) はプリコンパイルされません。したがって、一連の処理手順全体を実行時に行わなければなりません。
注: | SQL ステートメントの静的 SQL は、動的に処理される同じステートメントよりも自動的に速く実行されるとは考えないでください。動的ステートメントの準備にはオーバーヘッドが必要なため、静的 SQL の方が速く実行されます。それ以外の場合は、最適化プログラムがバインド時以前に使用可能なデータベース統計ではなく、現行のデータベース統計を使用できるので、動的に作成された同じステートメントのほうが速く実行されます。トランザクションの完了にかかる時間が 2 秒未満である場合は、一般に静的 SQL の方が速くなります。使用する方式を選択するために、両方のバインド方式をプロトタイプ化してください。静的および動的 SQL の詳細な比較は、動的 SQL と静的 SQL との比較を参照してください。 |
パッケージまたはバインド・ファイルを生成すると、プリコンパイラーはタイム・スタンプを生成します。タイム・スタンプはバインド・ファイルまたはパッケージ、および修正済みソース・ファイルに保管されます。
バインドを実行可能にしてアプリケーションをプリコンパイルすると、タイム・スタンプが一致するパッケージと修正済みソース・ファイルが生成されます。アプリケーションを実行する際に、タイム・スタンプが等しいかどうか検査されます。アプリケーションを実行するには、アプリケーションとその関連パッケージのタイム・スタンプが一致していなければなりません。そうしないと、SQL0818N エラーがアプリケーションに戻されます。
アプリケーションをデータベースにバインドする場合、 PREP コマンドの PACKAGE USING オプションを使用して省略時値を指定変更しない限り、アプリケーション名の最初の 8 文字がパッケージ名として使用されることを覚えておいてください。つまり、同じ名前の 2 つのプログラムをプリコンパイルしてバインドすると、 2 番目のプログラムが最初のパッケージを上書きします。最初のプログラムを実行すると、そのプログラムでは修正済みソース・ファイルのタイム・スタンプとデータベースのパッケージのタイム・スタンプとが一致していないため、タイム・スタンプ・エラーになります。
バインドを実行据え置きにしてアプリケーションをプリコンパイルすると、タイム・スタンプが一致する 1 つまたは複数のバインド・ファイルおよび修正済みソース・ファイルが生成されます。このアプリケーションを実行するには、アプリケーション・モジュールにより作成されるバインド・ファイルを実行します。バインド処理は、バインドで説明しているように、バインド・ファイルごとに行わなければなりません。
バインド・ファイルには、プリコンパイル中に修正済みソース・ファイルに保管されたタイム・スタンプと同じものが入っているため、アプリケーションとパッケージのタイム・スタンプは一致します。
再バインド は、以前にバインドされたアプリケーション・プログラムのパッケージを作成する処理です。パッケージが無効、または作動不能と示された場合は、これを再バインドしなければなりません。しかし、パッケージが有効であっても再バインドが必要な場合もあります。たとえば、新規に作成された索引を利用する場合、または RUNSTATS コマンドの実行後の更新統計を利用する場合です。
パッケージは、表、視点、別名、索引、トリガー、参照制約、および表検査の制約など、データベース・オブジェクトの一定のタイプに従属させることができます。パッケージがデータベース・オブジェクト (表、視点、トリガーなど) に従属している場合にそのオブジェクトが除去されると、パッケージは無効 な状態になります。除去されたオブジェクトが UDF である場合、パッケージは作動不能 状態になります。詳細については、管理の手引き: 計画 を参照してください。
無効なパッケージは、実行される際にデータベース・マネージャーによって暗黙に (つまり自動的に) 再バインドされます。作動不能パッケージは、 BIND コマンドまたは REBIND コマンドのいずれかを実行して、明示的に再バインドしなければなりません。暗黙の再バインドに失敗すると、予期しないエラーが生じる場合があることに気を付けてください。つまり、暗黙の再バインドのエラーは、実際にエラーのあるステートメントではなく実行中のステートメントに戻される場合もあります。作動不能パッケージを実行しようとすると、エラーが発生します。無効なパッケージをシステムで自動的に再バインドするのではなく、これらを明示的に再バインドすることができます。これにより、いつ再バインドを行うかを制御できるようになります。
パッケージを明示的にバインドするために使用するコマンドは、状況により異なります。 SQL ステートメントの数を変更するか、または変更された SQL ステートメントを含めるために修正されたプログラムのパッケージを再バインドするには、 BIND コマンドを使用しなければなりません。パッケージが最初にバインドされた変数からバインド・オプションを変更する必要がある場合にも、 BIND コマンドを使用します。その他の場合には、 BIND コマンドと REBIND コマンドのいずれかを使用してください。パフォーマンスの面では BIND よりも REBIND の方が優れているので、特に BIND を使用する必要がないときは REBIND を使用してください。
REBIND コマンドの詳細については、 コマンド解説書 を参照してください。