24時間年中無休のマルチユーザー環境でのSQL Server 2014スキーマの変更

24時間365日利用可能なデータベースを実行するために、SQL Server 2014 Enterpriseがインストールされています。私たちのデータベースは十分に大きい（200GB +）。また、新しいデータを読み取り、更新、または挿入するためにデータベースに毎分アクセスする多くのサービスがあります。クライアントに「ホット」再デプロイ機能を提供し、日々の更新（.netおよびスキーマの更新）をクライアントに対して透過的にしたいと考えています。アプリのバイナリを更新するロードバランサーを備えたクラスターに基づいたソリューションを見つけましたが、データベースの更新展開プロセスとこの問題を解決するためのベストプラクティスについては、まだいくつかの誤解があります。

スキーマの変更については、1つのサーバーを停止し、スキーマの変更を適用し、それを再起動してから、同じ変更を2番目のインスタンスに適用します。SQL Serverツールで実現できますか？これは一般的なアプローチですか？サーバーのバックアップ後のデータの同期方法 または、私は完全に間違った方向に考えていますか？より良い解決策はありますか？

一般的なスキーマの変更：列の追加/削除、ストアドプロシージャの追加/削除

以下では、もう少し計画とテストが必要になります。

ブルーグリーンのコンセプト：

Blue-Green Conceptの要点は、プロダクションを2つの環境に分割することであり、それらは常に同一（データ同期）であり、

1. Blue（Current）には、スキーマ/ビルドまたは製品の現在のバージョンが含まれ、「LIVE」環境にな​​ります。

2. 同時に、グリーンはステージング/テスト環境となり、スキーマ/ビルドまたは製品を次のリリースにアップグレードし、完全なリグレッションテストを行い、ビジネスユーザーからサインオフされます。カットオーバー期間中に幸せになったら、グリーンを「ライブ」環境に昇格させ、ブルーを次のリリースのプリプロダクション/ステージングまたはテストに降格します。

この方法により、ダウンタイムが非常に少なくなり、稼働中のシステム（アップグレードを実行しているためメンテナンスウィンドウにある）での展開の失敗のリスクが大幅に最小化されます。また、Blue-Greenアプローチに従って、LIVEバージョンとPREVIOUSバージョンの間で振動し、次のバージョンのステージングが行われます。

繰り返しますが、これにはより多くのハードウェア/ライセンスと計画とテストが必要になります。

ほとんどの手順は、DACPACとPowerShellを使用して自動化できます。また、1つのサーバーに複数のインスタンスをインストールする場合は、青と緑を切り替えるときにメモリ設定のバランスを再調整してください。LIVE環境は、Passive環境よりも多くのメモリを取得します。

現在の環境では、アジャイルコードの展開にブルー/グリーンモデルを実装しており、テストとビジネスサインオフに十分な時間をかけて2週間ごとにコードを昇格させることができます。また、何かがひどく間違った場合にロールバックするのも簡単です。DacpacsとPowerShellを使用して、展開の大部分を自動化しました。

（画像ソース）

ロールバックとリカバリのトラブルシューティングに関するGrant Fritcheyの記事も参照してください。課題と戦略

データベースが複製されていない場合、列の追加と削除は非常に高速に実行されます。列の追加は、SQLが作成する空の位置にすぎないためです。列をドロップすると、参照が消去されます。

それ以外の場合、何らかの制約またはインデックスがある場合は注意してください。

ADD/DELETEプロシージャは、実行自体にのみ影響します。推奨事項は、変更を加える前に再コンパイルを実行することです

sp_recompile 'myproc'