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