Processing INSERTs, UPDATEs, and DELETEs
The Merge Agent partitions the articles for a particular publication into two distinct groups:
- The Merge Agent places articles that are not involved in any join filter relationships, and not related through DRI to any articles involved in join filters into one group.
- The Merge Agent places articles that are explicitly involved in join filter relationships, and articles related to join filter articles through DRI into a second distinct group.
The Merge Agent adds each article defined to the publication to only one of the preceding 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 order
As 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:
- Before it uploads changes from the subscriber to the publisher.
- Before it downloads changes from the publisher to the subscriber.
The Merge Agent uses this common generation as the starting point when enumerating the generations to send to a partner replica during the upload and download phases of merge synchronization.
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:
308266 PRB: Non-Convergence When SQL Server Processes Child and Parent Generations in Separate Generation Batches
You can increase the
-UploadGenerationsPerBatchand 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.