detach / copy / attachまたはbackup-restore-replayを使用してデータを移行する必要がありますか？
データベースファイルを新しいSAN（古いSANから））に移行しようとしています。これを実装するためのオプションがいくつかあります。（1）サーバー上の新しいデータベースに完全バックアップを復元する作業のレベル。ただし、（2）私の元の計画は、古いSANから新しいSANデータベースを切断してから再接続します。
私の直感は、フェイルセーフであるように思われるので、デタッチ、コピー、アタッチするほうがいいと言っていますが、それは私の初心者かもしれません。データベースの名前を変更するプロセスで、トランザクションを見逃したり、どういうわけか「何かを壊したり」したくありません。
私の質問は、私がBACKUP-RESTORE-Replayオプションの懐疑論で正当化されるかどうか、そしてそのオプションの他のメリットやリスクは何ですか？
個人的には、デタッチ/アタッチのメカニズムは避けます。特にSQL Server 2000では、サーバーを常に起動し、それらのファイルを添付できるとは信じていません。私はこれがきれいに起こらなかった多くの話を聞いた-あなたがプランBを持っているからといって、プランAが自動的に賢明にならないからだ。
バックアップ/復元を使用すると、プランBに移動する必要はありません。バックアップが失敗した場合でも、データベースは稼働しています。復元が失敗した場合でも、古いデータベースは稼働しています。どちらの場合も、元のデータベースの操作を復元して、後で計画を再検討できます。ここでは、SQL Serverの停止やデタッチを介した追加のセキュリティに加えて、バックアップ/復元の方法からフーハスをテストすることもできます（現在、バックアップを実行するスペースと、戻す）。データベースを切り離したり、SQL Serverを停止したりせずに、切り離しアプローチを実際にテストすることはできません。適切なメンテナンスウィンドウの外で行うことは困難です。そして最後に、他のアプローチでは、SQL Serverを切り離すか停止するまで、ファイルのコピーを開始することさえできません。バックアップ/復元を使用すると、最後のログバックアップを取得してメンテナンスウィンドウを開始するずっと前に、.bakファイルを新しいストレージで待機させることができます。
SQL-Serverからのドライブからのプルアウトの方法に対するもう1つの利点：バックアップ/復元を使用すると、以前とは異なるドライブ文字にさまざまなファイルを移動できます。たとえば、新しいSANに移行したときに、ボリュームを増やすことができたため、tempdbをT：\（以前は存在しなかった）に移動したり、一部のデータファイルやログファイルを新しいドライブ文字に移動したりできます。私たちが持っていたすべての新しいI/O容量をより有効に活用するため。 SQL Serverをシャットダウンしてからディスクを交換する場合は、ドライブ文字とボリューム数を同じにする必要があります。
SAN再構成と移行のため、私はデータベースをほとんど常に移動していました。
サーバー全体を一度に移動すると仮定すると、パス＃2のようなものを使用します。 （一度に1つのデータベースを移動し、最終的にサーバー上のすべてのデータベースを移動する場合は、ファイルへのパスを変更する必要があるため、さらに問題になります。）
「single_user」は必ずしもYOUを意味するわけではないことに注意してください。 DBCC CHECKDBのデータベースにアクセスしても、誰かがすでにそこにいるためにアクセスできない可能性があります。データベースから「あなた以外の全員」を起動するために実行できるスクリプトを準備し、それを便利な場所に保管します。 SQL 2000には、最新のバージョンと同じ「すべての人を締め出す」機能がないことに注意してください。
古いトリックの1つは、SQL Serverサービスを一時停止することです。これにより新しいログインはできなくなりますが、すでに接続されているユーザーは通常どおり続行できます。だから：SSMSウィンドウを介して接続して作業を行い、サービスを一時停止してから、望ましくない接続を開始し、SSMSコマンドウィンドウを介して（GUIではなく、多くの接続を確立および切断します）、一時停止を解除しますサービス。警告：それがクラスターでどのように機能するかはわかりません。フェイルオーバーする必要がある場合があります。
作業が完了するまで、すべてのアプリユーザーをサーバーから除外する方法があると便利です。そうしないと、何かを実行しようとしているときに接続がポップアップし始め、リソースの競合やスローダウンにつながる可能性があります。正確な状況に応じて、過去に次の方法を使用しました。アプリサーバーをオフにするALTER DATABASE .. SET RESTRICTED_USERの使用（アプリアカウントがdb_owner、sysadmin、またはdbcreatorロールのメンバーである場合、これは問題です。 ）日曜日の朝など、特定の時間にシステムがオフラインになることをユーザーに伝えます。 （これは「実際の」24時間年中無休の環境では機能しません。）NICアプリサーバーまたはユーザーに面しているプラグを抜きます。（この場合、別のNIC管理者専用ネットワークに接続されているか、ILOを介して。）
多数のデータベースを切り離して再接続するのは、大変な作業です。その場合は、「attach」スクリプトを事前に作成しておく必要があります。
私はSQL Serverの停止、すべてのコピー、ドライブ文字の変更、SQL Serverの起動に多くの成功を収めてきました。取り外し/取り付けなし。 SQL Serverがオフであり、ファイルを（MOVINGではなく）コピーしている限り、システムデータベースを移動している場合でも、それほど多くの問題に遭遇することはありません。パスが同じであるため、SQL Serverは、サービスがオフの間に何も変更されたことを認識しません。ドライブ文字が正しいボリュームを指していることを確認してください。そうしないと、状況が悪くなります。
私の最もよくある問題は、ファイルディレクトリのACLを正しく取得していなかったことです。より最近のバージョンのSQL Serverは、サービスアカウントに必要な権限justを設定するのに適していますが、古いバージョンはそれほど面倒ではありません。 ACLの設定を忘れ、サービスアカウントがローカル管理者ではない場合（お勧めしません）、インスタンスの起動時に1つ以上のデータベースが開かない場合があります。慌てる必要はありません。ACLを変更してデータベースを接続するだけです。
通常、この種の作業にはROBOCOPYを使用します。 ACLを保持するコマンドラインスイッチがあります。
CRC計算/検証を使用することは悪い考えではありませんが、私はそれをやったことがありません。データベースが復旧したら、それらすべてに対してCHECKDB（）を実行します。メンテナンスジョブを手動で開始するのではなく、通常は事前にスクリプトを準備します。そうすれば、実行に数分または数時間かかる大規模なデータベースをチェックする前に、いくつかの小さなデータベースを最初にチェックできます。 CRCチェック（またはRedgateデータ比較ツール）がCHECKDB（）で見逃していたものを見つけ、SQL Serverがそれを修正できなかったとしたら疑問です。
ファイルをコピーした後、インスタンスを再起動する前に、フォルダーの1つの名前を変更して、OLDフォルダーのファイルパスを少し変更します。これは、「おっと、サーバーがまだ古いファイルを指している」という問題に対する追加のチェックです。
急いで古いファイルを削除したり、古いストレージのスペースを回復したりしないでください。完全バックアップが正常に実行されていることを確認してください。これらのバックアップのいくつかを別の場所にテスト復元します。 checkdb（）が正常に実行され、完全なバックアップが完了したら、その古いストレージを削除して、Lefthandをシャットダウンすることを検討できます。
これらの移行で発生した最悪の問題は、完了したと思った後に発生しました。 SAN管理者は、何かが発生し、ファイルシステムがスクランブルされたことを告げます（再分割、再フォーマット、再度コピー）。
もう1つの楽しい問題は、SAN明らかな理由もなく遅いことです。データをコピーするのに10時間かかり、9時間目に30％コピーされると思われる場合、問題があります。 。転送時間を監視し（robocopyは％コピーを示し、時間の見積もりを提供します。または、Perfmonを使用できます）、異常が発生した場合のフォールバック計画を作成します。
また、ボリュームがパーティション化されるかどうかはわかりませんが、ボリュームが1 MBのオフセットを使用していることを確認したい場合があります。 Windows Server 2008以降では、これは問題になりません。古いOSではそうです。これにはグーグル可能なものがたくさんあり、ストレージの担当者はそれについて知っているはずですが、私は尋ねます。
最初に、ストレージアレイの機能を使用してデータの移動を処理するオプションについて説明します。ベンダーがサポートしていないため利用できない場合は、購入していないか、SAN管理者が方法を知らない...
次に、次の手順を使用します。
- 新しいストレージをSQL Serverに提示します。
- SQLサービスを停止する
- 古いドライブから新しいドライブにすべてのデータをコピーします（robocopyを使用する場合は、アクセス許可を含めることを忘れないでください）
- 古いドライブからドライブ文字を削除します。
- 新しいドライブのドライブ文字を古いドライブ文字と一致するように変更します
- SQLサービスを開始する
それでおしまい。
SQL Serverが何も変更されていないことを認識している限り、デタッチ/アタッチは必要ありません。そして、何かがひどくうまくいかない場合は、古いストレージアレイの古いLUNにデータベースの古いコピーが置かれています。フェイルバックは、ドライブ文字を変更するだけのことです。