オンライン中にSQL Serverデータベースを新しいディスクに移動する

私は、ディスクI / Oで大いに苦労している1.4TBのSQL Serverデータベースを持っています。私たちはすべての問題を解決する新しいSSDアレイをサーバーにインストールしました。データベースを移動する最良の方法について議論しているだけです。理想的には、ダウンタイムなしでそれを実行できれば、それが最善です。ただし、2日間のパフォーマンスの低下（データのコピー中など）と2時間のダウンタイムのどちらを選択するかは、後者の方が望ましい場合があります。

これまでのところ、私たちが考え出したソリューションは次のとおりです。

• 簡単なコピー。DBをオフラインにして、ファイルをコピーし、SQL Serverの場所を変更して、オンラインに戻します。大まかな数値では、これには5時間ほどかかると見積もられていますが、これは実際には許容できませんが、最も簡単な解決策です。

• ブロックレベルのコピー。rsyncのようなユーティリティを使用して、DBの稼働中にファイルをバックグラウンドでコピーします。移行の準備ができたら、DBをオフラインにして、このユーティリティを使用して差分コピーを実行し、SQLサーバーで新しいファイルを指定してオンラインにします。ここでのタイミングは不明です。1.4TBの差分分析を実行してそれをコピーするのにどのくらい時間がかかるかはわかりません。もう1つの懸念は、ブロックレベルのコピーによって、SQL Serverがファイルを読み取り不可能な状態にして、時間を浪費することです。

• SQLマイグレーション。新しいディスクに新しい1.4TB SQLデータファイルを作成し、他のすべてのファイルで自動拡張を無効にします。次に、他のすべてのデータファイルに対してDBBC SHRINKFILE（-file_name-、EMPTYFILE）を順番に実行します。すべてのデータが揃ったら、ある時点でスケジュールされたウィンドウを使用して、MDFファイルをSSDに移動し、他の未使用のファイルを削除します。ダウンタイムを最小限に抑えるので、私はこれが好きです。しかし、これにどれくらい時間がかかるか、またそれが実行中にパフォーマンスの低下を引き起こすかどうかはわかりません。

これをテストするための負荷とパフォーマンスの環境はありません。戦略がステージング環境で機能することは確認できますが、影響やパフォーマンスは確認できません。

データベース全体を移動する1つの方法は、BACKUPおよびを使用することRESTOREです。最終的な切り替え中はデータベースは使用できなくなりますが、計画を立てることでダウンタイムを最小限に抑える必要があります。この手順は、FULLまたはBULK_LOGGED復旧モデルを前提としています。

1）完全バックアップを実行します（または既存のバックアップを使用します）。

2）最新の完全バックアップを別のデータベース名に復元し、WITH MOVE必要に応じてSSDストレージ上のファイルを再配置するNORECOVERYオプションと、その後の差分バックアップとログバックアップを復元できるようにオプションを指定します。

3）トランザクションログバックアップを使用した最終的なカットオーバーの時点まで、新しいデータベースに増分変更を適用しますRESTORE...WITH NORECOVERY。これにより、新しいデータベースへの最後の切り替えのダウンタイムが最小限になります。

4）新しいデータベースに切り替えるには、アプリケーションをオフラインにして、最後のトランザクションログバックアップを実行し、新しいデータベースに適用しますWITH RECOVERY。最後に、元のデータベースの名前を別の名前に変更し、再配置したデータベースの名前を元の名前に変更します。都合の良いときに古いデータベースを削除します。

SIMPLE復旧モデルでは、同様のプロセスを使用できますが、手順3のトランザクションログのバックアップ/復元は必要ありません。代わりに、最後のステップでデータベースの差分バックアップ/復元を使用してください。最初のFULLバックアップ以降の変更の量によっては、より多くのダウンタイムが必要になる場合があります。

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.