RELEASE バインド・オプション
RELEASE オプションは、プログラムが使用するリソースをいつ解放するかを判別します。各コミット・ポイント、あるいはプログラムの終了時のいずれかです。
RELEASEオプションは、特定の例外を除いて一般的にRELEASE(COMMIT)の動作を使用する多くの動的SQLステートメントには影響を与えません。 詳細は、「動的SQL文とRELEASE(DEALLOCATE)オプション 」を参照してください。
| コマンド・オプション | オプションの値 | と併用 |
|---|---|---|
| RELEASE |
|
RELEASE(INHERITFROMPLAN)オプションは、ネイティブRESTサービスのパッケージのリバインドには有効ではありません。- RELEASE バインドオプションは、ネイティブSQLプロシージャまたはアドバンスト・トリガのパッケージのREBINDには有効ではありません。
パーティション・ロックはテーブル・スペース・ロックと同じ規則に従います。テーブル・スペースのすべてのパーティション・ロックは同じ期間保持されます。 したがって、あるパッケージがRELEASE(COMMIT)を使用し、別のパッケージがRELEASE(DEALLOCATE)を使用している場合、テーブル空間のすべてのパーティションロックはRELEASE(DEALLOCATE)を使用します。
RELEASEオプションは、ページ・ロック、行ロック、LOBロック、XMLロックには影響しません。
オプションの説明 RELEASE
- RELEASE（ 専念 ）
- Db2 カーソルが保持されていない限り、コミットポイントごとにリソースを解放します。 アプリケーションがオブジェクトに再びアクセスする場合、そのアプリケーションは再びロックを獲得しなければなりません。
カーソルが WITH HOLD で定義されていない場合は、 次のコミット・ポイントで表、パーティション、または表スペースのロックが解放されます。 WITH HOLDオプションで定義されたカーソルは例外であり、カーソル位置を維持するために必要なロックはコミットポイントを過ぎても保持されます。
RELEASE（COMMIT）オプションが有効な場合、添付機能によってロックの解除タイミングが異なります
環境 リリース条件 TSO、バッチ、および CAF SQLのCOMMITまたはROLLBACKステートメントが発行されるか、アプリケーションプロセスが終了します。 IMS CHKPまたはSYNCコール（シングルモードトランザクション用）、I/O PCBへのGUコール、またはROLLまたはROLBコールが完了します。 CICS SYNCPOINT コマンドが出された場合。 RELEASE(COMMIT)オプションが有効な状態で取得されたロックは、アプリケーションがRELEASE(DEALLOCATE)オプションが有効なパッケージからその後のステートメントを発行すると、割り当て解除期間に昇格される場合があります。 詳細は、「複数のパッケージと混合されたRELEASEオプションを持つアプリケーション 」を参照してください。
- RELEASE(DEALLOCATE)
RELEASE(DEALLOCATE)オプションが有効になっている場合、 Db2 は通常、スレッドが終了したときにのみロックやその他のリソースを解放します。
ただし、特定の状況や設定では、RELEASE（DEALLOCATE）オプションが適用されない、またはリリース動作が変更される例外があります。 詳しくは、以下のセクションを参照してください。
- 動的SQL文とRELEASE(DEALLOCATE)オプション
- 配布パッケージとRELEASE(DEALLOCATE)オプション
- RELEASE（DEALLOCATE）オプションの初期化
- 一時テーブルの宣言とRELEASE(DEALLOCATE)オプション
- ロック降格とRELEASE（DEALLOCATE）オプション
RELEASE（DEALLOCATE）オプションは、パッケージまたはプランに常駐するアイテムが増えるため、パッケージまたはプランのサイズが大きくなる可能性があります。
- RELEASE(INHERITFROMPLAN)
- パッケージがリモートでバインドされたか、ローカルでバインドされたかに関係なく、ローカル・パッケージは、プランの RELEASE オプションの値を継承します。
RELEASE(INHERITFROMPLAN) オプションを使用してパッケージをリモートにバインドし、リモート・サーバーが INHERITFROMPLAN 値を認識しない場合には、サーバーがエラーを戻す場合があります。
関連する計画が存在しないため、次の状況ではRELEASE(INHERITFROMPLAN)オプションは適用されません
- アプリケーションをローカルでバインドし、その後パッケージをリモートサーバーにコピーする場合は、
- RRSAF を使用するアプリケーションをバインドする場合。
- ユーティリティ用に作成されたパッケージ。
これらの場合、RELEASE(COMMIT) がパッケージに対して有効になります。
デフォルト RELEASE
| 処理 | デフォルトの 値 |
|---|---|
| BIND SERVICE | COMMIT |
| BIND PLAN | COMMIT |
| BIND PACKAGE |
|
| REBIND PLAN | 既存の値 |
| REBIND PACKAGE | 既存の値 |
| REBIND TRIGGER PACKAGE | 既存の値 |
複数のパッケージと混合されたRELEASEオプションを持つアプリケーション
アプリケーションが複数のパッケージから異なるRELEASEバインドオプションでステートメントを発行する場合、アプリケーションプロセスで実際に適用されるRELEASEオプションは変更される可能性があります。 つまり、ロックはまずRELEASE(COMMIT)の期間で取得されるが、アプリケーションが異なるパッケージからのRELEASE(DEALLOCATE)オプション付きのステートメントを実行すると、後にRELEASE(DEALLOCATE)に昇格される可能性がある。
複数のパッケージからのステートメントで同じ表スペースに対するパーティション・ロックが獲得された場合、すべてのパーティション・ロックが同じ期間保持されます。 テーブルスペースに最初にアクセスするステートメントが、RELEASE(COMMIT)バインド・オプションを使用するパッケージからのものである場合、すべてのパーティション・ロックはRELEASE(COMMIT)のルールに従います。 しかし、RELEASE(DEALLOCATE)バインドオプションを使用する別のパッケージからのその後のステートメントが、同じテーブル空間のパーティションにアクセスすると、すべてのパーティションロックがRELEASE(DEALLOCATE)ルールに従うように昇格されます。
動的SQL文とRELEASE(DEALLOCATE)オプション
- RELEASE(DEALLOCATE) および KEEPDYNAMIC(YES) を使用し、CACHEDYN サブシステム・パラメーターを YES に設定してサブシステムがインストールされ、動的 SELECT、INSERT、UPDATE、DELETE の各ステートメントに対して RELEASE(DEALLOCATE) オプションが有効な場合。 詳細は、「CACHE DYNAMIC SQL フィールド（CACHEDYN サブシステムパラメータ ）」および 「KEEPDYNAMIC バインドオプション 」を参照してください。
- RELEASE(DEALLOCATE) を使用し、準備済み INSERT、UPDATE、DELETE、MERGE の各動的ステートメントが宣言済み一時表を参照し、コミット・ポイントを過ぎて保持されている場合 (ただし、ON COMMIT DROP TABLE オプションで表が定義されている場合を除く)。 詳細は、「宣言された一時テーブルとRELEASE(DEALLOCATE)オプション 」を参照してください。
動的ステートメントについて獲得されるロックは、 以下のいずれかのイベントが発生するまで保留されます。
- 申請プロセスが終了（割り当て解除）します
- アプリケーションが、同じステートメント ID を指定した PREPARE ステートメント を出す。 (ロックは次のコミット・ポイントで解放される)
- ステートメントが使用されなかったため、キャッシュから削除される。 (ロックは次のコミット・ポイントで解放される)
- ステートメントが従属しているオブジェクトがドロップされるか変更される、もしくはステートメントが必要とする特権が取り消される。 (ロックは次のコミット・ポイントで解放される)
配布パッケージとRELEASE(DEALLOCATE)オプション
クライアントシステムとのDRDA接続を通じて Db2 サーバー上で実行されるパッケージは、ほとんどの状況でRELEASE(DEALLOCATE)オプションを適用することができます。 ただし、 Db2 サーバーでMODIFY DDF PKGREL(COMMIT)コマンドが発行された場合、そのサーバーでクライアントシステムとの接続により実行されるパッケージに対しては、RELEASE(DEALLOCATE)オプションは影響しません。
詳細については、「高性能 DBAT の削除制御 」および「.」を参照してください。
RELEASE（DEALLOCATE）オプションの初期化
特定の状況下では、 Db2 はロックやその他のリソースを解放し、DDL文などのプロセスがパッケージやカタログへのアクセスを必要とする際に割り込めるようにすることができます- アクティブ・スレッドの割り込み
PKGREL_COMMIT サブシステム・パラメーター設定がデフォルト値の YES の場合、特定の操作がパッケージへの排他的アクセスを待機していると、Db2 スレッドは COMMIT または ROLLBACK 時にアクティブ・パッケージを解放します。
RELEASE(DEALLOCATE) オプションを指定してバインドされたパッケージの場合、パッケージがアクティブで、永続Db2スレッドに割り振られている間は、以下の操作が COMMIT または ROLLBACK に進行することができます。
- BIND REPLACE PACKAGE および REBIND PACKAGE 要求、パッケージによって静的に参照される表および索引に対するオンライン・スキーマ変更 (DDL ステートメント) の自動再バインドを含む
- パッケージが静的に参照するオブジェクトのペンディングの定義変更をマテリアライズするオンライン REORG 操作。
YES はデフォルト値です。
詳細は、 PKGREL_COMMITサブシステム・パラメータのパッケージ・リリース・コミット・フィールドを参照してください。
- アイドル・スレッドの割り込み
- パッケージロックがタイムアウトしそうな場合、 Db2 は、 CICS®、 IMS、RRSAFなどのローカルアタッチメント機能を使用するアイドルスレッドをリサイクルします。 次の特性を持つスレッドは再利用可能です。
- トランザクション境界にある
- Db2 で実行されていない
- 最近コミットもロールバックも実行されていない
一時テーブルの宣言とRELEASE(DEALLOCATE)オプション
RELEASE(DEALLOCATE) を指定すると、宣言済み一時表を参照する一部の静的および動的ステートメントもコミット・ポイント間で準備済みのステートメントとして保持されます。 ただし、ON COMMIT DROP TABLE オプションを使用して表が定義されている場合は例外です。 コミットポイント全体で準備されたままの状態のステートメントは、INSERT、UPDATE、DELETE、MERGE、およびSELECT INTOステートメントです。 以下のいずれかの条件に該当する場合、ステートメントはコミット・ポイント間で保持されません。
- ON COMMIT DROP TABLE オプションで、宣言済みグローバル一時表が定義されている。
- このステートメントは、 Db2 ベースオブジェクト（テーブルやビューなど）を参照しており、以下のいずれかのステートメントが真である
- 基本オブジェクト参照は、 Db2 カタログテーブル用です。
- コミットポイントで、 Db2 は、ベースオブジェクトのデータベース記述子（DBD）に対するX-ロックを待っている別の Db2 スレッドがあることを認識します。
- このステートメントはXML関数または操作を参照しており、コミットポイントで Db2 はXML操作のベースオブジェクトDBD S-ロックを解放する必要があると判断します。
- コミットポイントにおいて、 Db2 は、ステートメントで使用されているベースオブジェクトDBD S-ロックを解放する必要があり、コミットポイントをまたいで維持することはできないと判断します。
- Db2 別の スレッドが、そのステートメントを含む パッケージのX-lockを待っていることを決定します。 Db2 Db2
ロック降格とRELEASE（DEALLOCATE）オプション
コミット後にロックが保持される場合、それがセグメント化されたテーブルスペース内のテーブルスペースまたはテーブル上のS、SIX、またはXロックである場合、 Db2 はコミット時にそのロックを意図ロック（IXまたはIS）に降格させることがあります。 Db2 次の理由で取得された総ロックを降格させます
- Db2 ロックエスカレーションにより、グロスロックを取得した。
- アプリケーションが一括削除 (WHERE 文節または TRUNCATE の指定がない DELETE FROM object) を発行した場合。
カタログレコード RELEASE
SYSPACKAGE カタログテーブルおよび SYSPLAN カタログテーブルのRELEASE列を参照してください。