100以上のテーブルを含むデータベースがあり、主要な機能が追加されたとします。これには、既存のテーブルのうち20を変更し、さらに30を追加する必要があります。変更は、開発データベースの複数の開発者によって長期間（6か月）にわたって行われました。変更によって既存の本番データが無効にならないことを前提とします（たとえば、追加された列で許可されるデフォルト値/ nullがあり、満たすことができなかった新しい関係や制約はありません）。
これらの変更をスキーマで本番データベースに公開する最も簡単な方法は何ですか？できれば、データベースを長時間シャットダウンせずに。
必要な変更を実行するT-SQLスクリプトを記述します。本番データベースのコピーでテストします（コピーを取得するには、最近のバックアップから復元します）。テストで発見される避けられない間違いを修正します。スクリプトが完全に機能するまで繰り返します。
次に、実際の移行の時間になったら、管理者だけがログインできるようにDBをロックします。バックアップを取ります。スクリプトを実行します。結果を確認します。DBをオンラインに戻します。
最も長い部分はバックアップになりますが、それを行わないのはおかしいでしょう。バックアップにかかる時間を知っておく必要があります。全体的なプロセスはそれよりも長くはかからないため、ダウンタイムを長くする必要があります。深夜はほとんどの企業に適しています。
ダウンタイムなしで「変更」を行う方法についての一般的な答えはありません。答えは、正確に何が変更されたかに基づいて、実際にはケースごとに異なります。一部の変更はダウンタイムに影響を与えません（たとえば、新しいテーブルの追加）、一部の変更は最小限の影響しかありません（たとえば、nullビットマップサイズを増加させない新しいnull可能列のように、データサイズを変更せずに既存のテーブルに列を追加します）。他の変更はダウンタイムに大混乱をもたらします（データサイズを変更する操作は、強制的にインデックスを再構築し、その間テーブルをロックします）。一部の変更は、*重大な*ダウンタイムなしでは適用できません。変更が並行して適用された場合を知っています。データベースのコピーが作成され、レプリケーションが設定されて最新の状態に保たれ、コピーが変更されて同期が保たれます。最後に、操作はマスターデータベースになる変更されたコピーに移動されます。でプレゼンテーションがありますミシェル・ウッフォードによって与えられたPASS 2009は、godaddyが数週間続いたそのような変化をどのように経験したかについて言及しています。
ただし、小規模では、十分にテストされたスクリプトを使用して変更を適用し、テスト評価への影響を測定する必要があります。
しかし、本当の問題は、これがスキーマに加える最後の変更になるのかということです。最後に、アプリケーションに最適なスキーマを発見しました。本番データベースは変更されませんか？おめでとうございます、これをやってのけると、あなたは休むことができます。しかし現実的には、6か月でまったく同じ問題に直面することになります。本当の問題は、開発者がSSMSまたはVSServerExploredからデータベースに直接変更を加える開発プロセスです。開発プロセスでは、バージョン管理とデータベースで説明されているような、バージョン管理とT-SQLスクリプトに基づくスキーマ変更戦略を採用するように意識的に努力する必要があります。
ツールを使用してdiffスクリプトを作成し、メンテナンスウィンドウで実行します。私はこれにRedGateSQLCompareを使用しており、非常に満足しています。
私はここ数年、dbdeployを正常に使用しています。これにより、開発者は小さなSQL変更デルタを作成して、データベースに適用できます。変更はデータベース内の変更ログテーブルによって追跡されるため、何を適用するかがわかります。