复制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服务代理

回答

相关问题