ストアド プロシージャを再コンパイルしますか?

あなたの質問は、「スキーマを変更するとき、すべてのプロシージャが新しいスキーマで正しく実行されることを検証したい」と理解しています。すなわち。プロシージャ内の SELECT で参照されている列を削除する場合は、変更が必要であることを示すフラグを設定する必要があります。そのため、具体的には、「次の実行時にプロシージャを再コンパイルしたい」という質問を理解していません。そのジョブはエンジンによって処理され、スキーマの変更に関連するメタデータのバージョンの変更を検出し、既存のものを破棄するためです。キャッシュされた実行計画。

私の最初の観察は、あなたが質問で説明していることは、通常、TEST の仕事であるということです。 また、デプロイ プロセスには、新しい「ビルド」を検証する QA ステップが必要です。考えられる最善の解決策は、少なくともすべてのストアド プロシージャを反復処理し、実行を検証する最小限の単体テスト セットを実装することです。 テスト展開で、それぞれの正確性を確認します。これにより、すべての予期せぬ事態がほぼ解消されます。少なくとも問題のある場所 (本番環境または顧客のサイト) は解消されます。

次善の策は、開発ツールに依存してこれらの依存関係を追跡することです。 Visual Studio データベース 2008 データベース エディション はそのような機能をそのまま提供し、スキーマに加えた変更を検証します。

そして最後に、KM が提案したのと同様のことを行うという最後の選択肢があります。変更されたオブジェクトに応じてすべての手順 (および依存オブジェクトに応じたすべての手順などを再帰的に) の反復を自動化します。再コンパイルの手順をマークするだけでは十分ではありません。実際に必要なのは、ALTER PROCEDURE を実行して、テキストの解析とスキーマの検証をトリガーすることです (T-SQL と通常の言語では少し異なります)。コンパイル/実行サイクル、「コンパイル」自体は、プロシージャが実際に実行されるときにのみ発生します)。 sys.sql_dependencies 変更されたオブジェクトのすべての依存関係を見つけ、 sys.sql_modules :

with cte_dep as (
   select object_id
      from sys.sql_dependencies
    where referenced_major_id = object_id('<your altered object name>') 
    union all
    select d.object_id
    from sys.sql_dependencies d
        join cte_dep r on d.referenced_major_id = r.object_id
    )
, cte_distinct as (
    select distinct object_id
        from cte_dep)
select object_name(c.object_id)
    , c.object_id 
    , m.definition
    from cte_distinct c
    join sys.sql_modules m on c.object_id = m.object_id
  

 その後、依存する「モジュール」を実行して再作成できます (つまり、それらを削除して「定義」でコードを実行します)。 「モジュール」はストアド プロシージャよりも一般的であり、ビュー、トリガー、関数、ルール、デフォルト、およびレプリケーション フィルターもカバーすることに注意してください。暗号化された「モジュール」には利用可能な定義がありません。完全に正しくするには、sys.sql_modules でキャプチャされたさまざまな設定も考慮する必要があります。 (ANSI NULL、スキーマ バインディング、execute as 句など)。
 

 動的 SQL を使用する場合、それは検証できません。 sys.sql_dependencies によってキャプチャされません 、モジュールを「再作成」しても検証されません。
 

 全体として、単体テストの検証を実装することが最善の選択肢だと思います。