REBIND コマンド

REBIND コマンドは、バインド・ファイルを用いずに、 データベースに保管されているパッケージを再作成できるようにします。

許可

以下の権限のいずれか。
  • DBADM 権限
  • スキーマに対する ALTERIN 特権または SCHEMAADM 権限
  • パッケージに対する BIND 特権

SYSCAT.PACKAGES システム・カタログ表の BOUNDBY 列に記録した許可 ID は、 パッケージの最新のバインド・プログラムの ID であり、再バインド用のバインド・プログラム許可 ID として使用されます。 また、パッケージの表参照のためのデフォルト・スキーマとしても使用されます。 このデフォルト修飾子は、ユーザーが実行する再バインド要求の許可 ID と異なっていても問題ありません。 REBIND は、パッケージの作成時に指定されたのと同じ BIND オプションを使用します。

必要な接続

データベース。 データベース接続が存在しない場合で、暗黙の接続が有効な場合には、デフォルト・データベースへの接続が行われます。

コマンド構文

構文図を読むビジュアル構文図をスキップREBINDPACKAGEパッケージ名VERSIONバージョン名APREUSEYESNORESOLVEANYCONSERVATIVEREOPTNONEONCEALWAYSFUNCPATH,schema-name

コマンド・パラメーター

PACKAGE パッケージ名
再バインドされるパッケージを指定する修飾されている、または修飾されていない名前。
VERSION バージョン名
再バインドするパッケージのバージョン。 バージョンが指定されない場合は、"" (空ストリング) と見なされます。
APREUSE
静的 SQL アクセス・プランが再使用されるかどうかを指定します。 このオプションが有効である場合、照会コンパイラーは、再バインド時および将来の暗黙および明示の再バインド時に、既存のパッケージ内の静的 SQL ステートメントにアクセス・プランを再使用しようとします。 デフォルトは、BIND コマンドまたは REBIND コマンド、あるいは ALTER PACKAGE ステートメントの以前の呼び出し時に使用された値です。 この値を判別するには、SYSCAT.PACKAGES 内のパッケージの APREUSE 列を照会します。
はい
照会コンパイラーは、パッケージ内のステートメントにアクセス・プランを再使用しようとします。
いいえ
照会コンパイラーは、パッケージ内のステートメントにアクセス・プランを再使用しようとしません。
RESOLVE
パッケージの再バインドの実行に、 従来のバインド・セマンティクスを使用するかどうかを指定します。 これは、解決に SQL パスを使用する新しいオブジェクトが、パッケージ内の静的 DML ステートメントの解決時に考慮されるかどうかに影響します。 このオプションは DRDA ではサポートされません。 有効な値は以下のとおりです。
ANY
オブジェクト解決にその SQL パスを使用するオブジェクトに対する参照を解決するのに、SQL パスにあるすべての可能な組み合わせが考慮されます。 従来のバインド・セマンティクスは使用されません。 これがデフォルトです。
CONSERVATIVE
オブジェクト解決に SQL パスを使用するオブジェクトに対する参照を解決するのに、最後の明示的バインドのタイム・スタンプより前に定義された SQL パスのオブジェクトのみが考慮されます。 従来のバインド・セマンティクスを使用します。 このオプションは、作動不能パッケージではサポートされていません。
REOPT
Db2® にホスト変数、パラメーター・マーカー、グローバル変数、および特殊レジスターの値を使用してアクセス・パスを最適化させるかどうかを指定します。
NONE
ホスト変数、パラメーター・マーカー、グローバル変数、または特殊レジスターを含む SQL ステートメントのアクセス・パスは、 これらの変数の実際の値によって最適化されません。 その代わりに、これらの変数のデフォルトの推定値が使用され、このプランがキャッシュされて使用されます。 これがデフォルトの動作です。
ONCE
最初に照会が実行されるときに、ホスト変数、パラメーター・マーカー、グローバル変数、または特殊レジスターの実際の値によって、SQL ステートメントのアクセス・パスが最適化されます。 このプランがキャッシュされて使用されます。
ALWAYS
毎回の実行時に、ホスト変数、パラメーター・マーカー、グローバル変数、 または特殊レジスターの既知の値によって、 SQL ステートメントのアクセス・パスが必ずコンパイルおよび再最適化されます。
FUNCPATH
静的 SQL で、ユーザー定義の特殊タイプおよび機能を解析する際に使用する関数パスを指定します。 デフォルトは、そのパッケージに対して前回 BIND コマンドまたは REBIND コマンドが呼び出されたときに使用された値です。 この値を調べるには、SYSCAT.PACKAGES ビューで該当パッケージの FUNC_PATH 列を照会してください。
スキーマ名
SQL ID (通常または区切り)。 これは、アプリケーション・サーバーに存在するスキーマを識別します。 スキーマが存在する場合、プリコンパイル時やバインド時に妥当性検査は行われません。 同じスキーマを関数パス内で 2 回以上使用することはできません。 SYSPUBLIC スキーマ名は関数パスには指定できません。 指定できるスキーマの数は、最終的な関数パスの長さ (2048 バイト以下) により制限されます。 SYSIBM スキーマを指定する必要はありません。これを関数パスに含めない場合、SYSIBM スキーマが最初のスキーマであると仮定されます。

使用上の注意

再バインドが正常に行われても、 REBIND がトランザクションを自動的にコミットすることはありません。 ですから、ユーザー自身がトランザクションを明示的にコミットする必要があります。 しかし、このことにより「what if」分析が可能になります。 つまり、特定の統計を更新した後、 変更した内容を見るためにパッケージの再バインドを試行できるようになります。 さらに、1 作業単位内で複数の再バインドを実行することも可能になります。

