行っている変更によっては、メンテナンスウィンドウを使用する方が簡単な場合があります。そのウィンドウ（誰もテーブルのデータを変更できないはずです）の間に、次のことができます。
- 古い列を指すインデックス/制約をすべて削除し、トリガーを無効にします
- 新しいnullableを追加します 新しいデータ型の列（NOT NULLを意味する場合でも）
- 新しい列を更新して、古い列の値と同じに設定します（これは、個々のトランザクションのチャンクで実行できます（たとえば、
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL）ログのオーバーランを回避するためのチェックポイントを使用） - 更新がすべて完了したら、古い列を削除します
- 新しい列の名前を変更します（必要に応じてNOT NULL制約を追加します）
- インデックスを再構築して統計を更新する
ここで重要なのは、ステップ3で更新を段階的に実行できることです。これは、単一のALTERTABLEコマンドでは実行できません。
これは、列がデータの整合性に主要な役割を果たしていないことを前提としています。列が外部キーの関係に関与している場合は、さらに多くの手順があります。
編集
また、大声で疑問に思っているのですが、これについてはテストを行っていません（ただし、リストに追加しています）。ここでページ+行の圧縮が役立つかどうか疑問に思いますか？ INTをBIGINTに変更した場合でも、圧縮が行われていると、SQLServerはすべての値をINTに収まるかのように処理する必要があります。繰り返しになりますが、これによって変更が速くなるか遅くなるか、またはそもそも圧縮を追加するのにどれだけ時間がかかるかについてはテストしていません。捨てるだけです。