これらのテクノロジーのそれぞれについて個別に質問しましたが、適切な回答が見つかりませんでした。
セントラル オフィスには SQL Server 2005 Enterprise を実行するサーバーがあり、複数の大規模な (DSL が制限要因であるという意味では大規模な) データベースがあり、それぞれの場所でローカル コピーが必要です。現在、数十の拠点があり、さらに多くの拠点をオンラインにする必要があります。これらのデータベースを同期する必要がある場所の総数は、今後 2 年間で数百になります。
各拠点の WAN 接続の問題を克服しようとしています。これらは DSL 回線であり、場所の配線が常に最適であるとは限りません。現在、一部の場所が 1 時間ごとにダウンするという問題が発生しています。再配線と地元の電話会社の支援を受けてこれらの問題を解決するために取り組んでいますが、それは主に当面の問題を浮き彫りにしています。
しばらくの間、トランザクション レプリケーションを試してみましたが、うまくいくこともありましたが、メンテナンスが多すぎて、考えられる説明がなくランダムにエラーが発生することが多く、サブスクリプションを再初期化する必要がありました (これには 4 回以上かかる可能性があります)。スナップショット全体を一度に取得するのに十分な時間、場所が接続されていると仮定すると、数時間)。独自のソリューションをゼロから展開することを検討しましたが、必要な規模と信頼性を考えると、これが最善のアイデアになるとは思いません。
これまで、Sync Framework についても調べてきました。また、他の誰かが提案したように、Service Broker についても調べました。Sync Framework の方が適しているようですが、Service Broker の方がスケーラビリティと信頼性が高いと聞きました。Sync Framework または Service Broker に関連するオーバーヘッドに関する経験的データを見つけることができないため、この点で 2 つを比較することは不可能であることが証明されています。
私たちが本当に必要としているのは、セントラル オフィス サーバーと、自律的に実行でき、私たちの介入が必要な障害が発生した場合に管理者に報告できるリモート クライアントとの間の双方向の同期です。
この問題には非常に多くの解決策が考えられますが、それらはすべてまったく異なるテクノロジに関係しているため、私はこれに目を向ける必要があります。
私たちの状況に最適な解決策は何だと思いますか? その理由は何ですか?
編集: 明らかに、SQL Server 2008 にアップグレードすると、この問題は簡単に解決されます。ただし、最初はより安価なオプションを試してみたいと思います。