オフサイトコピーのためのSQL Serverレプリケーション
社内にはプライマリSQLサーバーがあります（現時点では15台のプライマリサーバー（全体で約500データベース）。ほとんどのサーバーは16進コアプロセッサを搭載しています）。
これらは、近くの建物にある他のバックアップサーバーにミラーリングされます（専用の0msファイバーリンクを介して）。
私たちがしたいことは、（はるかに大きなDRプロジェクトの一部として-つまり、私たちの地域に通信の問題がある場合）離れた場所にあるオフサイトのデータセンターにデータのライブコピーを維持することです。
現在、SQL Server 2008 R2-Standardエディションを使用しています。
SQL Server 2008 R2の「スタンダードエディション」を使用すると、非同期は「エンタープライズエディション」機能になるため、同期ミラーリングに限定されます。
オフサイト同期ミラーリングを使用したテストを実施しましたが、レイテンシが原因でそれは無意味になりました。
SQL Server 2012 EnterpriseにアップグレードしてAlwaysOn可用性グループを実装したいのですが、会社はSQLライセンスをアップグレードするために£100,000以上を費やすことを望んでいません（コアライセンスあたりの2012のライセンス+六角コアプロセッサ=重大な失敗）-彼らは、2008 Enterpriseにアップグレードするためにお金を使うことすらしません。そのため、非同期のミラーリングもウィンドウの外に出ます。
したがって、これらの財務上の制約に縛られている私は、2008 R2 Standardエディションで立ち往生しています。
私に残された唯一のオプションは、ログ配布と複製です（何かを見逃した場合は訂正してください）-ログ配布は大雑把です-しかし、適切に管理すると実現可能になる可能性があるため、今のところ、それを後回しにしています。
私の質問：
- SQL Server 2008 R2 Standardには、オフサイトレプリケーションを実行するために必要なすべてのレプリケーション機能がありますか？
- 社内サーバーのオフサイトデータセンターへのレプリケーション（レイテンシ20〜30ミリ秒）は、プライマリサーバーのパフォーマンスに影響を与えることなく実行できますか（ "プリンシパル"サーバーにレプリケーションディストリビューターを設定してもかまいません）。
- レプリケーションがインスタンスレベルのレプリケーションソリューションではない場合、この管理で複数のDBAが処理できますか？ （私はすでに15のPrincipleサーバーとそのミラー対応物を管理していることを前提としています-確かに多くの自動化があります）
- 既存のミラーリング構成に影響を与えることなく、プライマリからのレプリケーションは可能でしょうか。パブリッシャーではなくサブスクライバーをミラーリングすることがベストプラクティスであると理解していますが、これは正しいですか。
- レプリケーションバージンがあなたが私の注意を喚起する必要があることを忘れている何か他にありますか？
あなたが説明したことに基づいて、ログ配布が進むべき道になるでしょう。ログシッピングは古くからあり、試され、真実です。
レプリケーションは非常に壊れやすく、特に新しいテーブルを追加してそれらのテーブルをレプリケーショントポロジに追加する場合は、大量の障害が発生する可能性があります。
2012年のアップグレード費用については、あなたが思っているほど悪くはないかもしれません。ソフトウェアアシュアランスとエンタープライズアグリーメントをお持ちであれば、ライセンスにかかる費用を大幅に節約できます。
ログ配布は「粗雑」（私はそれを簡単に呼ぶ方がいい）かもしれませんが、レプリケーションは複雑で、私の経験では脆弱です。回避できるのであれば、複雑さを加えたくないでしょう。壊れたレプリケーション設定を修正するために、ある種の英雄的な経験をする必要はありません。
これらすべてのデータベースのレプリケーション構成を管理することは、問題の原因となります。 500個のデータベースでこれらの変更をテストすることは、それ自体、キャリアではないにしても、非常に大規模なプロジェクトであるため、データベーステーブルを変更するレプリケーションの形式は使用できません。サブスクライバー側でパフォーマンスの問題が発生し始める可能性があり、Fillfactor、メンテナンスプラン、およびその他の同様の複雑な問題を検討し始める必要があります。プライマリサーバーから「ローカル」セカンダリサーバーに切り替える必要がある場合はどうなりますか？すべてのレプリケーション構成をやり直しますか？それは大きな仕事になりそうです。自動化する場合、それは自動化の作成とテストに費やされる時間であり、それらの500データベースを変更するときにそれを調べる必要があります。
SQL Server 2005までのログ配布はDRにあったことを思い出してください。これは魅力的ではありませんが、機能します。
TL; DR- Simplerの方が優れています。ログ配布を使用します。