用于从主服务器更新从属SQL Server 2008数据库同时最小化中断的模式

Question

我们有一个ASP.NET Web应用程序，由使用SQL Server 2008的许多实例的Web场托管，我们在其中将来自多个源的数据聚合和预处理为针对快速最终用户查询性能而优化的格式（生成5一些表中有-10万行）。聚合和优化由后端服务器上的服务完成，然后我们要将其分发到Web应用程序实例使用的多个只读前端副本，以实现最大的可伸缩性。

我的问题是将这些数据从后端数据库传输到只读前端副本的最佳方法，这种方式不会在此过程中损害其性能。前端Web应用程序实例将处于持续高负载状态，并且需要始终具有良好的响应能力。

后端数据库不断更新，所以我怀疑事务复制不是最好的方法，因为不断更新副本会损害它们的性能。

数据的陈旧性不是一个大问题，因此快照复制可能是可行的方法，但这会导致复制期间性能不佳。

执行放置和批量插入将导致没有用户查询数据的句点。

我真的不想编写一个复杂的集群方法，我们在更新过程中将副本从集群中删除 - 这些行中有什么东西我们可以毫不费力地做，或者有更好的选择吗？

Answer 1

实际上，SQL Server 2005（和2008）中内置了一种技术，旨在解决此类问题。 Service Broker （我将进一步提及SSB）。问题在于它的学习曲线非常陡峭。

我知道MySpace公开了如何使用SSB来管理他们的SQL Server园区： MySpace使用SQL Server Service Broker来保护1 PB数据的完整性。我知道有几个（主要）网站使用类似的模式但不幸的是它们没有公开，所以我不能提到名字。我亲自参与了一些围绕这项技术的项目（我以前是SQL Server团队的成员）。

现在请记住，SSB不是像Replication这样的专用数据传输技术。因此，您将找不到与发布向导和复制的简单部署选项类似的任何内容（检查表并将其转移）。 SSB是一种可靠的消息传递技术，因此它的原语停止在消息交换的层面上，你必须编写利用数据更改捕获，将其打包为消息，并将消息解压缩到目的地的关系表中。

为什么有些公司会像你描述的那样在任务上使用SSB而不是复制，因为SSB在可靠性和可扩展性方面有更好的理由。我知道在1500多个站点之间交换数据的项目，远远超出了Replication的功能。 SSB也从物理拓扑中抽象出来：您可以移动数据库，重命名机器，重建服务器而无需更改应用程序。因为数据流发生在逻辑路线上可以即时添加到新拓扑中。 SSB还具有长时间的连接和停机时间，能够在数小时，数天甚至数月的断开连接后恢复数据流。通过引擎集成实现高吞吐量（SSB是SQL引擎本身的一部分，不是sattelite应用程序和复制等过程的集合）意味着积压的变更可以在合理的时间内处理（我知道正在经历一半的站点）每分钟百万次交易）。 SSB应用程序通常依靠内部激活来处理收到的数据。 SSB还有一些独特的功能，如内置负载均衡（通过路由）具有粘性会话语义，支持死锁免费应用程序特定的相关处理，优先级数据交付，对数据库镜像的特定支持，基于证书的身份验证，用于跨域操作，内置持久计时器等等。

这不是一个特定的答案'如何将数据从服务器A上的表T移动到服务器B'。更多关于如何“在服务器A和服务器B之间传输数据”的通用技术。

Answer 2

我以前从未处理过这种情况，但确实想出了一个可能的解决方案。基本上，它需要更改主数据库结构。您将保留此数据的修改记录，而不是存储数据。因此，如果添加了记录，则存储“表X，插入具有以下值的新记录：...”。通过修改，只需存储表，字段和更改的值。删除时，只需存储删除的记录。每个修改都将以时间戳存储。

您的客户端系统将保留其数据库的本地副本，并将在特定日期/时间之后定期请求所有数据库修改。然后，您可以在本地数据库上执行这些修改，它将再次更新。

后端？好吧，它只会保留一个修改列表，也许还有一个包含基础数据的表。保持修改也意味着你要记录历史，让你问一下系统一年前的样子。

这将如何执行取决于后端数据库上的修改数量。但是如果你每15分钟请求一次更改，那么每次都不应该有那么多的数据。

但是，我再也没有机会在真正的应用程序中解决这个问题，所以它对我来说仍然是一个理论原则。看起来很快但需要很多工作。

Answer 3

选项1 ：编写应用程序以使用行级事务传输数据。它可能需要更长的时间，但不会导致使用数据中断站点，因为行在读取之前和之后都存在，只有新数据。此处理将在单独的服务器上进行，以最大限度地减少负载。

在sql server 2008中，您可以将 READ_COMMITTED_SNAPSHOT 设置为 ON ，以确保正在更新的行不会导致阻塞。

但基本上所有这个应用程序都会读取新数据，因为它可以从一个数据库进入另一个数据库。

选项2 ：将数据（表或整个数据库）从聚合服务器移动到前端服务器。如果可能，自动执行此操作。然后切换Web应用程序以指向新数据库或表以供将来请求使用。这有效，但需要控制您可能没有的网络应用程序。

选项3 ：如果您正在谈论单个表（或者这可能适用于多个表），您可以做的是视图交换。因此，您针对指向表A的sql视图编写代码。您是否在表B上工作，当它准备就绪时，您将视图更新为指向表B.您甚至可以编写一个确定活动表并自动执行的函数整个互换的东西。

选项4 ：您可以使用类似服务器的字节级复制之类的东西。这听起来很可怕。这基本上是将服务器从A点复制到B点，直到将其复制到非常多的字节。它主要用于灾难恢复情况，听起来这可能是一种有点/不同的DR情况，但不是真的。

选项5 ：放弃并学习如何出售保险。 ：）