SANの再構成と移行のために、私はほとんど常にデータベースを移動していました。
一度にサーバー全体を移動していると仮定すると、パス#2のようなものになります。(一度に1つのデータベースを移動し、最終的にサーバー上のすべてのデータベースを実行する場合は、ファイルへのパスを変更する必要があるため、問題が大きくなります。)
「single_user」は必ずしもあなたを意味するわけではないことに注意してください。DBCC CHECKDBにデータベースを移動すると、誰かが既にそこにいるためにアクセスできません。"everyone but you"をデータベースから起動し、便利な場所に保管するために実行できるスクリプトを準備します。SQL 2000には、最新のバージョンと同じ「全員を寄せ付けない」機能がないことに注意してください。
古いトリックの1つは、SQL Serverサービスを一時停止することです。これにより、新しいログインが防止されますが、すでに接続されているユーザーは通常どおり続行できます。SSMSウィンドウを介して接続して作業を行い、サービスを一時停止してから、望ましくない接続をキックアウトし、SSMSコマンドウィンドウ(GUIではなく、多くの接続を作成および切断します)を実行し、一時停止を解除しますサービス。警告:クラスターでどのように機能するかはわかりません。フェイルオーバーが必要な場合があります。
作業が完了するまで、すべてのアプリユーザーをサーバーから締め出す方法があると便利です。そうしないと、物事を行おうとしているときに接続がポップアップし始め、リソースの競合や遅延につながる可能性があります。正確な状況に応じて、過去に次の方法を使用しました:ALTER DATABASE .. SET RESTRICTED_USERの使用(アプリアカウントがdb_owner、sysadminまたはdbcreatorロールのメンバーである場合、それは問題です。 )日曜日の朝などの特定の時間にシステムがオフラインになることをユーザーに伝えます。(これは、「実際の」24時間365日の環境では機能しません。)アプリサーバーまたはユーザーに直面しているNICを取り外します。(この場合、管理者専用ネットワークに接続された別のNICまたはILOを介してアクセスできます。)
多数のデータベースを切り離して再接続するには、多くの作業が必要になる場合があります。その場合は、事前に「アタッチ」スクリプトを作成してください。
SQL Serverを停止し、すべてをコピーし、ドライブ文字を変更し、SQL Serverを起動することに成功しました。デタッチ/アタッチなし。SQL Serverがオフで、ファイルを(MOVINGではなく)コピーしている限り、システムデータベースを移動している場合でも、あまり面倒なことはありません。パスが同じであるため、SQL Serverは、サービスがオフの間は何も変更されたことを認識しません。ドライブ文字が正しいボリュームを指していることを確認してください。そうしないと、問題が発生します。
私の最もよくある問題は、ファイルディレクトリのACLを正しく取得できなかったことです。SQL Serverのより新しいバージョンは、サービスアカウントに必要なアクセス許可のみを設定するのに優れていますが、古いバージョンはそれほど面倒ではないようです。ACLの設定を忘れ、サービスアカウントがローカル管理者でない場合(推奨しません)、インスタンスの起動時に1つ以上のデータベースが開かない場合があります。パニックしないで、ACLを変更してデータベースを接続するだけです。
私は通常、この種の作業を行うためにROBOCOPYを使用します。ACLを保持するためのコマンドラインスイッチがあります。
CRC計算/検証を使用することは悪い考えではありませんが、私はそれをやったことがありません。データベースが復旧したら、それらすべてに対してCHECKDB()を実行します。通常、メンテナンスジョブを手動で開始することに頼るのではなく、事前にスクリプトを準備します。そうすれば、大規模なデータベースをチェックする前に、いくつかの小さなデータベースを最初にチェックでき、実行に数分または数時間かかる可能性があります。CRCチェック(またはRedgate Data Compareツール)がCHECKDB()が見落としているものを見つけ、それがSQL Serverで修正できない場合は、私は疑います。
ファイルをコピーした後、インスタンスを再起動する前に、フォルダーの1つを名前変更して、OLDフォルダーのファイルパスを少し変更します。これは、「サーバーがまだ古いファイルを指している」という問題に対する追加のチェックです。
急いで古いファイルをドロップして古いストレージのスペースを回復し、完全バックアップが正常に実行されたことを確認してください。これらのバックアップのいくつかを別の場所にテスト復元します。適切なcheckdb()の実行と適切なフルバックアップが完了したら、その古いストレージを削除し、左側をシャットダウンすることを検討できます。
これらの移行で私が経験した最悪の問題は、完了したと思った後に起こりました。それは何かが起こって、私のファイルシステムがスクランブルされたと私に言っているSAN管理者でしょう。(再パーティション化、再フォーマット、再コピー。)
別の楽しい問題は、明らかな理由もなくSANが遅いことです。データをコピーするのに10時間かかり、9時の時点で30%コピーされていると思われる場合は、問題があります。転送時間(ロボットコピーは%コピーを示し、推定時間を示します。または、Perfmonを使用できます)を確認し、何かがおかしくなった場合のフォールバックプランを用意します。
また、ボリュームが自動的にパーティション分割されるかどうかはわかりませんが、1 MBのオフセットを使用していることを確認してください。Windows Server 2008以降では、これは問題になりません。古いOSではそうです。これにはたくさんのグーグル可能なものがあり、ストレージ担当者はそれについて知っているはずですが、お願いします。