データベースオブジェクトに変更をデプロイするたびに、それに依存するコードは無効になります。これは、トリガー、ビュー、およびストアドプロシージャに影響します。ただし、次に何かがそのコードを呼び出すと、データベースは自動的にそれを再コンパイルします。
だから私たちはこれについて心配する必要はありませんよね？ええ、はい、ある程度までです。重要なのは、トリガー（またはその他）の無効化は、そのトリガーの動作に影響を与える可能性のある変更が行われたことを示すフラグであり、副作用が発生する可能性があります。最も明らかな副作用は、トリガーがコンパイルされないことです。さらに微妙に、トリガーはコンパイルされますが、操作中に失敗します。
したがって、開発環境でトリガーの再コンパイルを強制して、変更によって根本的に何も壊れていないことを確認することをお勧めします。ただし、すべてがオンデマンドで再コンパイルされると確信しているため、本番環境で変更をデプロイするときは、そのステップをスキップできます。私たちの神経に依存します:)
Oracleは、スキーマ内のすべての無効なオブジェクトを自動的に再コンパイルするためのメカニズムを提供します。
-
最も簡単なのは、
DBMS_UTILITY.COMPILE_SCHEMA()を使用することです。 。しかし、これは8i以降（Javaストアドプロシージャのサポートにより循環依存の可能性が導入されたため）危険であり、すべてのオブジェクトを最初に正常にコンパイルすることが保証されなくなりました。 -
9iでは、Oracleからスクリプト
$ORACLE_HOME/rdbms/admin/utlrp.sqlが提供されました。 物事を再コンパイルしました。残念ながら、SYSDBAアクセスが必要です。 -
10gで、彼らはUTL_RECOMPパッケージを追加しました。これは、基本的にそのスクリプトが実行するすべてのことを実行します。これは、多数のオブジェクトを再コンパイルするために推奨されるアプローチです。残念ながら、SYSDBAアクセスも必要です。 詳細 。
11gで、オラクルはきめ細かい依存関係管理を導入しました。これは、テーブルへの変更がより細かい粒度（基本的にはテーブルレベルではなく列レベル）で評価され、変更によって直接影響を受けるオブジェクトのみが影響を受けることを意味します。 詳細 。