也許讀者對下面的實際例子并不陌生，在某一大型企業的分銷系統中，銷售經理或一些銷售骨干人員經常要外出處理業務，將簽訂的合同通過手邊的筆記 本電腦傳遞到總部銷售信息數據庫。在這一例子中有兩個主要的特;征任何銷售經理和銷售骨干都可以修改銷售信息數據庫;只有在進行數據傳遞時才將源數據庫與 目標數據庫相連。在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) 在目標數據庫，從節點送來的數據與已存在數據進行合并，合并代理來進行沖突檢測，如果未發生沖突則接收復制數據;如果發生沖突，合并代理根據缺省或所設定的沖突解決規則來解決沖突。

關鍵字：SQL Server、數據庫、合并復制