SQL2005で数百のデータベースを複製/ミラーリングするための最良の方法
私は現在、それぞれさまざまなサイズ（1〜10ギガ）の約400〜500のSQL2005データベースをホストしています。利用可能なさまざまな方法のほとんどと、ミラーリング、ログ配布、レプリケーション、およびクラスタリングの一般的な長所/短所は知っていますが、指定したサイズ（400- 500 一意データベース）。
この種のセットアップで別のサーバーにフェイルオーバーする機能を持たせるための最善の方法は何かについて、誰かが良いアドバイスを持っていますか？
フェイルオーバーはすぐに行う必要はありません。毎日バックアップを取り、それらをストレージに移動するよりも優れたものを探しています。私は、データベースを一度に1つずつではなく、一括で管理しやすくするものを探しています。
ご意見ありがとうございます！
あなたのターゲットソリューションは、あなたが本当に求めているものは何かという問題を中心に展開すると思いますか？
HAを使用している場合は、単一のインスタンス上のデータベースの数を考慮してクラスタリングを検討することをお勧めします（これが当てはまると思います）。
DR機能を求めていて、ストレージインフラストラクチャが失望することを心配している場合は、2番目のサイト（論理的または物理的）とそのシナリオで利用可能なオプションについて実際に話し合っています。この場合のミラーリングは、非常に多くのデータベースのウィンドウの外にあります。ログシッピングはオプションですが、Farseekerが正しく指摘しているように、管理性が問題になります。また、レプリケーションも同様の懸念で失敗します。
上記のFarseekerとno_oneの両方が示唆しているように、ハードウェアベースのレプリケーションが必要になる可能性があります。これをWindows2008ジオクラスタリング機能と組み合わせて、優れたHAおよびDR機能を提供できます。これらの厳しい経済状況では、それはより大切な解決策かもしれませんが。
もう1つの根本的なオプションは、 HP Polyserve または XkotoのGridscale のようなものに投資することです。
お役に立てれば。
ストレージベンダーに相談して、ハードウェアベースのレプリケーションが提供されているかどうかを確認する必要があります。それはあなたが思いつくかもしれない他のどの解決策よりもはるかに速いでしょう。
私は3つのかなり大きなデータベースを実行しており、バックアップ（バックアップはレプリカで実行されます）、dbccチェック、およびホットスタンバイの両方の目的でSAN）に複製します。最初にセットアップするのは悪夢でした。しかし、一度設定すると非常にうまく機能します。
3つの8-12 TBデータベースがそれぞれ-EMCでホストされていますSANそれぞれが異なるサーバーで実行されています。最初に同じSAN上で複製し、マウントします別のホストがSANに接続し、レプリケートされたコピーを使用してオフラインバックアップとDBCCチェック、およびバッチレポートを実行します。これにはレプリケーションマネージャーを使用します。
また、2行目のバックアップのためにSANからSAN 2日ごとにコピーします。
セットアップするのは悪夢でした-かなりの時間がかかりました。 EMCからDellにバウンスされ、戻ってきました。彼らに怒鳴った後、彼らはついに彼が何をしているかを実際に知っている誰かを送りました。 Netappはかなりの経験があるので、一緒に行きたかったのですが、上司に却下されました。どうやらDellは彼らにより良いリース契約を提供したようです。
公平を期すために、過去2年間で非常によく役立っています。
HTH
私は昨年かそこらでDoubleTakeを使用しました。これにより、70から90（毎月増加するカウント）のデータベースをかなり迅速に高圧縮でDRに複製することができました。 Farseekerが述べたように、ブロックレベルのレプリケーションが可能になり、非常にうまく機能します。また、トランザクションの負荷が大きい場合のキューも可能になります。
私があなたのインスタンスで実際に目にする唯一の問題は、これらのデータベースの重さです。 10GBを超えるデータベースが少なくとも5つあり、ピーク時とジョブ中に大量のトランザクションデータがあり、データベースあたり1日あたり約1〜3GBです。毎月800+ GB以上をネットワーク上で転送する場合（もちろん、圧縮ははるかに少なくなります）。過去15か月間に20以上のデータベースを追加して以来、ディスクキューに関連するIO）が高すぎることがわかりました。したがって、ほとんどのデータベースでこのようなものを使用しようとすると問題が発生する可能性があります。非常にビジーです。多くのキューに入れなければならず、リンクがダウンした場合、データの欠落や受信側になってしまう可能性があります。もちろん、これはDR展開でのみ問題になります。ただし、注意深く監視し、帯域幅を調整してください。キューを抑えるのに大いに役立ちます。
スタンバイサーバーへのログ配布を使用します。ログファイルを処理するため、サーバーへの影響（最初のコピーを除く）はごくわずかです。
15分ごとに実行します（約75のデータベースがあります）が、500のデータベースで15分ごとに実行すると、最後のデータベースが終了するまでに最初のデータベースが期限切れになるため、必要になる可能性があります。少し広げてください。
ログ配布構成をスクリプト化できますが、2つの側（元の側と宛先）で構成する必要があります。私はそれがかなり一握りである可能性があると思います。
もう1つのオプションは、no_oneが提案しているブロックレベルのバックアップです。 Doubletake SQLサーバーのブロックレベルのレプリケーションを実行する製品があります（すでに高価な製品にとっては非常に高価なオプションだと思います）-データとログフォルダーをポイントするだけです。残りはお世話になります。
他の非SQLデータベース（BTrieve）にはDoubleTakeを使用しましたが、非常にうまく機能し、レプリケーションの待ち時間はわずか20秒程度でした。