卸载批处理
有些应用程序要求对数据执行大批量处理操作。在许多情况下,这些批处理操作无法在联机事务处理 (OLTP) 服务器上执行,因为处理开销会影响服务器上的其他操作。在这种情况下,必须在单独的服务器上执行批处理操作。有些情况下,批处理操作只是简单的卸载;而在其他情况下,批处理的结果要被传播回联机处理服务器。
下面的关系图显示了一个将数据复制到批处理服务器的典型方案:
Adventure Works Cycles 示例
Adventure Works Cycles 是一家虚构的制造公司,用于演示数据库概念和方案。有关详细信息,请参阅示例和示例数据库。
Adventure Works Cycles 使用批处理来检查其网站上的信用卡欺诈。将从网站事务收集的数据从为网站提供服务的 Microsoft SQL Server 复制到用于许多 Adventure Works Cycles 应用程序的单独 SQL Server 上。在批处理服务器上,针对信用卡欺诈模式检查数据。虽然欺诈检测产生了少量数据(如果帐户显示可疑活动,则更新少量列的数据),但检查操作包含大量计算并需要丰富的服务器资源。批处理运行后,少量的数据将发送回网站的 OLTP 服务器,同时指出可能存在欺诈迹象的所有帐户。
此方案的一般要求
批处理应用程序通常具有下列要求,相应的复制解决方案必须满足这些要求:
- 系统必须保持事务的一致性。
- 系统的滞后时间应较低:联机处理服务器上的更新必须快速到达批处理服务器。
- 系统的吞吐量应较高:应能处理大量事务的复制。
- 在线处理服务器上的复制处理所需的开销应为最小。
- 数据更改可能会沿两个方向流动:批处理的结果可能被传播回联机处理服务器。
- 批处理服务器所需的数据可能是联机处理服务器上可用数据的子集。
用于此方案的复制类型
SQL Server 使用出版业的术语来描述复制系统的组件。这些组件包括发布服务器、订阅服务器、发布、项目和订阅。
- 在上面的关系图中,联机处理服务器为发布服务器。联机处理服务器上的部分或所有数据都包括在发布中,每个数据表都是一个项目(项目还可以是其他数据库对象,如存储过程)。批处理服务器是发布的订阅服务器,用来接收架构和数据作为订阅。
- 如果结果被传播回联机处理服务器,则批处理服务器同时还是发布服务器(其发布通常与联机处理服务器上的发布相同),而联机处理服务器则订阅此发布。
有关系统组件的详细信息,请参阅复制发布模型概述。
SQL Server 针对不同应用程序的要求提供了不同的复制类型:快照复制、事务性复制和合并复制。最好用事务性复制来实现此方案,这更适合满足上一部分中所述的要求。有关事务性复制的详细信息,请参阅事务复制概述和事务复制的工作机制。
按照设计,事务性复制可处理此方案下列主要要求:
- 事务的一致性
- 较低的滞后时间
- 高吞吐量
- 最低开销
对此方案考虑的选项有筛选、对等事务性复制和双向事务性复制:
- 事务性复制使您可以筛选列和行,因此批处理服务器可以只接收应用程序所需的数据。有关详细信息,请参阅筛选已发布数据。
- 事务性复制使您可以使用对等事务性复制或双向事务性复制选项在多个方向传播更改。有关详细信息,请参阅对等事务复制和双向事务复制。
实现此方案的步骤
若要实现此方案,必须先创建一个发布和若干个订阅,然后再初始化每个订阅。有关各步骤的详细信息,请单击下面的链接:
- SQL Server Management Studio:如何配置对等事务复制 (SQL Server Management Studio)
- 复制 Transact-SQL 编程: How to: Configure Peer-to-Peer Transactional Replication (Replication Transact-SQL Programming)
- 双向事务复制
在对订阅进行了初始化且数据开始在发布服务器和订阅服务器之间流动之后,您可能需要查阅下列主题来了解有关常见管理任务和监视任务的信息: