ここで専門家の助けが必要な状況に直面しています。私たちの会社がデータベースサーバーを別の場所に出荷したいので、新しいサーバーをインストールしてテストし、物理的に目的の場所に出荷して持っていくという状況に直面しています。古いサーバーを停止し、新しいサーバーを稼働させます。問題は、サーバーを構成しましたが、ダウンタイムを最小限に抑えて、プライマリサーバーのすべてのデータで2番目のデータベースを起動できる計画を見つけることができないことです。もう1つの問題点は、これら2つが単一のネットワークに接続されないことです。したがって、260 GBのデータベースは、あるサーバーから別のサーバーに移動することはできません。または、新しいサーバーを宛先に移動してライブの準備ができるまで、ダウンタイムを設定することはできません。
サーバーを宛先に移動した後、どういうわけかデータベースを同期する必要があります。助けてください。
オフラインになるのに数時間の余裕があれば、私はを調べますrsync。Windowsシステムを使用している場合は、およびcygwinのパッケージを含むディストリビューションを取得してインストールできます。rsyncssh
私が最初に行うことは、必要なオフラインの推定時間をできるだけ正確に計算することです。そのために：
cygwinソースマシンとデスティネーションマシンの両方でセットアップし、SSHを構成する必要があります（名前を付けて、ほとんどすべての作業を実行するスクリプトがありますssh-host-config）。ソースサーバーからSSH経由で宛先サーバーに接続できることを確認する必要があります。
.BAKデータベースバックアップファイル全体を宛先サーバーに初めてコピーします。初めて、DBバックアップファイルを圧縮して小さな部分に分割することができます。初めてDBバックアップファイルが作成されたら、ソースdbバックアップファイルを圧縮しないでください。
rsyncデータベースバックアップファイルを毎日実行するタスクをプログラムします。パスワードなしで（キーを使用して）宛先サーバーに接続するようにSSHを構成する必要がある場合があります。そのような場合は、ここで要約を、ここで詳細を確認してください。
安定したプロセスを達成したら、数値を調べて、移行日に転送されるバイト数を計算してみてください。
推定バイト数とアップロード/ダウンロード帯域幅レートを使用すると、必要な時間の推定値に到達できるはずです。
私は次の仮定をしています：
これは、rsyncldfまたはmdfオンラインでのファイルではなく、完全バックアップファイルを対象としていることに注意してください。そうは言っても、この他のDBAスレッドを考慮に入れてください。
上記の一連のメモとコメントの後で、昨年は同じタスクに直面しましたが、dbは小さくなりましたが、他の可能性を調べた後rsync、もちろんすべてのステップをテストした後、最終的にそれを行いましたテストし、必要な時間を非常に正確に事前に把握します。
あなたのデータベースは大きいので、このアプローチがあなたに最適かどうかはわかりません。
新しいデータベースサーバーをセットアップできます。次に、既存のデータベースのバックアップを取り、新しいサーバーに復元します。次に、Merge Replicationを使用して、既存のデータベースから新しいデータベースにデータを複製します。もちろん、これは、既存のデータベースサーバーが（インターネット経由であっても）新しいデータベースサーバーに接続できることを前提としています。ネットワーク経由でまったく接続できない場合は、ダウンタイムが発生するという事実に直面する必要があります。この場合、バックアップを新しいサーバーに復元します。もちろん、これは完全バックアップです。データベースを新しいサーバーに復元したら、古いサーバーに戻り、トランザクションログのバックアップとともに差分バックアップを作成します。次に、古いサーバーの電源を切る必要があります（復元中にサーバーでトランザクションが発生しないようにするため）。