従来のバインディング・セマンティクス
オブジェクトの解決は、SQL オブジェクトの定義時か、パッケージのバインド操作の処理時に行われます。
データベース・マネージャーは、どの特定の定義済みの SQL オブジェクトを、DDL ステートメント内で参照されているかアプリケーション内でコード化されている SQL オブジェクト用に使用するか選択します。
- ルーチン - 適合度が上か、または適合度が同程度で SQL パス内の前の位置にある新しいルーチンが定義されることがあります。あるいは、適合度が上か、または適合度が同程度で SQL パス内の前の位置にある既存のルーチンに特権が付与されることもあります。
- ユーザー定義のデータ・タイプ - 新しいユーザー定義のデータ・タイプが、同じ名前で、SQL パス内の前の位置にあるスキーマ内に定義されることがあります。
- グローバル変数 - 新しいグローバル変数が、同じ名前で、SQL パス内の前の位置にあるスキーマ内に定義されることがあります。
- パブリック別名を使用して解決する表またはビュー - 実際の表、ビュー、またはプライベート別名が、同じ名前で現行スキーマ内に定義されることがあります。
- パブリック・シーケンス別名を使用して解決するシーケンス - 実際のシーケンスまたはプライベート・シーケンス別名が、同じ名前で現行スキーマ内に定義されることがあります。
- パブリック・モジュール別名に解決するモジュール - 実際のモジュールまたはプライベート・モジュール別名が、同じ名前で、SQL パス内のスキーマ内に定義されることがあります。
- パッケージ内の静的 DML ステートメント
- ビュー
- トリガー
- チェック制約
- SQL ルーチン
- ユーザー定義タイプまたはデフォルトの式があるグローバル変数
- ユーザー定義のパラメーター・タイプまたはデフォルトの式があるルーチン
パッケージ内の静的 DML ステートメントの場合、SQL オブジェクトの参照はバインド操作時に解決されます。 ビュー、トリガー、SQL ルーチン、およびチェック制約の中にある SQL オブジェクトの参照は、SQL オブジェクトの定義時または再妥当性検査時に解決されます。 既存の静的オブジェクトの使用時に、データベース・スキーマ内の変更のために、そのオブジェクトに無効または作動不能のマークが付けられていなければ、従来のバインディング・セマンティクス が適用されます。
従来のバインディング・セマンティクスにより、SQL オブジェクトの参照を解決するときは、必ず前の解決時に使用されたものと同じ SQL パス、デフォルト・スキーマ、および一連のルーチンが使用されることになります。 また必ず、従来のバインディング解決中に考慮された SQL オブジェクトの定義のタイム・スタンプが、非従来型バインディング・セマンティクスを使用してステートメントが最後にバインドまたは妥当性検査された時点のタイム・スタンプより後にならないようになります。 非従来型のバインディング・セマンティクスは、元の生成でのパッケージまたはステートメントと同じ SQL パスおよびデフォルト・スキーマを使用しますが、SQL オブジェクトの定義のタイム・スタンプを考慮せず、以前に解決された一連のルーチンを考慮しません。
- SQL パッケージ内の静的ステートメントにこの変更が起きると、パッケージに作動不能のマークが付けられます。 このパッケージ内のステートメントの次回の使用時に、パッケージを作動不能にしたデータベース・スキーマ内の最新の変更を考慮して SQL オブジェクトを解決できるように、非従来型のバインディング・セマンティクスを使用するパッケージの暗黙の再バインドが行われます。
- ビュー、トリガー、チェック制約、または SQL ルーチンにこの変更が行われると、SQL オブジェクトに無効のマークが付けられます。 オブジェクトの次回の使用時に、非従来型のバインディング・セマンティクスを使用する SQL オブジェクトの暗黙の再妥当性検査が行われます。
シグニチャー SCHEMA1.BAR(INTEGER) および SCHEMA2.BAR(DOUBLE) を持つ 2 つの関数を擁するデータベースについて考察してみます。 SQL パス内には、 SCHEMA1 と SCHEMA2 の 2 つのスキーマ (SQL パス内でのその順序は重要ではありません) があると仮定します。 USER1 には、関数 SCHEMA2.BAR(DOUBLE) に対する EXECUTE 特権が付与されています。 USER1 は、BAR(INT_VAL) を呼び出すビューを作成すると仮定します。INT_VAL は、INTEGER データ・タイプを使用して定義された列またはグローバル変数です。 ビュー内のこの関数参照は、関数 SCHEMA2.BAR(DOUBLE) に解決します。SCHEMA1.BAR(INTEGER) に対する EXECUTE 特権が USER1 にないからです。 ビューの作成後に SCHEMA1.BAR(INTEGER) に対する EXECUTE 特権が USER1 に付与されると、データベース・スキーマの変更によりビューに無効のマークが付けられなければ、ビューは引き続き SCHEMA2.BAR(DOUBLE) を使用します。 必須の特権が取り消されるか、従属先のオブジェクトのドロップか変更が行われると、ビューに無効のマークが付けられます。
パッケージ内の静的 DML の場合、パッケージの再バインドは暗黙的に行うことができますが、REBIND コマンド (またはこれに対応する API) または BIND コマンド (またはこれに対応する API) を明示的に発行して行うこともできます。 パッケージに無効のマークが付けられると、従来のバインディング・セマンティクスを使用して暗黙の再バインドが実行されますが、パッケージに作動不能のマークが付けられると、非従来型のバインディング・セマンティクスを使用します。 従属先の索引がドロップされるか変更される場合のみ、パッケージに無効のマークが付けられます。 REBIND コマンドには、従来のバインディング・セマンティクスで解決するか (RESOLVE CONSERVATIVE オプション)、それとも新しいルーチン、データ・タイプ、またはグローバル変数を考慮して解決するか (デフォルト・オプションの RESOLVE ANY) を選択するオプションがあります。 データベース・マネージャーによってパッケージに作動不能のマークが付けられていない場合のみ、RESOLVE CONSERVATIVE オプションを使用できます (SQLSTATE 51028)。
このトピック内の従来のバインディング・セマンティクスの説明は、データベース構成パラメーター auto_reval の設定が DISABLED 以外であることを前提にしています。 新規データベースの auto_reval のデフォルト設定は DEFERRED です。 バージョン 9.7 にアップグレードされたデータベースの auto_reval のデフォルト設定は DISABLED です。 auto_reval が DISABLED に設定されている場合、従来のバインディング・セマンティクス、無効化、および再有効化の動作は、バージョン 9.7より前のリリースの場合と同じです。 auto_reval が DISABLED に設定されている場合は、従来のバインディング・セマンティクスは、関数、メソッド、ユーザー定義タイプ、およびグローバル変数に関する SQL オブジェクトの定義のタイム・スタンプのみ考慮します。 無効化と再妥当性検査の動作の場合、DROP、REVOKE、および ALTER ステートメントのケースでは、セマンティクスがさらに制約されるか、従属オブジェクトに対する影響によりそのオブジェクトのカスケードとドロップが行われることを意味します。 パッケージのケースでは、ほとんどのデータベース・スキーマ変更は、パッケージに無効のマークが付けられ、暗黙の再バインド中に従来のバインディング・セマンティクスが使用される結果になります。 しかし、従属関数がドロップされ、auto_reval が DISABLED に設定される変更がスキーマに加えられると、その関数に従属するパッケージに作動不能のマークが付けられ、作動不能パッケージの暗黙の再バインドは行われません。