了解合并复制文章处理顺序

本文介绍如何了解合并复制文章处理顺序。

原始产品版本:  SQL Server
原始 KB 编号:   307356

摘要

合并代理遵循一组特定的规则,这些规则控制在同步过程中合并过程对文章应用更改的顺序。

本文讨论文章处理顺序为什么很重要。

详细信息

文章处理顺序非常重要有两个主要原因:

  • 在许多情况下,合并代理必须按特定顺序处理对参与声明性参照完整性 (DRI) 约束的文章的更改,以获得最佳性能。 如果不是,合并代理可能必须重试数据操作语言 (DML) 操作,它尝试的顺序不正确 (即尝试在其父行之前插入子行) 。

  • 使用触发器维护参照完整性的应用程序需要合并代理以特定顺序发送更改。 如果合并代理以不正确的顺序发送更改,则触发器很可能回滚更改,并且更改不会在整个复制拓扑中传播。

备注

将 DML 更改操作应用于合作伙伴副本时,合并代理可以绕过 FOREIGN KEY 约束计算SQL用户触发器执行。 为此,必须使用 NOT FOR REPLICATION 选项创建 FOREIGN KEY 约束和/或用户触发器。 在这两种情况下,合并过程都假定 SQL Server 在针对对象执行原始用户启动的更改时已成功评估业务逻辑,并且当将数据复制到合作伙伴副本时,无需重新计算这些条件。 通过此方式使用 NOT FOR REPLICATION 的主要好处是提高了性能。 有关 NOT FOR REPLICATION 选项以及如何正确使用该选项的详细信息,请参阅 SQL Server 2000 Books Online 中的 NOT FOR REPLICATION 选项主题。

由于前面列出的两个原因,合并代理向合作伙伴副本传递更改的顺序非常重要。

在开始讨论文章处理顺序之前,了解两个关键概念非常重要。 两个关键概念如下所示:

  • 文章昵称。

  • 一代。

下面是对两个概念的说明。

  • 文章昵称

    昵称是一个整数值,合并代理使用该整数值来标识要合并 (SQL Server表) 文章。 合并设置过程在将文章添加到合并出版物时分配文章昵称。 如果文章参与 DRI 约束,则合并设置过程将尝试生成反映定义的 DRI 约束的文章昵称。 合并过程将 FOREIGN KEY 约束引用的表 (父) 一个比引用表 (子表或定义 FOREIGN KEY 约束的表) 中小的文章昵称。

    如果表格不参与 DRI 约束,合并设置过程将基于文章添加到出版物的顺序分配文章昵称 (以升序) 。

  • Generation

生成是一个整数值,合并代理使用该整数值跟踪对特定文章的逻辑更改组。 在合并同步之间的特定副本中对特定文章进行的所有更改都与同一代相关联。 每次运行合并代理时,它将关闭现有的开放生成,然后打开新一代,以与下一组更改关联。

处理 INSERT、更新和删除

合并代理将特定出版物的文章分为两个不同的组:

  • 合并代理将任何联接筛选器关系中未涉及的文章(不通过 DRI 相关)放入将筛选器加入一个组所涉及的任何文章。

  • 合并代理将联接筛选器关系中明确涉及的文章和通过 DRI 加入筛选器文章相关的文章放入另一个不同的组中。

合并代理仅将定义给出版物的每篇文章添加到上述组之一。

合并代理使用组来确定 、 和 定义为出版物的所有 UPDATEs INSERTs 文章的总体处理 DELETEs 顺序。

在两个各自的组中,合并代理处理和按升序的文章昵称顺序,并按降序文章 INSERTs UPDATEs DELETEs 昵称顺序处理。 首先,合并代理处理整个特定组,然后处理和 (DELETEs UPDATEs 特定组 INSERTs) 。 从概念上说,合并代理会将上述两个组附加到另一个 (,) 按前面列出的顺序合并。 合并代理首先处理第一个组,然后将处理扩展到第二个组,然后并行处理两个组的剩余 DELETEs DELETE 更改。 尽管合并代理在每个各自的组中保持文章处理顺序,但合并代理不会在两个各自的组中保持严格的文章处理顺序。 因此,在 或 的情况下,具有更高文章昵称的第一个组的更改可能会先于昵称较低的第二 INSERT UPDATE 个组的更改到达。 对于 ,也会发生相反的情况 DELETE 。 这两种行为都是设计使的。

生成批处理对文章处理顺序的可能影响

如前面所述,通过一代,可以在逻辑上 (更改,) 特定文章在同步会话之间的特定副本 INSERTs UPDATEs DELETEs 上发生的更改分组。 最终,当合并代理确定必须在两个副本之间交换哪些更改时,合并代理将处理生成。 合并代理在同步过程的以下点协商一个通用生成:

  • 在将订阅者中的更改上载到发布者之前。

  • 在将更改从发布者下载到订阅者之前。

合并代理使用此常见生成作为起始点,在合并同步的上载和下载阶段枚举要发送到合作伙伴副本的代。

合并代理分批处理生成,也称为生成批处理。 默认情况下,合并代理从订阅者上载到发布者,或从发布者下载到订阅者的每一代中都包含 100 代。 生成批次大小可以通过 和 Merge Agent 参数配置,也可以 -UploadGenerationsPerBatch -DownloadGenerationsPerBatch 通过合并代理配置文件进行配置。 在默认情况下,如果需要交换 ((即,在发布者 (或重新发布服务器) 和订阅者之间下载和上载) ,需要交换的生成数超过 100 个,则合并代理将处理多个生成批处理。 批处理数取决于合并代理必须交换的生成数,以及特定合并会话每批设置的强制生成数。

在交换多个生成批处理的情况下,合并代理可能会将相关的父更改和子更改拆分到两个单独的生成批处理中。 如果是这种情况,合并代理可能会先于包含关联父更改的生成批次在生成批处理中传递子更改。 在使用重新发布者的分层合并拓扑中,在极少数情况下,跨生成批处理拆分父项和子项更改可能会导致不融合。 有关非融合性详细信息,请参阅以下文章:

在单独生成SQL Server处理子代和父代时不收敛。

您可以增加 和 -UploadGenerationsPerBatch 前面 -DownloadGenerationsPerBatch 讨论的参数,以避免跨生成批次拆分父和子更改。

按照前面讨论的规则,在特定的生成批处理中维护文章处理顺序。 但是,合并代理无法维护各生成批次中的文章处理顺序。