Article ID: 307356 - View products that this article applies to.
This article was previously published under Q307356
The Merge Agent follows a specific set of rules that govern the order in which the merge process applies changes to articles during the synchronization process.
This article discusses why article processing order is important.
There are two primary reasons why article processing order is important:
For the two reasons that were listed earlier, the order in which the Merge Agent delivers changes to a partner replica is important.
Before beginning a discussion of article processing order, it is important to have an understanding of two key concepts. The two key concepts are as follows:
A nickname is an integer value that the Merge Agent uses to identify an article (a SQL Server table) to merge replication. The merge setup process assigns an article nickname when it adds the article to a merge publication. If an article participates in DRI constraints, the merge setup process tries to generate an article nickname that reflects defined DRI constraints. The merge process assigns tables referenced by a FOREIGN KEY constraint (a parent) a smaller article nickname than that of the referencing table (the child table, or the table on which the FOREIGN KEY constraint is defined).
If a table does not participate in DRI constraints, the merge setup process assigns the article nickname based on the order in which it adds the article to the publication (in ascending order).
A generation is an integer value that the Merge Agent uses to track a logical group of changes to a particular article. All of the changes made to a particular article at a particular replica between merge synchronizations are associated with the same generation. Each time the Merge Agent runs, it closes the existing open generation, and then opens a new generation with which to associate the next set of changes.
Processing INSERTs, UPDATEs, and DELETEsThe Merge Agent partitions the articles for a particular publication into two distinct groups:
The Merge Agent uses the groups to determine the overall processing order of UPDATEs, INSERTs and DELETEs for all articles defined to the publication.
In each of the two respective groups, the Merge Agent processes INSERTs and UPDATEs in ascending article nickname order, and processes DELETEs in descending article nickname order. First, the Merge Agent processes all DELETEs in their entirety in a particular group, followed by UPDATEs and INSERTs (also in a particular group). Conceptually, the Merge Agent appends the two aforementioned groups to one another (not merged) in the order listed previously. The Merge Agent begins by processing DELETEs for the first group, and then extends DELETE processing to the second group and the remainder of changes for the two groups are processed in parallel. Although the Merge Agent maintains article processing order in each respective group, the Merge Agent does not maintain strict article processing order across the two respective groups. As such, in the case of an INSERT or UPDATE, it is possible that changes from the first group with a higher article nickname can arrive ahead of those from the second group with a lower nickname. The converse situation can also occur for a DELETE. Both of these behaviors are by design.
Possible effects of generation batching on article processing orderAs stated earlier, with a generation you can logically group changes (INSERTs, UPDATEs and DELETEs) that occur for a particular article at a particular replica between synchronization sessions. Ultimately, the Merge Agent works with generations when it determines which changes it must exchange between two replicas. The Merge Agent negotiates a common generation at the following points in the synchronization process:
The Merge Agent processes generations in batches, also referred to as generation batches. By default, 100 generations are included in each generation batch that the Merge Agent uploads to the publisher from the subscriber, or downloads to the subscriber from the publisher. The generation batch size is configurable through the
-UploadGenerationsPerBatch and the -DownloadGenerationsPerBatch Merge Agent parameters, or through the Merge Agent profile. In the default case, if there are more than 100 generations that you need to exchange (that is, download and upload, or both) between a publisher (or a re-publisher) and a subscriber, the Merge Agent processes multiple generation batches. The number of batches depends on the number of generations that the Merge Agent has to exchange, and the generations per batch settings in-force for a particular merge session.
In a situation where multiple generation batches are exchanged, the Merge Agent may split related parent and child changes across two separate generation batches. If that is the case, the Merge Agent may deliver a child change in a generation batch ahead of the generation batch that contains the associated parent change. In hierarchical merge topologies that use re-publishers, there is one rare situation in which the splitting of parent and child changes across generation batches can lead to non-convergence. For more information about non-convergence, see the following article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/308266/EN-US/ )PRB: Non-Convergence When SQL Server Processes Child and Parent Generations in Separate Generation Batches
You can increase the -UploadGenerationsPerBatch
and the -DownloadGenerationsPerBatch parameters discussed previously to avoid splitting parent and child changes across generation batches.
Article processing order is maintained in a particular generation batch pursuant to the rules discussed previously. However, the Merge Agent cannot maintain article processing order across generation batches.
Article ID: 307356 - Last Review: April 6, 2011 - Revision: 4.1