合並復制的概述

也許讀者對下面的實際例子並不陌生，在某一大型企業的分銷系統中，銷售經理或一 些銷售骨干人員經常要外出處理業務，將簽訂的合同通過手邊的筆記本電腦傳遞到總部銷 售信息數據庫。在這一例子中有兩個主要的特；征任何銷售經理和銷售骨干都可以修改銷 售信息數據庫；只有在進行數據傳遞時才將源數據庫與目標數據庫相連。在SQL Server 中，合並復制為這一情況提供了較好的解決方案。

     合並復制作為一種從出版者向訂購者分發數據方法允許出版者和訂購者對出版數據進 行修改，而不管訂購者與出版者是相互連接或斷開，然後當所有（或部分）節點相連時便 合並發生在各個節點的變化。在合並復制中，每個節點都獨立完成屬於自己的任務，不像 事務復制和快照復制那樣訂購者與出版者之間要相互連接，完全不必連接到其它節點，也 不必使用MS DTC 來實現兩階段提交就可以在多個節點對出版進行修改，只是在某一時 刻才將該節點與其它節點相連（此時所指的其它節點並不一定指所有其它節點），然後將 所發生的數據變化復制到這些相連節點的數據庫中。如果在復制時因更新同一數據而發生 沖突，則數據的最終結果並不總是出版者修改後的結果，也不一定包含在某一節點上所做 的所有修改。因為各節點都有自主權，都可以對出版物（復制數據）進行修改，這樣在按 照所設定的沖突解決規則對沖突處理之後，數據庫最終的結果往往是包含了多個節點的修 改。

    可以看出盡管最後所有的數據庫都有相同的結果集，但這個結果是在多個節點共同 參與下形成的，是多個修改合並到目標數據庫的結果。因此合並復制並不維護事務的一致。
    與創建快照復制和事務復制出版物相比，當創建一個合並出版物時，SQL Server 會對 數據

庫以及出版表進行以下處理（見圖16-54）：

（1） SQL Server 把出版表中的每一行都加上一個標識列，這樣在表的多個拷貝間能 惟一標識出該行。如果基本表上已存在具有ROWGUIDCOL 屬性的標識列，則 SQL Server 將自動把其作為復制表的行標識，如果沒有，則或在創建出版物過 程中這些表被激活時，或在SQL Server Agent 第一次為該出版物提供服務時， SQL Server 將向表中添加一個具有ROWGUIDCOL 屬性的rowguid。

（2） SQL Server 添加一個觸發器來跟蹤每一行或列數據的變化，並把捕捉到的變化 存儲到幾個系統表中，或在創建出版物過程中復制表被激活時，或在SQL Server Agent 第一次為出版物提供服務時，將創建這些跟蹤觸發器。
（3） SQL Server 把用戶跟蹤的系統表添加到數據庫，來執行沖突的檢測，解決和記 錄。MSmerger_contents MSmerger_tombstone 系統表用來跟蹤對出版物中 數據的UPDATE、 DELETE、 INSERTS 操作。 

 

合並復制的執行步驟
合並復制的執行需要快照代理和合並代理。其主要步驟是：
（1） 與快照復制、事務復制中快照代理的作用一樣，合並復制的快照代理在開始復 制之前也要完成二項任務；創建快照文件（同步集合）將存儲在分發者的復制 目錄下；在出版數據庫記錄同步作業。合並代理將初始快照文件分發給訂購者， 從而完成訂購初始化（出版數據庫與訂購數據庫同步）。
（2） 當在某一節點（訂購者）對出版物中表的某一行進行修改時，觸發器會觸發， 並將該行的生成列generation column 設置為零。當合並代理執行時，它把 所有生成列為零的合成一組或多組，凡是新的生成列值比原來的大，則用新值 替換舊值。
（3） 在進行同步處理時，合並代理把所有生成列值為零的列（被修改的列）復制到 所有其它訂購者。
（4） 在目標數據庫，從節點送來的數據與已存在數據進行合並，合並代理來進行沖 突檢測，如果未發生沖突則接收復制數據；如果發生沖突，合並代理根據缺省 或所設定的沖突解決規則來解決沖突。