2

我已经分别询问了这些技术中的每一种，但确实没有找到合适的答案。

我们的中央办公室有一台运行 SQL Server 2005 Enterprise 的服务器，该服务器有几个大型（在 DSL 是限制因素的意义上说很大）数据库，我们需要在每个位置的本地副本。我们目前有几十个地点，并且需要将更多地点带到网上。在接下来的 2 年内，我们需要将这些数据库同步到的位置总数将达到数百个。

我们正在努力解决每个位置的 WAN 连接问题。这些是 DSL 线路，并且这些位置的布线并不总是最好的。我们目前遇到的问题是，某些地点每小时都会出现故障。虽然我们正在努力通过重新布线和当地电信公司的协助来解决这些问题，但它主要强调了手头的问题：我们需要一个可以处理偶尔连接的双向同步。

我们尝试了事务复制一段时间，虽然它在某些时候有效，但对我们来说维护成本太高，而且它似乎经常随机出错而没有可能的解释，迫使我们重新初始化订阅（这可能需要 4几个小时，假设该位置将保持连接足够长的时间以一次获取整个快照）。我们已经考虑从头开始推出我们自己的解决方案，但考虑到我们需要的规模和可靠性，我认为这不是最好的主意。

到目前为止，我们还研究了 Sync Framework，以及其他人建议的 Service Broker。Sync Framework 似乎更合适，但有人告诉我 Service Broker 可扩展性更好且更可靠？我找不到任何与 Sync Framework 或 Service Broker 相关的开销的经验数据，因此在这方面无法比较两者。

我们真正需要的是中央办公室服务器和远程客户端之间的双向同步，它可以自主运行，并且可以在发生需要我们干预的故障时向管理员报告。

这个问题有很多可能的解决方案，都涉及完全不同的技术，我需要重新审视这个问题。

对于我们的情况，您认为最佳解决方案是什么，为什么？

编辑：显然，升级到 SQL Server 2008 可以轻松解决这个问题。但是，我们想先尝试更便宜的选择。

4

3 回答 3

1

我没有任何硬性数据可以提供，但我们不久前在一个项目中使用了同步框架。我对它的体验真的很糟糕。它很慢（即使在 LAN 上同步相对较小的表），扩展性非常大，需要大量工作来手动处理错误情况（它会很高兴生成比 WCF 默认处理的更大的数据包 - 并且只能拆分更新以一种方式同步，而不是另一种方式。）它只适用于少数选定的数据库（我记得客户端必须使用 MS SQL Compact Edition），除非您愿意编写自己的 SyncAdapter。

总的来说，很多工作只是为了为您的问题找到一个脆弱且低效的解决方案。我不会推荐它。

于 2010-01-28T05:02:08.020 回答
1

您可以在一端使用带有 SQL express 2008 R1/R2 的同步框架，在中央端使用多租户数据库 SQl 服务器企业。下面是通过安全 WCF 通道进行 n 层同步的示例应用程序。您可以编写 Windows 服务来从后端同步数据：

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

它应该足以处理大量客户（数千）。

于 2012-04-23T10:15:55.987 回答
0

我想我们将研究 SQL Server 2008 升级路线。似乎本机更改跟踪支持将是完成此任务的最简单方法。

于 2010-01-28T16:10:59.823 回答