ダウンタイムなしでSQL-Serverデータベースを移動
SQL Server 2005 DBを、ダウンタイムなしでSQL Server 2008を実行している別のサーバーに移動することはできますか？システムは24時間年中無休であり、異なるストレージを持つ別のサーバーに移動する必要があります。
データベースをコピーしようとしましたが、プロセスの最後にデータベース全体の同期が維持されません。
ゼロダウンタイムなしただし、慎重に計画することで、ダウンタイムをほぼゼロにすることができます。
- オプション1：
- 既存の2005サーバーと新しい2008サーバーのログ配布をセットアップします。
- IPやホスト名を慎重に切り替えて、カットオーバーを計画します。
- 最終カットオーバーの前に、必ず最終テールログバックアップを実行してください。
オプション2（より多くの作業、より少ないダウンタイム）：
- 2008ボックスが新しい場合は、最初に2005を製品ボックスと同じspにインストールします。
- パフォーマンスのオーバーヘッドを回避するために、データベースミラーリングをセットアップし、最初の段階で非同期にします。
- 接続文字列にフェイルオーバーパートナーが含まれるようにクライアントを設定します
- 同期データベースミラーリングに変更し、新しいボックスにフェイルオーバーします
- データベースミラーリング設定の2005〜 2008年のインプレースアップグレードについては、「ローリングアップグレード手順」に従ってください。
もちろん、これを正しく行うには、実際にテストするときに、何も見逃していないことをテストして確認する必要があります。
いいえ、ごめんなさい。ダウンタイムなしでデータベースを移動する方法がわかりません。イースター休暇のように1時間も入れる方法がないデータベースには何がありますか？
これを行うための非常に複雑な方法...（ほぼ）
- サーバーをVMwareクラスターにP2Vします。ダウンタイムはありません。
- 2番目のサーバーを作成し、アクティブ/パッシブクラスターを作成します。
- パッシブノードを2008にアップグレードし、フェイルオーバーします。
- 利益？
明らかに、ここにあるすべてのものはテストを必要とします。詳細な手順は数多く残されています。
または-管理者にダウンタイムに同意してもらい、それを顧客に宣伝します。次に、死に至るアップグレードを練習してテストします！
この「安い」ことを試みる際の技術的な困難を経営陣に説明してください。これは、完全な27x7のアーキテクチャを最初に構築するときにシステムに構築するものです。
最大のシステムでさえ、ダウンタイムを計画しています。さらに心配する必要があるのは、計画外のダウンタイムです。
トランザクションレプリケーションはここであなたの友達です...
新しいサーバーをスレーブとしてレプリケーションをセットアップした場合は、新しいデータベースを起動して実行できるはずです。準備ができたら、切り替えます（ここでは最小限のダウンタイム、数時間ではなく数分）。 ..テーブルのインデックスを1つか3つ再作成する必要があるかもしれませんが、それが完了すると、それは完了です。
SQL Serverだけでは、これを達成することはできません。私は過去にDouble Takeと呼ばれる製品を使用しました。これにより、DBを別のサーバーに複製し、都合の良いときにフェイルオーバーすることができます。
新しいマシンでサービスが開始されると、フェイルオーバープロセスで多少のダウンタイムが発生します。
2つの環境間でデータベースの同期ミラーリングを設定することを検討できます。同期すると、データベースは、飛行中のトランザクションを中断するだけでフェイルオーバー（またはバック）できます。
現在、それが単一インスタンス/非クラスター化セットアップの場合、ダウンタイム0％を達成することはできませんデータの損失なし。 DBが主に読み取り量が多く、書き込み操作を2回失う方がよい場合は、DBを停止するために、いくつかのオプションがあります。
DBのCOPY_ONLY完全バックアップを実行し、それが完了したら、bakファイルを新しいサーバーストレージに移動することができます。 DBにSQLの新しいインスタンスを復元し、接続文字列を適切な場所に書き直して（うまくいけば、どこか1つのincファイルにしてください）、サイトを再起動します。サイトに不具合が発生し、アクティブなセッションが再開されます。
しかしながら。バックアップから復元までの間にすべての書き込みが失われます。
Dbミラーソリューションを使用すると、最小限のダウンタイム（フェイルオーバーまで数秒）でこれを達成することができます。詳細については、このMSDNの記事を参照してください。 http://msdn.Microsoft.com/en-us/library/bb677181.aspx
トム
ダウンタイムなしで移行できると主張するChronicDBという製品を見つけました。 SQLServerをサポートしているかどうかはわかりません。
私は確かにダウンタイムに終わった。最終テールを含むトランザクションログを使用して、バックアップ/復元の「通常の」方法を採用しました。
ダウンタイムなしでこれを行うためのすぐに使える方法があるはずだと私はまだ思っています。
2.0フレームワークを使用するアプリケーションサーバーとして.NETソリューションを使用している場合、tvanzeleによる提案は問題なく機能するはずです。以下の手順：
- プライマリデータベースが完全リカバリモードであり、ログバックアップを取っていることを確認してください
- 監視サーバーとして機能するSQLEXPRESSまたはStandardEditionSQLインスタンスをインストールします
- 完全バックアップをバックアップおよび復元し、バックアップを新しいインスタンス（監視ではない）に記録します
- 新しいSQLインスタンスへのデータベースミラーリングを設定し、SQLEXPRESS/Standardインスタンスを監視として使用します
- フェイルオーバーサーバーを認識するようにアプリケーションの接続文字列を変更します。参照についてはconnectionstrings.comを参照してください。
- 古いインスタンスを再起動して、データベースをミラーにフェイルオーバーします
- フェイルオーバーインスタンスのみを使用するようにアプリケーションの接続文字列を変更する
- ミラーリングを解除する