ストアード・プロシージャーは、FENCED または NOT FENCED ストアード・プロシージャーとして実行できます。どちらとして実行するかは、CREATE PROCEDURE ステートメントに FENCED として登録したか、それとも NOT FENCED として登録したかによって決まります。
NOT FENCED ストアード・プロシージャーは、データベース・マネージャーと同じアドレス空間 (DB2 エージェントのアドレス空間) で実行されます。ストアード・プロシージャーを NOT FENCED として実行すると、 FENCED ストアード・プロシージャーとして実行した場合に比べてパフォーマンスが向上します。なぜなら、FENCED ストアード・プロシージャーは省略時では特殊な DB2 プロセスで実行されるからです。このプロセスのアドレス空間は DB2 システム・コントローラーとは異なります。
注:
デバッグを目的とする場合は、ローカルな FENCED ストアード・プロシージャー を使用することを検討してください。ローカルの FENCED プロシージャーは、 PARAMETER STYLE DB2DARI プロシージャーです。ローカルの FENCED プロシージャーを呼び出すには、 CALL <library-name>!<entry-point> を出します。ここで、 library-name は共用ライブラリーの名前を表し、 entry-point はストアード・プロシージャーの共用ライブラリーの入り口点を表します。共用ライブラリーと入り口点の名前が同じ場合には、 CALL <entry-point> を出すことができます。
NOT FENCED および通常の FENCED ストアード・プロシージャーでは、デバッガーが余分なアドレス空間にもアクセスするので、デバッグ活動は複雑になります。ローカルな FENCED ストアード・プロシージャーはアプリケーションのアドレス空間で実行されるので、デバッガーはアプリケーション・コードとストアード・プロシージャー・コードの両方にアクセスできます。ローカルな FENCED ストアード・プロシージャーをデバッグに使用できるようにするには、以下のステップを実行してください。
注: | ローカルな FENCED ストアード・プロシージャーをデバッグする際には、 制約事項にリストされた制約事項に違反したステートメントを使用しないように、注意する必要があります。 DB2 は、ローカルな FENCED ストアード・プロシージャーに対する呼び出しを、クライアント・アプリケーションのサブルーチンへの呼び出しと見なします。したがって、ローカルな FENCED ストアード・プロシージャーには、通常のストアード・プロシージャーに対する制約事項に違反するステートメントを含めることもできます。たとえば、プロシージャー本体に CONNECT ステートメントを含めることができます。 |
NOT FENCED ストアード・プロシージャーを作成する場合は、使用するオペレーティング・システムによっては、それがスレッド環境で実行されることもあるので注意が必要です。したがって、ストアード・プロシージャーは、これらの変数へのアクセスが直列化するように、常に再入可能であるかまたはその静的変数を管理するものでなければなりません。
注: | ストアード・プロシージャーでは静的データを使用することはできません。なぜなら、DB2 はストアード・プロシージャー内の静的データがそれ以降の呼び出しで再度初期化されたかどうかを保証できないからです。 |
NOT FENCED ストアード・プロシージャーは、必ず WCHARTYPE NOCONVERT オプションを使用して作成してください。詳細については、C および C++ での WCHARTYPE プリコンパイラー・オプションを参照してください。
DB2 は、NOT FENCED ストアード・プロシージャーでは以下に示す機能をサポートしていません。
以下の DB2 API およびすべての DB2 CLI API は、 NOT FENCED ストアード・プロシージャーではサポートされません。