複製vs同步框架vs服務代理

我已經分別詢問了這些技術，但實際上還沒有找到合適的答案。複製vs同步框架vs服務代理

我們有一個服務器在我們的中央辦公室運行SQL Server有，我們需要在每個位置我們的本地副本數據庫幾大（在這個意義上，DSL是限制因素大）2005企業。我們目前有幾十個地點，需要更多的在線服務。我們需要將這些數據庫同步的位置總數將在未來2年內達到數百個。

我們正試圖解決每個位置的WAN連接問題。這些是DSL線路，並且這些地點的線路並不總是最好的。我們目前遇到的問題是一些地點每小時都會下降。雖然我們正在通過當地電信公司的重新佈線和協助來解決這些問題，但它主要強調了手頭的問題：我們需要雙向同步來處理偶爾連接的問題。

我們嘗試了一段時間的事務複製，雖然它在一段時間內工作，但它對我們來說過於維護，而且它似乎經常隨機錯誤地出現，沒有任何可能的解釋，迫使我們重新初始化訂閱（可能會假設該位置將保持連接足夠長的時間以便一次性獲得整個快照，則需要4小時以上）。我們從頭開始研究自己的解決方案，但鑑於我們需要的規模和可靠性，我不認爲這將是最好的想法。

到目前爲止，我們還看到了同步框架，並經別人，Service Broker的建議。 Sync Framework似乎更適合，但我被告知Service Broker可以更好地擴展並且更可靠？我找不到有關Sync Framework或Service Broker所涉及的開銷的任何經驗數據，因此無法在這方面比較兩者。

我們真正需要的是局端服務器與遠程客戶端，可以自主運行，並可以在需要我們的干預失效的情況下，以管理員報告之間的雙向同步。

有這個問題，所以許多可能的解決方案，所有涉及到完全不同的技術，我需要一個新的關注這一點。

您認爲對我們的情況最佳的解決方案是什麼？爲什麼？

編輯：顯然，升級到SQL Server 2008將輕鬆解決這個問題。不過，我們想先嚐試較便宜的選項。

來源

2010-01-28 Matt

我想我們會看看SQL Server 2008的升級路線。看起來，本地更改跟蹤支持將是實現這一目標的最簡單方法。

來源

2010-01-28 16:10:59 Matt

我沒有任何硬數據可以提供，但我們前段時間在項目中使用了同步框架。我的經驗非常糟糕。它很慢（即使在局域網內同步相對較小的表時），可擴展性也很差，並且需要大量工作來手動處理錯誤情況（它會很樂意生成比WCF默認可以處理的更大的數據包 - 並且只能分割更新當其中一個方法同時進行批處理時）。它只適用於一些選擇數據庫（客戶端必須使用MS SQL Compact Edition，我記得），除非您願意編寫自己的SyncAdapter。

總的來說，很多工作只是爲了解決問題而得到一個脆弱和低效的解決方案。我不會推薦它。

來源

2010-01-28 05:02:08 jalf

謝謝你的回覆。我聽說同步框架v1中出現了類似的問題，但是還沒有發現v2。我相信v2包含更多的SyncAdapter以包含標準的SQL Server實例以及更多抽象類來創建自己的適配器。 – Matt 2010-01-28 05:15:20

我們使用了v2。開箱即用的唯一客戶端數據庫仍然是SQL CE。當然，編寫自己的適配器並不是火箭科學，所以這可能是框架問題中最少的。根據u @ jalf的 – jalf 2010-01-28 08:37:40

什麼是C＃4.5的同步框架的替代？ – Neel 2014-03-21 11:17:25

與SQL Express 2008的R1/R2的一端和中心端多租戶數據庫SQL Server企業可以使用同步framwork。以下是通過安全WCF channel.You的n層同步示例應用程序可以編寫Windows服務數據從後臺同步：

http://www.rajneeshnoonia.com/blog/2012/03/n-tier-sync-framework/

這是前人的精力足夠的能力來處理大量客戶端（千）的。

來源

2012-04-23 10:15:55

複製vs同步框架vs服務代理

回答

相關問題