REBIND コマンドは、自動コミットが有効な場合には、トランザクションをコミットします 。

このコマンドは、以下のことを行います。
  • パッケージを短時間で再作成できます。 これによりユーザーは、 元のバインド・ファイルを必要とせずに、システムにおける変更を利用することができます。 例えば、特定の SQL 言語が新しく作成された索引を利用できるような場合には、 REBIND コマンドがパッケージを再作成するのに使用できます。 REBIND によって、RUNSTATS の実行後にパッケージを再作成することもできます。その結果、新規の統計を利用できるようになります。
  • 作動不能パッケージを再作成できます。 作動不能パッケージは、 バインド・ユーティリティーまたは再バインド・ユーティリティーのどちらかを呼び出すことにより、 明示的に再バインドしなければなりません。 パッケージが依存する関数インスタンスがドロップされると、パッケージは動作不能とマークされます（ SYSCAT.PACKAGESシステムカタログのVALID列はXに設定されます）。
  • 無効パッケージの再バインドに関する制御がユーザーに与えられます。 無効なパッケージは、実行時に データベース・マネージャー によって自動的または暗黙的に再バインドされます。 これは、再バインドが成功した場合にコミットし、すべてのユーザーにパッケージへの即時アクセスを許可する自律型トランザクションで行われます。 無効パッケージの暗黙的な再バインドは、無効パッケージの最初の SQL 要求の実行を著しく遅らせる可能性があります。

パッケージに複数のバージョン (同じパッケージ名と作成者を持つ数多くのバージョン) が存在する場合は、一度に 1 つのバージョンしか再バインドできません。 VERSIONオプションに指定されない場合、パッケージ・バージョンは "" にデフォルトされます。 同じ名前を持つパッケージが 1 つしか存在しない場合でも、 そのバージョンが、指定されたバージョンまたはデフォルトのバージョンと一致しない限り、再バインドは行われません。

パッケージを明示的に再バインドするのに、 BIND と REBIND のどちらを使用すべきかは、環境によって異なります。 REBIND のパフォーマンスは BINDのパフォーマンスより著しく優れているため、特に BINDを使用する必要がない状況では常に REBIND を使用することをお勧めします。 ただし、BIND 必須 を使用できます。
  • プログラムに修正が加えられている場合 (例えば、 SQL ステートメントが追加または削除された場合、 またはパッケージがそのプログラムの実行可能モジュールと一致しない場合など)。
  • 再バインドにおいて、REBIND コマンドでサポートされないバインド・オプションを変更する場合。 REBIND コマンドは、すべてのバインド・オプションをサポートしているわけではありません。 例えば、バインド処理の過程でパッケージに対する特権が付与されるようにする場合、BIND コマンドには GRANT オプションがあるため、このコマンドを使用する必要があります。
  • パッケージが現在ではデータベース内に存在していない場合。
  • すべての バインド・エラーを検出する必要がある場合。 REBIND は、検出される最初のエラーのみ戻しますが、BIND コマンドはバインド中に発生する、 最初の 100 のエラーを戻します。

REBIND は Db2 Connect によってサポートされています。

他のユーザーが使用中のパッケージで REBIND が実行された場合、他のユーザーの作業論理単位が終了するまで、再バインドは起こりません。これは、再バインド中に SYSCAT.PACKAGES システム・カタログ表中のパッケージのレコードで、排他ロックが掛けられるためです。

REBIND が実行されると、 データベース・マネージャー は、 SYSCAT.STATEMENTS システム・カタログ表に保管されている SQL ステートメントからパッケージを再作成します。

REBIND を実行してエラーが発生した場合、 処理は停止し、エラー・メッセージが戻されます。

REBIND を実行するとパッケージが再び Explain されますが、その対象となるパッケージは、EXPLSNAP バインド・オプションを YES または ALL (パッケージの SYSCAT.PACKAGES カタログ表項目の EXPLAIN_SNAPSHOT 列に示される) に設定して作成されたもの、および EXPLAIN バインド・オプションを YES または ALL (パッケージの SYSCAT.PACKAGES カタログ表項目の EXPLAIN_MODE 列に示される) に設定して作成されたものです。 使用される Explain 表は、REBIND を要求したユーザーのものであり、最初にバインドを実行したユーザーのものではありません。

SQL ステートメントに誤りがあることが検出され、BIND オプションの SQLERROR CONTINUE を指定していた場合、問題が修正されたとしても、そのステートメントには無効とマークされます。 REBIND しても、ステートメントが無効の状態は変更できません。 VALIDATE RUN でバインドされたパッケージの場合、 ステートメントは、REBIND 実行時にオブジェクトが存在するかどうか、または権限の問題があるかどうかに応じて、REBIND 全体において静的バインドから追加バインドに変更されたり、追加バインドから静的バインドに変更されたりします。

パッケージを REOPT ONCEまたはALWAYSで再バインドすると、静的および動的なステートメントのコンパイルとパフォーマンスが変わる可能性があります。

REOPT が指定されていない場合、 REBIND は、 PRECOMPILE または BIND 時に使用された既存の REOPT 値を保持します。

すべてのコンパイル済み SQL オブジェクトには、従属パッケージが存在します。 このパッケージは、REBIND_ROUTINE_PACKAGE プロシージャーを使用していつでも再バインドすることができます。 明示的に従属パッケージを再バインドしても、無効なオブジェクトの再有効化は行われません。 無効なオブジェクトを再有効化するには、自動再有効化を使用するか、または ADMIN_REVALIDATE_DB_OBJECTS プロシージャーを使用して明示的に行います。 オブジェクトを再有効化すると、自動的に従属パッケージが再バインドされます。