私は現在、SQL Server 2008の大規模なデータベース(約500GB)を使用しており、それは新しいSQL Server 2014サーバーに再配置されます。
私の目的は、移行時間を最小限に抑えることです。
データベースをネットワーク共有にバックアップしてから移行することは、非常に時間がかかります。
私の計画は、カットオーバーまでデータベースの同期を維持する方法を見つけることです。
私はログ配布を調査してきましたが、プロセスが完全にわからない(私はDBAではないので、テレビで再生することすらしません)。また、データベースを使用可能な状態にしないためです。状態、それが実用的かどうかはわかりません。
提案や、役立つ可能性のあるツールの推奨事項を受け入れます。
データベースミラーリングを設定することをお勧めします。
同期の高安全モードでミラーリングを設定すると、2008データベースは、ソースデータベースで変更されているため、2014サーバーにデータを送信します。
新しいマシンに切り替えることを決定したら、ミラーデータベースへのフェイルオーバーを開始するだけで、「et voila」です。2014マシンがデータベースを「アップグレード」するのに必要な1〜2分後に、データベースがオンラインになり、準備が整います。使用する。
「私はDBAではない」という制約の範囲内で検討します
私はマルチTBデータベースをこの方法で移行しました。
移行時間は長くなりますが、フルバックアップとDIFFバックアップの間のインデックスメンテナンスを無効にするなど、管理できるデータ変更の量によっては、ミラーリングを使用するよりもはるかに長くはなりません。
私の目的は、移行時間を最小限に抑えることです。
ログ配布は、システムのダウンタイムを最小限に抑えるデータベース移行を実行する優れた方法です。
まず、現在のサーバーから新しいサーバーにログ配布(これを実行するためのWeb上のさまざまな記事)を設定します。最初のサーバーは構成でプライマリと見なされ、新しいサーバーはセカンダリと見なされます。その後、変更は指定された時間間隔でプライマリからセカンダリに「出荷」されます。
実際に移行するときは、次のような this などのソリューションを使用します。
セカンダリにフェイルオーバーすると、このソリューションではプライマリデータベースにアクセスできなくなることに注意してください。これにより、プライマリとセカンダリの両方で作業が行われ、それぞれの変更を1つのデータベースに手動でマージしようとする状況から保護されます。
ここでログ配布を使用する利点の1つは、他のほとんどの方法よりも高速になることです。例として、メソッドAとメソッドBを取り上げます。方法Aはログ配布を使用し、方法Bは移行時に差分を使用します。
方法A:
方法B:
方法Aは、最後の数個のトランザクションログバックアップをセカンダリに適用するだけで、すぐに使用できます。方法Bでは、最後の完全バックアップ以降に発生したすべての変更を適用する必要があります。これらの2つの方法の違いは、差がどれだけ大きいかによって、最小からかなりの範囲になる可能性があります。バックアップしてセカンダリに適用するデータが少ないため、方法Aはほぼ確実に毎回勝ちます。
データベースの一貫性について確信があり、単一のSANストレージを両方のサーバーで使用する場合、データベースをデタッチして attach in他のサーブでは r。この方法には制限がありますが、状況が条件と一致する場合、それらの中で最速だと思います。