SQL Server 2000 發佈與訂閱

SQL Server 2000 發佈與訂閱

爲快照複製制定計劃

快照複製需要在以下方面制定計劃：

     傳輸和存儲快照文件。

     調度快照。

傳輸和存儲快照文件

可以選擇在一個默認位置或非默認位置存儲快照文件，默認位置一般位於分發服務器上。備用位置可以在另一臺服務器、一個網絡驅動器或可移動媒體（如光盤或可移動磁盤）上。也可以將快照文件保存到文件傳輸協議 (FTP) 站點以供訂戶以後檢索。

此外，可以通過將數據寫爲 Microsoft CAB 文件格式來壓縮快照文件，以改善網絡性能。

當制定傳輸與存儲快照文件計劃時，估計在快照文件位置和接收快照文件的訂閱服務器需要的磁盤空間。

一個快照需要的空間大小受幾個因素影響，其中包括已發佈項目的大小及數目。快照文件可以在分發服務器上的默認快照文件夾或可選位置中創建。壓縮可選位置中的快照文件可以減少所需的總空間。

當在同一個驅動器的默認文件夾和備用位置創建快照文件時，快照文件首先在默認文件夾中創建，然後被複制到備用位置。如果使用壓縮快照文件，則在將這些文件放入可選快照位置之前已經進行復制和壓縮。在這種情況下，所有快照文件需要的總空間是默認位置中原始快照文件的大小與可選位置中壓縮快照文件的大小之和。

如果備用存儲位置與默認位置不在同一驅動器上，那麼默認位置需要的空間就是快照文件的大小。可選位置需要的空間是壓縮快照文件的總大小。
調度快照

併發快照處理是爲事務複製提供的，而優化的合併快照生成是爲合併複製提供的。從概念上講，併發快照處理類似於數據庫上的更新繼續的同時執行數據庫備份的方式。

使用併發快照處理和事務複製，在快照代理程序運行時，它將臨時共享鎖放置在發佈表上，將該錶快速發佈以便數據庫中的數據修改能夠繼續執行。此時所做的數據修改成爲初始快照的一部分。快照應用於訂閱服務器，且分發代理程序協調每個被捕獲的事務以查看它是否已被傳送到訂閱服務器。在此調節過程中，訂閱服務器上的表也臨時鎖定。

若要使用戶不能臨時添加或更新表的可能性最小化：

     可能的情況下，選擇帶有事務複製的併發快照處理。發佈服務器上的共享鎖只能控制幾秒鐘。

     識別所需要的數據更新量最小的時機，並相應調度代理程序。與備份一樣，生成快照可能會消耗大量資源，在生成期間該開銷會降低其餘系統性能。

若要爲運行快照代理程序制定最佳的調度計劃，請計算快照代理程序完成快照所需的時間。因爲快照是用 bcp 創建的，所以請對數據集執行大容量複製測試並測定其完成時間。如果數據集很大，請對數據集的某個示例執行大容量複製，並推斷整個數據集的花費時間。

如果關心數據庫內的中斷活動，那麼另一個選擇便是不應用快照。可以手工設置訂閱服務器，例如從數據庫轉儲。這稱爲手工應用初始快照。

爲事務複製制定計劃

事務複製需要在以下方面制定計劃：

     事務日誌空間。

     分發數據庫的磁盤空間。

     要發佈的各個表的主鍵。

     即時更新和排隊更新。

     轉換複製的數據。

     事務複製中的 text 和 image 數據類型。

     標識範圍。

     約束和 NOT FOR REPLICATION。

事務日誌空間

對於將要在事務複製中發佈的各個數據庫，確保分配給事務日誌足夠的空間。已發佈數據庫的事務日誌可能需要比同樣的、未發佈數據庫的日誌更多的空間。這是因爲日誌記錄在移動到分發數據庫之後纔會被清除。

如果分發數據庫不可用，或者日誌讀取器代理未在運行，那麼發佈數據庫的事務日誌將繼續增長。除非完全關閉數據庫的複製，否則晚於最先發布但尚未傳入分發數據庫的事務日誌無法被截斷。建議將事務日誌文件設置爲自動增長，以便日誌可以適應這些環境。
分發數據庫的磁盤空間

如果計劃創建事務發佈，並使快照文件可立即爲訂閱服務器所用，請爲分發數據庫分配足夠的磁盤空間，以便存儲最後一次快照之後的所有事務。使快照文件可立即爲訂閱服務器所用，儘管這樣可提高新的訂閱服務器訪問發佈的速度，但是該選項要求分發數據庫擁有更大的磁盤空間。這還意味着每當快照代理程序運行時，將會生成一個新的快照。如果不使用該選項，並不允許匿名訂閱，則只有存在新的訂閱時才需要生成新的快照。

分發數據庫立即開始收集事務，並繼續保存它們，直到再次運行快照代理程序（無論以調度還是手工運行）。在下一次快照代理程序運行後，清除任務開始通過從第一個快照中刪除行來清除和減小分發數據庫的大小。因此，如果使用默認的調度，即每天運行一次快照代理程序，那麼必須具有足夠的磁盤空間以存儲一天中發生的所有事務。

類似地，如果計劃創建事務發佈並允許對發佈的匿名訂閱，那麼必須讓分發數據庫擁有足夠的磁盤空間以存儲自上次快照後的所有事務。允許匿名訂閱還意味着每當運行快照代理程序時都會生成新的快照。

在以上兩種情況下分配更多磁盤空間的另一個方法是：比每天運行一次（默認）更頻繁地運行快照代理程序以使分發數據庫中必須保留的命令較少。但是，生成快照非常消耗資源，會暫時影響性能。縮短分發保持期（在發佈服務器和分發服務器屬性對話框中）也有助於保留較少的命令，因爲分發清理代理程序由分發保持期控制，並將已複製的事務從分發數據庫刪除。
主鍵

在事務複製中所有已發佈的表都必須包含一個已聲明的主鍵。通過用 Transact-SQL 語句 ALTER TABLE 爲現有的表添加一個已聲明的主鍵，可以使該表爲發佈做好準備。
事務複製中的 text 和 image 數據類型

在事務發佈中複製 text 和 image 數據類型的過程受以下因素的影響：

     支持在發佈服務器上對 text 和 image 列使用 INSERT、UPDATE 和 DELETE 語句，而沒有特殊考慮事項。但是，這些列不能由使用快照複製或事務複製和即時更新或排隊更新訂閱的訂閱服務器更新。

     在用於複製的已發佈表上，可以使用帶 WITH LOG 選項的 WRITETEXT 和 UPDATETEXT 來複制日誌記錄文本操作。不支持爲複製而發佈的 text 或 image 列，而該複製是使用帶有 WITH NO_LOG 選項的 WRITETEXT 和 UPDATETEXT 操作的複製，這是因爲複製讀取事務日誌。

     僅當所有訂戶都運行 Microsoft SQL Server 6.0 版或更高版本訂閱服務器時，才能執行 UPDATETEXT 操作。WRITETEXT 操作將被複製爲 UPDATE 語句，從而使 WRITETEXT 不但實現到 SQL Server 的複製，而且實現到 ODBC 訂閱服務器的複製。（UPDATETEXT 操作僅被複製爲 UPDATETEXT。）

     如果要修改多個 text 列，則不使用自定義過程，因爲其它 text 列的值無日誌記錄。相反，將生成一個標準的 UPDATE 語句。

     可配置參數 max text repl size 控制可被複制的 text 和 image 數據的最大字節數。這樣可允許支持不能處理較大 text 和 image 值的 ODBC 驅動程序和 SQL Server 實例，以及具有系統資源（虛擬內存）限制的分發服務器。當發佈 text 或 image 列，並且運行超過配置限制的 INSERT、UPDATE、WRITETEXT 或 UPDATETEXT 操作時，操作將失敗。

     使用 sp_configure 系統存儲過程可設置 max text repl size 參數。

     當發佈 text 和 image 列時，文本指針應當在與 UPDATETEXT 或 WRITETEXT 操作（並可重複讀取）相同的事務內檢索。例如，不要在一個事務中檢索文本指針，然後卻在另一個事務中使用它。它可能已移動並失效。

     另外，在獲得文本指針後，不應在執行 UPDATETEXT 或 WRITETEXT 語句之前，執行任何可能改變文本指針所指向的文本位置的操作（例如更新主鍵）。

      以下使用 UPDATETEXT 和 WRITETEXT 操作處理要複製數據的推薦方法：
         1. 開始事務。

         2. 獲得帶有可重複讀取隔離的文本指針。

         3. 在 UPDATETEXT 或 WRITETEXT 操作中使用文本指針。

         4. 提交事務。

      說明  如果未在同一事務中獲得文本指針，則允許在發佈服務器處進行修改，但更改不會發布到訂閱服務器。

在評估訂閱服務器數據庫時，需要考慮的一個重要因素是：所複製的 text 和 image 列的文本指針將在訂閱服務器表上被初始化，即使它們在發佈服務器上未被初始化。因此，即使被分發任務添加到訂閱服務器表中的各個 text 和 image 列中沒有內容，它們也至少要佔用 43 字節的數據庫存儲空間。
爲合併複製制定計劃

合併複製需要在以下方面制定計劃：

     timestamp 列。

     標識範圍。

     數據完整性。

     主鍵。

     與可選同步夥伴同步。

     行級跟蹤和列級跟蹤。

     觸發器和業務規則。

     合併複製中的 text 和 image 數據類型。

     衝突解決。

     聯機脫機應用程序的臨時維護

timestamp 列

合併複製支持 timestamp 列。雖然複製 timestamp 列，但不復制 timestamp 的字面值。當在訂閱服務器處應用初始快照行時，將重新生成 timestamp 值。這將允許訂閱服務器處的客戶端應用程序使用 timestamp 值以執行像樂觀併發控制這樣的功能。在那些情況下，用於執行樂觀併發控制的 ODBC 驅動程序、OLE DB 提供程序、DB-Library 遊標或服務器遊標會對更新行的 timestamp 值與原始行的當前值進行進行比較。如果 timestamp 值不相同（表示某一行已經更改），那麼應用程序能夠執行適當的操作（例如回滾事務或重讀數據）。因爲 timestamp 值在訂閱服務器重新生成，所以當執行項目驗證時，將篩選出 timestamp 列。
數據完整性

因爲合併複製可傳播在訂閱服務器處所做的更改，所以必須確保在各個訂閱服務器處保留應用程序的完整性。所有用來驗證發佈服務器處數據更改的表應當也位於訂閱服務器上。

提供選項以確保由合併代理程序用來連接發佈服務器的登錄也可用於控制以下情況：只有經過身份驗證用戶才能將在訂閱服務器上所作的數據更改傳播到發佈服務器。
外鍵

當創建合併發佈時，指定作爲項目包含在此發佈中的表。如果包含帶有外鍵的表，那麼所引用的表也應包含在發佈中。如果試圖向引用某個主鍵的項目中添加新行，而該主鍵位於缺少的表中，那麼插入將失敗，因爲 SQL Server 2000 無法找到所需的主鍵。如果試圖更新項目中現有行中的數據，那麼更新將成功，因爲 SQL Server 2000 不必添加新行和關鍵字。

在創建合併發佈後，可對其進行修改以包含附加的項目。如果發現必須用額外的行來更新項目，而不僅僅靠對現有行的修改來更新，那麼可向發佈中添加任何缺少的引用表。請使用發佈屬性對話框添加缺少的表。
與可選同步夥伴保持同步

要合併發佈的訂閱服務器可與訂閱起源所在的發佈服務器以外的其它服務器保持同步。與可選同步夥伴的同步使得訂閱服務器即使在主發佈服務器不可用的情況下仍可同步數據，或由於物理位置可與另一同步夥伴連接（例如，正訪問遠程辦公室且可以與那裏的可選同步夥伴連接）的情況下，仍可使數據同步。

應該決定合併複製訂閱服務器是否有必要擁有可選同步夥伴，併爲同步準備這些備用服務器。
衝突檢測和解決

在決定合併複製衝突的檢測和解決方案時，可指定是在行級識別衝突，還是在列級識別衝突。

決定是使用行級跟蹤還是列級跟蹤，應根據是將行內的任何更改視爲衝突（行級跟蹤），還是允許不同的用戶同時更新同一行而不是同步處理間的同一列（列級跟蹤）。

選擇使用行級還是列級跟蹤應當基於應用程序，以及是要將對錶中同一行的任何更改當作衝突，還是不同的用戶可以同時更新同步處理間的同一行，而不是同一列。例如，在某些應用程序中，通過使用列跟蹤來合併對不同列的更改視爲是可接受的。這意味着如果發佈服務器更改了列 1，訂閱服務器更改了列 2，合併進程接受發佈服務器對列 1 所做的更改以及訂閱服務器對列 2 所做的更改。而有些應用程序可能要求對多個站點的相同行所做的更改（即使值位於不同列）應視爲衝突，並在行級進行檢測和解決。
觸發器和業務規則

您應當清楚所複製表上的所有觸發器和約束。在未制定計劃的情況下，觸發器和約束可與表一起復制，並可導致合併複製過程中反覆出現衝突。
合併複製中的 text 和 image 數據類型

只有當 UPDATE 語句顯式修改過 text、ntext 和 image 列時，合併複製纔會支持對這些列的複製，因爲這將導致觸發器激發更新元數據以確保事務傳播到其它訂閱服務器。

只使用 WRITETEXT 和 UPDATETEXT 操作不會將更改傳播至其它站點。如果應用程序使用 WRITETEXT 和 UPDATETEXT 更新 text 或 ntext 列，請在同一事務中，顯式地將一個虛 UPDATE 語句添加到 WRITETEXT 或 UPDATETEXT 操作之後，以啓動觸發器，因而保證更改將傳播到其它站點。
使用 Northwind 數據庫並更新 Employees 表中的 Notes 列（數據類型爲 ntext）：

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
DECLARE @mytextptr varbinary(16)
SELECT @mytextptr = textptr(Notes)
FROM Employees
WHERE EmployeeID = '7'
   IF @mytextptr IS NOT NULL
BEGIN
UPDATETEXT Employees.Notes @mytextptr 0 NULL 'Terrific job this review period.'
-- Dummy update to fire trigger that will update meta data and ensure the update gets propagated to other Subscribers.
UPDATE Employees
-- Set value equal to itself.
SET Notes = Notes
WHERE EmployeeID = '7'
END
COMMIT TRAN
SET TRANSACTION ISOLATION LEVEL READ COMMITTED

聯機脫機應用程序的臨時維護

在爲使用複製的聯機脫機應用程序制定計劃時，要計劃應用程序部署的臨時維護以及把新數據集傳輸到脫接訂閱服務器的方法。

儘管 SQL Server 2000 複製允許對臨時連接或使用慢速鏈接的訂閱服務器進行充分的數據訪問，仍需爲應用程序的臨時維護制定計劃，可能的話還需爲在訂閱服務器中重新應用快照制定計劃。

爲複製選項制定計劃

在制定複製計劃時需要額外考慮一些複製選項，其中包括即時更新、排隊更新、將排隊更新作爲故障轉移的即時更新和轉換複製數據。如果用戶不需要在訂閱服務器更新數據，請考慮使用快照複製或不帶即時更新或排隊更新選項的事務複製，這樣更易於配置和管理複製。
即時更新或排隊更新訂閱需要考慮的因素

計劃即時更新或排隊更新訂閱需要考慮的因素有：

     用於將數據行添加到表中的 INSERT 語句必須包含列的列表。

     使用即時更新或排隊更新選項的訂戶不能在訂閱服務器上重新發布覆制數據。

     訂戶不能更新或插入 text 或 image 值。

     在發佈爲即時更新訂閱或排隊更新訂閱啓用後，該選項無法爲發佈禁用（儘管訂閱不需要使用它）；若要刪除該選項，必須刪除該發佈並創建一個新發布。

     快照複製不要求使用表中的主鍵。但是，自身事務複製或帶有任何可更新訂閱的快照複製不要求使用主鍵。

     如果啓用發佈上的即時更新和或排隊更新，也無法使用可轉換訂閱。如果已選擇使用即時更新和或排隊更新，創建發佈嚮導中將不顯示轉換已發佈的數據頁。

即時更新訂閱需要額外考慮的因素

即時更新允許快照複製和事務複製訂戶在訂閱服務器上更新已複製數據，並將更改傳播至發佈服務器，然後傳播到所有其它訂閱服務器。

在計劃使用帶有即時更新的快照複製或事務複製時，請考慮以下因素：

     使用 uniqueidentifier 列跟蹤更新。uniqueidentifier 列將自動添加到發佈中使用的任何表中。添加該列需要使用 INSERT 語句以獲得列的列表。如果使用 Microsoft SQL Server 7.0 版中的即時更新，並正升級到 SQL Server 2000，將需要再次訂閱發佈。

     使用此選項，在發佈服務器和訂閱服務器兩處都使用兩階段提交協議 (2PC) 分發和執行更新：一相在訂閱服務器本地，一相在發佈服務器。這需要做更改的發佈服務器和訂閱服務器可用，且互相連接。

     即時更新與發佈服務器的訂閱連接（由 sp_link_publication 控制）在創建登錄映射時，對 SQL Server 身份驗證可使用安全模式 0，對鏈接服務器定義可使用安全模式 2。發佈訪問列表 (PAL) 必須至少包括一個 SQL Server 身份驗證帳戶，除非用戶使用安全模式 2 並配置了委託（通過配置委託可以設置 Windows 身份驗證使用模式 2）。可以通過委託喚醒調用訂閱服務器上的 INSERT、UPDATE 和 DELETE 觸發器，以 Windows 用戶帳戶與發佈服務器建立連接。若要設置委託，請參見

排隊更新訂閱需要額外考慮的因素

排隊更新允許快照複製和事務複製訂戶修改已發佈的數據，而不必一直連接在發佈服務器上。

當創建發佈時啓用排隊更新選項，一個啓用了排隊更新的訂戶對已發佈數據執行了插入、更新或刪除操作，所做的更改將存儲在隊列中。當網絡連接恢復後，在發佈服務器上經過排隊的事務將進行異步應用。

當計劃使用帶有排隊更新的快照複製或事務複製時，請考慮以下因素：

     由於更新異步傳播至發佈服務器，所以發佈服務器或另一臺訂閱服務器有可能更新同一數據，而在應用更新時會發生衝突。當創建發佈時，需要選擇適當的衝突解決策略。

     對於快照複製，表應至少擁有一個唯一索引，且最好有一個主鍵。對於事務複製，表必須擁有一個主鍵。

     如果訂閱服務器數據庫進行了水平分區，且在分區中有在訂閱服務器上存在而在發佈服務器上不存在的行，那麼訂閱服務器將無法更新這些預先存在的行。在試圖更新這些行時返回錯誤。應當先將這些行從表中刪除，然後再次添加。

     用標識範圍管理標識值以確保不同的訂戶具有不同的標識值。

轉換已發佈數據需要考慮的因素

藉助於數據轉換服務 (DTS) 的功能，可在複製過程中轉換數據。創建自定義水平和垂直數據分區，創建諸如數據類型映射、列操作和字符串操作的數據轉換，都是轉換已發佈數據的例子。

在制定轉換複製數據計劃時，請考慮以下因素：

     可轉換訂閱的快照數據僅限於字符模式；無法對本機格式（通常應用速度更快）使用 DTS。

     在爲可轉換訂閱啓用發佈後，選項無法停用；必須刪除現有的發佈並創建一個新的發佈，但是如果啓用了選項，訂閱無須使用它。

     無法對可轉換訂閱使用即時更新或排隊更新選項（轉換映射爲單方向，即從發佈服務器到訂閱服務器）。

     儘管使用轉換已發佈數據嚮導會創建一個 DTS 包，但是這種類型的 DTS 包不能在複製外執行（從 DTS 設計器或命令提示符狀態下）。但是，可以在允許轉換已發佈數據的事務發佈和快照的複製過程中使用以 DTS 工具創建的包。

     將 DTS 轉換引入複製將增加開銷並降低分發性能。數量取決於轉換的複雜程度。但不影響日誌讀取器代理程序的性能。

合併複製或可更新訂閱

當需要在訂閱服務器上對複製數據進行更新時，可使用帶可更新訂閱選項的快照複製或事務複製，也可使用合併複製。選擇的方式取決於複製拓撲和應用程序及其用戶的需要。

在以下情況下使用合併複製。     在以下情況下使用快照複製或帶有即時更新或排隊更新的事務複製。

     在訂閱服務器上讀取和更新已複製數據。

     訂閱服務器和發佈服務器只偶爾連接。

     處理和解決由對相同數據的多個更新引起的衝突。

     需要逐行傳播更新，並且在行級上對衝突進行評估和解決。

   

     訂閱服務器上的複製數據主要爲只讀。

     訂閱服務器、分發服務器和發佈服務器在多數情況都是連接的，但是這對於排隊更新訂閱不是必要的。

     很少發生由對相同數據的多個更新引起的衝突。

     需要在事務的基礎上傳播更新，並且在事務的基礎對衝突進行評估和解決（無論整個事務提交還是取消）。

設計複製拓撲

複製拓撲定義服務器和數據複本間的關係，以及用於決定複本間同步發生方式的邏輯。設計複製拓撲將有助於確定以下內容：更改從發佈服務器到訂閱服務器所需的時間，單個更新的失敗是否阻止更新其它訂閱服務器，以及更新信息到達訂閱服務器的順序（該順序可影響分析和報表）。

確定複製拓撲：

     選擇物理複製模型（中央發佈服務器、帶有遠程分發服務器的中央發佈服務器、發佈訂閱服務器或中央訂閱服務器）。

     決定快照文件的位置及發佈服務器和訂閱服務器的初始同步方式。

     決定分發服務器位於本地還是遠程，並決定分發數據庫是否共享。

     決定多個發佈服務器是共享一個分發服務器，而每個發佈服務器使用其各自的分發數據庫，還是共享一個分發數據庫。

     確定使用的複製類型和選項。

     確定是在發佈服務器上（使用強制訂閱），還是在訂閱服務器上（使用請求訂閱）對複製進行初始化。

複製拓撲並不僅限於服務器間的物理連接，因爲它還包含了數據複本間的數據路徑。訂閱服務器可從不同的發佈服務器接收多個數據複本，而所有那些數據複本可在單個服務器上存在，從而組成複雜的拓撲。

物理複製模型

物理複製模型是一個映射表，用於確定如何在企業內分發數據及如何在複製執行過程中配置服務器。基於在分佈式數據因素、評估複製環境和爲各種類型的複製制定計劃中列出的所有因素和注意事項，應當能夠確定複製模型的最佳解決方案。

以下是複製模型的例子：

     中央發佈服務器。

     帶有遠程分發服務器的中央發佈服務器。

     再次發佈者。

     中央訂閱服務器。

中央發佈服務器

這種最簡單的 Microsoft SQL Server 2000 複製拓撲模型將一個發佈服務器和一個分發服務器置於同一服務器上，而將一個訂閱服務器置於單獨的服務器上。

當將若干訂閱服務器添加至發佈服務器和分發服務器中時，該方案則變得稍微有些複雜。發佈服務器擁有正在發佈的數據，併成爲所有訂閱服務器的中央發佈服務器。例如，該方案可能用於將主數據、列表或報表從中央發佈服務器分發至任意數目的訂閱服務器。

發佈服務器和訂閱服務器的角色不是互斥的；服務器可以同時擔任二者。例如，假定服務器 A 發佈發佈 1，並且服務器 B 發佈發佈 2。在此情況下，服務器 A 既可作爲發佈 1 的發佈服務器，也可作爲發佈 2 的訂閱服務器。這是一個篩選數據和發佈分區的示例。

帶有遠程分發服務器的中央發佈服務器
隨着複製活動等級的增加，或者隨着服務器或網絡資源變得受到限制，可能出於性能原因將發佈服務器和分發服務器置於不同的服務器上。當將一個繁忙的聯機事務處理 (OLTP) 服務器配置爲發佈服務器時，這樣做可能比較適當。儘管使用單獨的分發服務器會增加網絡總流量，但是該方案將減少發佈服務器上的本地處理工作和磁盤使用量。

這種方案類似於中央發佈服務器方案，不同之處在於由單獨的計算機執行發佈和分發任務。當出於性能和存儲空間方面的考慮，需要使發佈服務器（例如，一臺使用頻繁的 OLTP 服務器）從分發任務中解脫出來時，此方案十分有用。發佈服務器必須通過可靠、高速的通訊鏈接連接到分發服務器。

再次發佈者

再次發佈者模型使用兩臺服務器發佈相同的數據。發佈服務器將數據發送至訂閱服務器，然後後者將數據重新發布至任意數目的訂閱服務器。當發佈服務器必須通過低速或昂貴的通訊鏈接向訂閱服務器發送數據時，此方案十分有用。如果在鏈接的遠端有許多訂閱服務器，那麼使用再次發佈者會將大容量的分發負擔轉移到鏈接的遠端。

在此圖中，發佈服務器和再次發佈者（發佈訂閱服務器）都作爲其自身的本地分發服務器。如果將其各自設置爲使用遠程分發服務器，則各分發服務器需要與其發佈服務器位於低速或昂貴的通訊鏈接的同一端。發佈服務器必須通過可靠、高速的通訊鏈接連接到遠程分發服務器。

任何服務器既可作爲發佈服務器，又可作爲訂閱服務器。例如，設想發佈一份位於紐約的表，它需要分發至歐洲四個不同城市：倫敦、奧斯陸、巴黎和里斯本。之所以選擇位於倫敦的服務器來訂閱源於紐約的發佈表，是因爲倫敦的站點滿足下列條件：

     返回紐約的網絡鏈接相當可靠。

     紐約到倫敦的通訊成本不太高。

     從倫敦到其它歐洲訂閱服務器站點有良好的網絡通訊線路。

中央訂閱服務器

在中央訂閱服務器模型中，很多發佈服務器將信息複製到訂閱服務器上的公用目的表中。目的表進行了水平分區，且包含作爲主鍵一部分的位置特有的列。各發布服務器複製包含位置特有的數據的行。

該複製配置對某些情況可能有用，例如，將來自本地倉庫上許多服務器的清單數據彙總到公司總部的中央訂閱服務器。該配置還可用於彙總來自公司內各自治商業部門的信息，或合併來自分散位置的訂單處理。

快照複製的工作機制

快照複製是通過快照代理程序和分發代理程序實現的。快照代理程序準備快照文件，其中包含了已發佈表和數據庫對象的架構和數據，然後將這些文件存儲在快照文件夾中，並在分發服務器上的分發數據庫中記錄同步作業。快照文件夾默認位於分發服務器上，但可以指定一個備用位置取代默認位置或者與之並存。

分發代理程序將保存在分發數據庫表中的快照移動到訂閱服務器上的目的表中。分發數據庫僅用於複製，不包含任何用戶表。

快照代理程序

快照代理程序每次運行時，都會檢查是否新增了任何新訂閱。如果沒有新訂閱，則不創建任何新的腳本或數據文件。如果創建發佈時啓用了立即創建第一個快照選項，則每次快照代理程序運行時都創建新的架構和數據文件。所有架構和數據文件都存儲在快照文件夾中，然後由分發代理程序或合併代理程序將它們傳送到訂閱服務器，也可以手工傳送。快照代理程序執行以下步驟：

   1. 建立從分發服務器到發佈服務器的連接，並在發佈所包含的所有表上設置共享鎖。共享鎖保證了數據快照的一致性。由於這些共享鎖阻止所有其他用戶更新這些表，所以快照代理程序必須安排在數據庫活動的非峯值期間執行。

   2. 建立從發佈服務器到分發服務器的連接，並將每個項目的表架構複製到一個 .sch 文件。如果要求包含索引和描述性引用完整性，則代理程序將選中索引寫入一個 .idx 文件。其它數據庫對象，如存儲過程、視圖、用戶定義函數等，也可以作爲複製的一部分進行發佈。

   3. 在發佈服務器上覆制已發佈表中的數據，並將這些數據寫入快照文件夾。如果所有訂閱服務器都是 Microsoft SQL Server 2000 實例，則將快照存儲爲本機大容量複製程序文件。如果一個或多個訂閱服務器爲異類數據源，則快照將按字符模式文件存儲。這些文件是代表一個時點的表的同步集合。一次發佈內的每一個項目都有一個同步集。

   4. 向分發數據庫的 MSrepl_commands 表和 MSrepl_transactions 表追加行。MSrepl_commands 表中的表項是表明同步集（.sch 文件和 .bcp 文件）位置的命令，以及對所有指定的預創建腳本的引用。MSrepl_transactions 表中的表項是引用訂閱服務器同步任務的命令。

   5. 釋放所有已發佈表的共享鎖，完成日誌歷史表的寫入。

生成快照文件後，可以使用快照探索器在快照文件夾中查看這些快照文件。在 SQL Server 企業管理器中，展開復制及發佈文件夾，右擊一項發佈，然後單擊瀏覽最新快照文件夾菜單選項。
分發代理程序

每次分發代理程序運行快照發布時，都會將架構和數據移動到訂閱服務器上。分發代理程序執行以下步驟：

   1. 建立從代理程序所在服務器到分發服務器的連接。如果是強制訂閱，分發代理程序通常在分發服務器上運行，如果是請求訂閱，分發代理程序通常在訂閱服務器上運行。

   2. 檢查分發服務器上的分發數據庫中的 MSrepl_commands 表和 MSrepl_transactions 表。代理程序從第一個表中讀取同步集的位置，並從這兩個表中讀取訂閱服務器同步命令。

   3. 將架構和命令應用到訂閱數據庫。如果訂閱服務器不是 Microsoft SQL Server 2000 實例，則代理程序將在必要時轉換數據類型。所有發佈項目均將同步，同步時保持基礎表間的事務和引用完整性（假定訂閱數據庫如果不是 SQL Server，具有完成該任務的事務功能）。

當處理大量的訂閱服務器時，在訂閱服務器上運行分發代理程序（不論通過使用請求訂閱，還是通過使用遠程代理程序激活），可以節省分發服務器的處理資源。如果使用遠程代理程序激活，可以選擇在訂閱服務器上運行分發代理程序進行強制訂閱，或者在分發服務器上運行分發代理程序進行請求訂閱。

可以在創建訂閱時應用快照，也可以按照創建發佈時設置的調度應用快照。

說明  如果代理程序在分發服務器上運行，調度的同步是根據分發服務器上的日期和時間執行的，而不是根據訂閱服務器上的日期和時間。否則，調度就根據訂閱服務器上的日期和時間進行。

因爲數據庫或個別的表的自動同步增加了系統開銷，所以加大自動同步的間隔時間的優點之一，是可以將初始快照安排在發佈服務器較空閒的時候進行處理。

快照代理程序通常由 SQL Server 代理程序運行，可以直接用 SQL Server 企業管理器進行管理。快照代理程序與分發代理程序也可以通過使用 Microsoft ActiveX 控件嵌入到應用程序中。快照代理程序在分發服務器中運行。對於強制訂閱，分發代理程序通常在分發服務器上運行，而對請求訂閱，則通常在訂閱服務器上運行。但是，可以使用遠程代理程序激活將分發代理程序處理卸載到另一個服務器上進行。
清除快照複製

創建分發數據庫時，SQL Server 2000 在分發服務器上加入下列任務：

     代理程序檢查

     事務清除

     歷史記錄清除

這些任務有助於在一個長期運行的環境中有效地進行復制。當快照在所有訂閱服務器上應用後，複製清除程序自動爲初始快照刪除其關聯的 .bcp 文件。

如果爲匿名訂閱啓用了發佈，或用立即創建第一個快照選項啓用了發佈，則在快照位置將至少保留快照文件的一個副本。如果具有快照發布匿名訂閱的訂閱服務器與發佈服務器同步，這將確保最新的快照是可用的。

事務複製工作機制

事務複製是由快照代理程序、日誌讀取器代理程序和分發代理程序實現的。快照代理程序準備快照文件，其中包含了已發佈表和數據庫對象的架構和數據，然後將這些文件存儲在快照文件夾中，並在分發服務器上的分發數據庫中記錄同步作業。

日誌讀取器代理程序監視已爲事務複製配置的每個數據庫的事務日誌，並將已設複製標記的事務從事務日誌複製到分發數據庫中。分發代理程序將保存在分發數據庫表中的事務和初始快照作業移動到訂閱服務器上。

初始快照

新的事務複製訂閱服務器上必須包含一些表，這些表與發佈服務器上的表具有相同的架構和數據，然後才能從發佈服務器上接收增量更改。將完整的當前發佈從發佈服務器複製到訂閱服務器稱爲應用初始快照。Microsoft SQL Server 2000 將爲您創建並應用快照，您也可以選擇手工應用快照。

在向訂閱服務器分發並應用快照時，實際上只有那些正在等待初始快照的訂閱服務器受到影響。而該發佈的其它訂閱服務器（即那些已經收到對已發佈數據所進行的插入、更新、刪除或其它修改內容的訂閱服務器）不受任何影響。
併發快照處理

一般來講，隨着快照的生成，SQL Server 在快照生成期間，將在所有作爲複製一部分進行發佈的表上放置共享鎖。這可以防止在發佈表上進行更新。只有使用事務複製纔可用的併發快照處理，在整個快照生成過程中，將不包含共享鎖，因而，在 SQL Server 2000 創建初始快照文件時，允許用戶不間斷地連續工作。

當使用事務複製新建發佈並指出所有訂閱服務器都是 SQL Server 7.0 或 SQL Server 2000 的實例時，可使用併發快照處理。

複製開始以後，快照代理程序將共享鎖放在發佈表中。直到在日誌文件中輸入了表明快照開始的記錄後，鎖纔開始阻止更改。在接收到事務後，共享鎖即被除去，從而可繼續修改數據庫中的數據。即使複製的數據量很大，包含鎖的持續時間也是很短暫的（幾秒鐘）。

這時，快照代理程序開始生成快照文件。快照完成後，說明快照處理已結束的第二條記錄被寫入日誌。在生成快照時影響表的任何事務都在開始和結束令牌之間捕獲，並由日誌讀取器代理程序轉發到分發數據庫。

在訂閱服務器上應用快照時，分發代理程序首先應用快照文件（架構文件和 .bcp 文件）。然後調節每個捕獲事務，以查看該捕獲是否已傳送到訂閱服務器。在協調過程中，訂閱服務器上的表是鎖定的。在創建快照時，從發佈服務器上捕獲的事務越多，在訂閱服務器上應用此快照所需要的時間就越長。從概念上講，這與重新啓動 SQL Server 時的恢復進程相似。

在併發快照處理期間，當對標記用於複製的數據進行析取時，不能對它執行 UPDATETEXT 語句。如果啓動 UPDATETEXT 語句，則會返回錯誤信息，指出由於正在進行併發快照處理而不允許此操作。快照完成之後，UPDATETEXT 語句可以再次執行。

前面已經提到，如果在某些系統中業務邏輯通過訂閱數據庫上的觸發器或約束進行指示，則當併發快照處理髮生在這些系統上時應注意。併發快照處理對錶使用大容量插入，然後執行一系列特殊的 INSERT 和 DELETE 語句，使表處於一致的狀態。這些操作作爲一個事務執行，因此數據庫用戶看不見處於不一致狀態的數據。但訂閱服務器上的約束將在此事務內執行，而且可能評估不基於一致數據集的更改。若要避免這種情況，通常建議在訂閱服務器數據庫的所有約束和具有 IDENTITY 屬性的列上指定 NOT FOR REPLICATION 選項。因爲在訂閱服務器表處於一致狀態之前，不會在併發快照處理期間使用自定義存儲過程，所以使用自定義存儲過程不影響業務邏輯的執行。

訂閱服務器上的外鍵約束、檢查約束和觸發器不需要 NOT FOR REPLICATION 選項，因爲它們將在併發快照生成期間禁用並在快照生成後啓用。

重要  日誌讀取器代理程序必須在用併發處理生成快照後運行。如果日誌讀取器代理程序不運行，分發代理程序將繼續運行並返回錯誤，表明快照不可用，並且不將其應用到訂閱服務器。在分發代理程序可以將快照應用到訂閱服務器之前，日誌讀取器代理程序需要將快照生成期間發生的所有更改傳播到分發數據庫。日誌讀取器代理程序通常以連續模式運行，因此，它在生成快照後將很快自動運行，無須考慮此問題。如果選擇不以連續模式運行日誌讀取器代理程序，則必須手工運行它。

儘管併發快照處理允許更新在發佈表上繼續，但由於快照本身的開銷，性能將有所下降。只要可能，建議在最低常規活動期間生成快照（比如選擇進行數據庫備份的時段）。

重要  如果發佈表含有不包含在聚集索引中的主鍵或唯一約束，且在併發快照處理過程中對聚集鍵上的數據進行修改，則複製會失敗。建議僅當唯一和主鍵約束包含在聚集索引內或確保在生成快照時不修改聚集索引的列的數據時，才啓用併發快照處理。

併發快照處理只適用於事務複製和在 Microsoft Windows 98、Microsoft Windows NT 4.0 和 Microsoft Windows 2000 操作系統上運行 SQL Server 7.0 或更高版本實例的訂閱服務器。

如果要發佈到運行 SQL Server 7.0 的訂閱服務器，則分發服務器必須運行 SQL Server 2000 且必須使用強制訂閱才能使用併發快照處理。分發代理程序在分發服務器上運行，並且能夠執行併發快照處理。如果使用的是請求訂閱，則分發代理程序將運行在 SQL Server 7.0 上的訂閱服務器上，而在該服務器上併發快照處理不可用。

如果要發佈到運行 SQL Server 7.0 的訂閱服務器，則分發服務器必須運行 SQL Server 2000 且必須使用強制訂閱才能使用併發快照處理。分發代理程序在分發服務器上運行，並且能夠執行併發快照處理。如果使用的是請求訂閱，則分發代理程序將運行在 SQL Server 7.0 上的訂閱服務器上，而在該服務器上併發快照處理不可用。如果在運行 SQL Server 7.0 的訂閱服務器上使用請求訂閱，則必須禁用併發快照處理。

因爲這些限制，所以當創建事務發佈時創建發佈嚮導不會默認進行併發快照處理；但是如果應用程序滿足這些條件，則建議啓用該選項。若要啓用併發快照處理，請更改快照生成模式。打開發布屬性，單擊快照選項卡，然後選擇在生成快照的過程中併發訪問複選框。
快照代理程序

快照代理程序在事務複製過程中實現初始快照所執行的程序與快照複製中所用的程序相同（前面有關併發快照處理的概要除外）。生成快照文件後，可以使用快照探索器在快照文件夾中查看這些快照文件。在 SQL Server 企業管理器中，展開復制及發佈文件夾，右擊一項發佈，然後單擊瀏覽最新快照文件夾菜單選項。

數據修改及日誌讀取器代理程序

日誌讀取器代理程序可以連續運行，也可以按照創建發佈時建立的調度運行。執行日誌讀取器代理程序時，該代理程序首先讀取發佈的事務日誌（該日誌與進行一般 SQL Server 操作期間爲事務跟蹤與恢復所用的數據庫日誌相同），並識別所有的 INSERT、UPDATE 以及 DELETE 語句，或者其它對已作複製標記的數據事務的修改。然後，該代理程序將這些事務批量複製到分發服務器上的分發數據庫中。日誌讀取器代理程序使用內部存儲過程 sp_replcmds 從日誌中獲得下一個已作複製標記的命令集。於是分發數據庫成爲將更改發送到訂閱服務器所用的存儲與轉發隊列。只有已提交的事務才能發送到分發數據庫中。

發佈服務器上的事務與分發數據庫中的複製事務具有一一對應的關係。存儲在表 MSrepl_transactions 中的一個事務可以包含許多命令，每個命令可以沿着表 MSrepl_commands 中的 500 Unicode 字符邊界拆分。當整批事務都成功寫入分發數據庫之後，這一批事務便被提交。在每一批命令都提交到分發服務器後，日誌讀取器代理程序調用 sp_repldone 過程標記複製最終完成的位置。最後，代理程序標記事務日誌中準備好截斷的行。仍在等待複製的行不會被截斷。發佈服務器上的事務日誌可以被轉儲而不會影響複製，因爲只清除未作複製標記的事務。

只要不修改唯一約束的列，訂閱服務器上所做的數據修改將始終作爲一系列單行語句傳播。如果 UPDATE 確實修改了唯一約束的列，則 UPDATE 將作爲一系列後跟一系列 INSERT 語句的 DELETE 語句傳播。唯一約束的列是任何參與唯一索引或聚集索引的列，即使沒有將聚集索引聲明爲唯一索引。對索引視圖或索引視圖所基於的基表所執行的 UPDATES 將作爲 DELETEINSERT 對傳播。

日誌讀取器代理程序在分發服務器上的 SQL Server 代理程序中運行，並可通過在企業管理器中的複製監視器和代理文件夾中對其訪問，進行直接管理。
分發代理程序

事務命令存儲在分發數據庫中，直到分發代理程序將其傳播到所有訂閱服務器中，或者訂閱服務器上的分發代理請求訂閱更改。分發數據庫僅用於複製，不包含任何用戶表。絕對不可以在分發數據庫中創建其它對象。訂閱服務器按事務在發佈服務器上應用的相同次序接收事務。

分發代理程序是 SQL Server 代理程序的一個組件，並且可以通過使用 SQL Server 企業管理器對其進行直接管理。快照代理程序與分發代理程序也可以通過使用 Microsoft ActiveX 控件嵌入到應用程序中。快照代理程序在分發服務器中運行。對於強制訂閱，分發代理程序通常在分發服務器上運行，而對請求訂閱，則通常在訂閱服務器上運行。但是，可以使用遠程代理程序激活將代理程序處理卸載到另一個服務器上進行。

當複製過程正在進行時，SQL Server 可以驗證訂閱服務器上正在更新的數據。由此可以保證發佈服務器與訂閱服務器上的數據相同。
跳過事務複製中的錯誤

用於事務複製的 -skiperrors 代理程序命令行參數使您得以指定可以在分發進程中跳過的錯誤。一般來講，當日志讀取器代理程序和分發代理以連續模式運行，並且其中之一遇到錯誤時，代理程序以及分發進程將停止。通過用 -skiperrors 參數指定不希望干擾複製的預期錯誤，分發代理程序將錯誤信息記入日誌，然後繼續運行。
清除事務複製

創建分發數據庫時，SQL Server 將下列任務加入到分發服務器上的 SQL Server 代理程序中，以清除不再需要的數據：

     代理程序檢查

     代理程序歷史記錄清除

     事務清除

     分發清除

     歷史記錄清除

     過期訂閱清除

在所有訂閱服務器都接收到事務後，分發清除代理程序刪除分發數據庫中已提交的事務。已提交事務在分發數據庫中保留一段定義好的時間，這段時間稱爲保持期。在調度備份時設置保留期，可確保在分發數據庫中具有自動恢復目的數據庫所需的可用信息。

例如，如果一個訂閱服務器設置爲每 24 小時對目的數據庫做一次事務日誌轉儲，則可將保留期設置爲 48 小時。即使訂閱服務器正好在調度備份發生前遇到失敗，分發服務器的分發進程仍可使用自動還原複製表所需的所有事務。

合併複製的工作機制

合併複製是由快照代理程序和合並代理程序實現的。快照代理程序準備快照文件，其中包含已發佈表的架構和數據，然後將這些文件存儲在快照文件夾中，並在發佈數據庫中插入同步作業。快照代理程序還創建複製特定的存儲過程、觸發器和系統表。

合併複製代理程序將保存在發佈數據庫表中的初始快照作業應用到訂閱服務器上。該代理程序也合併那些創建初始快照之後在發佈服務器或訂閱服務器上發生的增量數據更改，並根據配置的規則或者使用創建的自定義衝突解決程序協調衝突。

在合併複製中分發服務器的角色非常有限，所以在本地（即在與發佈服務器所在的同一臺服務器上）實現分發服務器是很常見的。在合併複製過程中根本不使用分發代理程序，分發服務器上的分發數據庫存儲有關合並複製的歷史信息和雜項信息。

UNIQUEIDENTIFIER 列

Microsoft SQL Server 2000 爲所複製的表的每一行標識一個唯一列。這使行在表的多個複本中被唯一識別。如果表中已含具有 ROWGUIDCOL 屬性的列，且該列具有唯一索引或主鍵約束，則 SQL Server 自動使用該列作爲正在發佈的表的行標識符。

否則，SQL Server 爲正在發佈的表添加一個標題爲 rowguid 的 uniqueidentifier 列，該列具有 ROWGUIDCOL 屬性及一個索引。添加 rowguid 列會增加發布表的大小。rowguid 列和索引將在快照代理程序第一次執行發佈時添加到發佈表。
觸發器

然後 SQL Server 安裝觸發器，該觸發器跟蹤每行或每列的數據更改。觸發器捕獲對正在發佈的表的更改，並將這些更改記錄在合併系統表中。發佈表上的跟蹤觸發器在發佈的快照代理程序第一次運行時得以創建。當快照在訂閱服務器上應用時，在訂閱服務器上創建觸發器。

爲項目創建的不同觸發器在行級或列級跟蹤更改。因爲 SQL Server 在正在發佈的表中支持同類型的多個觸發器，所以合併複製觸發器不會與應用程序定義的觸發器相互衝突。
存儲過程

快照代理程序還創建更新訂閱數據庫的自定義存儲過程。一個自定義存儲過程用於 INSERT 語句，一個用於 UPDATE 語句，還有一個用於 DELETE 語句。當數據進行了更新，需要在訂閱數據庫中輸入新的記錄時，將使用自定義存儲過程，而不使用單個的 INSERT、UPDATE 和 DELETE 語句。
系統表

SQL Server 在數據庫中增加數個系統表，以支持數據跟蹤、高效同步以及衝突的檢測、解決和報告。對於每個已更改或已創建的行，表 MSmerge_contents 包含發生最新修改的生成。還包含總體行版本和行的每個特性。MSmerge_tombstone 在發佈內存儲對數據的 DELETE。這些表使用 rowguid 列來連接發佈表。

這些表中的生成列相當於一個邏輯時鐘，指示某一行在一個給定站點的上次更新時間。實際的 datetime 值不用於標記更改發生的時間或者確定衝突，而且站點之間的同步時鐘互不相干。這使得衝突檢測和衝突解決算法對時區差別和多個服務器上物理時鐘間的差別更有彈性。在一個給定的站點，生成編號與合併代理程序或用戶在該站點執行更改的次序相關。

MSmerge_genhistory 和 MSmerge_replinfo 使 SQL Server 得以確定需要用每個合併發送的生成。

有幾個跟蹤列添加到合併發佈表中。如果發佈表中的某些列名是爲合併處理保留的，則因爲有重複的列名而無法生成初始快照。保留的列名如下：

     reason_code

     source_object

     reason_text

     Pubid

     conflict_type

     origin_datasource

     tablenick

     create_time

初始快照和快照代理程序

新的訂閱服務器上必須包含一些表，這些表與發佈服務器上的表具有相同的架構和數據，然後才能從發佈服務器上接收增量更改。將完整的當前發佈從發佈服務器複製到訂閱服務器稱爲應用初始快照。SQL Server 將爲您創建並應用快照，您也可以選擇手工應用快照。

即使創建的訂閱不能自動對其應用快照（有時稱爲 nosync 訂閱），仍可應用快照的某些部分。必要的跟蹤觸發器和表在訂閱服務器上創建，這意味着即使訂閱指定將不自動應用快照，仍需創建並應用快照。

只有在合併複製確保訂閱服務器上具有已生成的表架構和數據的最新快照之後，纔會發生已更改數據的複製。在向訂閱服務器分發並應用快照時，實際上只有那些需要初始快照的訂閱服務器才能獲得並應用快照。除非將訂閱標記爲重新初始化或將發佈標記爲重新初始化（這種情況下，與給定發佈相對應的所有訂閱在下一個合併進程中均將重新初始化），否則已經接受了 INSERT、UPDATE、DELETE 或對已發佈數據的修改的訂閱服務器不會受到影響。

一個訂閱表一次只能訂閱一個合併發佈。例如，假定在兩個發佈中都發布 Customers 表，然後從一臺訂閱服務器訂閱兩個發佈，並指出同一個訂閱數據庫將接收來自兩個發佈的數據。在初始化同步過程中，其中一個合併代理程序將失敗。

初始快照可以是快照複製、事務複製和合並複製中的附加訂閱數據庫。如果使用可連接的訂閱數據庫，將複製訂閱數據庫及其訂閱，並可在另一個訂閱服務器上應用它們。

快照代理程序在合併複製中執行初始快照的步驟與其在快照複製中執行的步驟相似。

生成快照文件後，可以使用快照探索器在快照文件夾中查看這些快照文件。在 SQL Server 企業管理器中，展開復制及發佈文件夾，右擊一項發佈，然後單擊瀏覽最新快照文件夾菜單選項。
動態快照

動態快照爲應用動態篩選過的合併複製快照帶來了性能上的好處。通過使用 SQL Server 2000 大容量複製編程文件將數據應用到特定的訂閱服務器，而不是使用 INSERT 語句，將改善對動態篩選合併發佈應用初始快照的性能。

合併代理程序

一旦在訂閱服務器上應用了快照，SQL Server 觸發器即開始跟蹤在發佈服務器和訂閱服務器上執行的 INSERT、UPDATE 和 DELETE 語句。

對參與合併複製的每個表都在 MSmerge_articles 表中分配一個生成時隙。當在發佈服務器或訂閱服務器上的合併發佈中更新了某行時，即使發佈服務器和訂閱服務器未連接，觸發器也爲該行更新 MSmerge_contents 系統表中的 generation 列，更新到給定基表適當的生成時隙。當發佈服務器和訂閱服務器重新連接，並且合併代理程序運行時，合併代理程序將所有未提交的行更改收集到一個或多個組中，並指派一個高於所有以前生成的生成值。這使合併代理程序對更改進行批處理，反映到獨立生成中不同的表中，並處理這些批以在速度低的網絡中取得效率。

每個站點的合併代理程序都跟蹤記錄它向每一個其它站點發送的最高生成列值，以及每一個其它站點向它發送的最高生成列值。這提供了起點，使得在檢查每張表時可以不檢查已與其它站點共享的數據。各個站點在給定行所存儲的生成列值可以是不同的，因爲站點存儲的這些數值反映了該站點處理更改的次序。

可以通過設置 sp_addmergepublication 或 sp_changemergepublication 的 @max_concurrent_merge 參數來限制同時運行的合併進程數。如果最大數量的合併進程已經在運行，則任何新合併進程都將在隊列中等待。可以在合併代理程序命令行上設置 –StartQueueTimeout，指定代理程序在其它合併進程結束前等待的時間。如果超出了 –StartQueueTimeout 時間，且新的合併進程仍然在等待，則新進程將停止並退出。
同步

當合並複製拓撲中的發佈服務器和訂閱服務器重新連接，並且更新在站點之間進行傳播（如果有必要的話，還要檢測和解決衝突）時，即發生同步處理。在同步處理過程中，合併代理程序將所有更改過的數據發送到訂閱服務器。數據從更改發生處流向需要更新或同步處理的站點。

交換方向控制合併代理程序是從訂閱服務器上載更改 (-ExchangeType='Upload')、將更改下載到發佈服務器 (-ExchangeType='Download')，還是先執行上載、接着執行下載 (-ExchangeType='Bidirectional')。如果必須控制所應用的更改數量，則可以配置合併代理程序命令行參數 –MaxUploadChanges 和 –MaxDownloadChanges。在這種情況下，僅當傳播了所有更改後，才彙集發佈服務器和訂閱服務器上的數據。

在目的數據庫中，從其它站點傳播來的更新按照衝突檢測和解決規則與現有的值進行合併。合併代理程序評估送達的數據值與當前數據值，通過默認衝突解決程序自動解決新舊數據值之間的所有衝突。該默認衝突解決程序是在創建發佈時指定的，也可以是自定義的。SQL Server 2000 中的合併複製提供許多用戶可自定義的衝突解決程序，幫助您實現自己的業務邏輯。

只有在同步處理髮生時，更改過的數據值才被複制到其它站點並與那些站點上的更改匯聚在一起。同步發生的時間可以是幾分鐘、幾天、甚至幾星期，這可在合併代理程序調度中進行定義。同步時數據將彙集並且所有站點最終將具有相同的數據值，但是，要想實現這一點，必須停止所有更新，並在站點之間合併若干次。

爲每個發佈指定的訂閱保持期控制發佈服務器和訂閱服務器應多長時間同步一次。如果在保持期內訂閱未與發佈服務器保持同步，則訂閱將標記爲失效，需要重新初始化。這是爲了防止舊的訂閱服務器數據將這些更改同步並上載到發佈服務器。發佈的默認保持期是 14 天。由於合併代理程序根據此值清除發佈和訂閱數據庫，配置此值時一定要小心地使其與應用程序相適應。

說明  合併進程要求在訂閱服務器上 sysservers 表內有發佈服務器的條目。如果該條目不存在，則 SQL Server 將嘗試添加該條目。如果合併代理程序所使用的登錄沒有添加該條目（例如訂閱數據庫的 db_owner）的訪問權限，則將返回一個錯誤。
重新初始化訂閱

合併複製訂閱服務器以所接收的初始快照爲基礎進行數據更新，除非將訂閱標記爲重新初始化。如將訂閱標記爲重新初始化，則當合並代理程序再次運行時，該程序將會在訂閱服務器上應用新的快照。作爲一種可選操作，在重新應用快照之前，可以將在訂閱服務器上進行的更改上載到發佈服務器上。這樣可確保訂閱重新初始化之前，在訂閱服務器上進行的任何更改都不會丟失。

如果在創建訂閱時指定不在訂閱服務器上應用初始快照（在系統存儲過程 sp_addmergesubscriptionthe 中將參數 @sync_type 設置爲 nosync），則在對訂閱重新初始化時，將會在訂閱服務器上重新應用快照。此功能可確保訂閱服務器具有與發佈服務器相同的架構和數據。

如果重新初始化對合併發布的所有訂閱，則沒有指定初始快照同步的訂閱的重新初始化方式，與重新初始化具有 'automatic' 同步類型的訂閱相同。若要防止將快照的複製重新應用於訂閱服務器，請除去指定不進行初始快照同步處理的那個訂閱，然後在重新初始化之後重新創建它。

合併代理程序是 SQL Server 代理程序的一個組件，可以直接用 SQL Server 企業管理器進行管理。也可以用 Microsoft ActiveX 控件將快照代理程序和合並代理程序嵌入到應用程序中。快照代理程序在分發服務器中運行。合併代理程序通常在分發服務器上執行強制訂閱，在訂閱服務器上執行請求訂閱。遠程代理程序激活可用於將代理程序處理負荷卸載到另一臺服務器。

SQL Server 能夠在複製進程中驗證訂閱服務器上的數據，以便可以確保在發佈服務器上應用的數據更新同樣也在訂閱服務器上應用。
驗證訂閱服務器的權限

SQL Server 2000 提供了驗證訂閱服務器權限的選項，以將數據更改上載到發佈服務器。這將驗證合併代理程序登錄是否具有權限，以在發佈數據庫上執行 INSERT、UPDATE 和 DELETE 命令。驗證權限要求合併代理程序必須是在發佈數據庫中具有適當權限的有效用戶。

除了驗證在訂閱服務器上所用的登錄是否在發佈訪問列表 (PAL) 中之外，還要進行這種權限驗證。

可以使用 sp_addmergearticle 存儲過程中的 @check_permissions 屬性設置驗證訂閱服務器的權限，也可使用 SQL-DMO 中的 CheckPermissions 屬性進行設置。可以指定 sp_addmergearticle 存儲過程中 @check_permissions 參數的一個或多個下列值。
值     描述
0（默認值）     將不檢查權限。
1     在可以上載訂閱服務器上進行的 INSERT 操作之前檢查發佈服務器上的權限。
2     在可以上載訂閱服務器上進行的 UPDATE 操作之前檢查發佈服務器上的權限。
4     在可以上載訂閱服務器上進行的 DELETE 操作之前檢查發佈服務器上的權限。

說明  如果在已經生成初始快照後設置 @check_permissions 參數，則必須在訂閱服務器上生成並重新應用新的快照，才能在合併數據更改時驗證權限。
清除合併複製

分發數據庫創建完成之後，SQL Server 自動將下列任務加到 SQL Server 代理程序上，以清除不再需要的數據：

     在發佈服務器上清除訂閱

     在分發服務器上清除歷史記錄

這些任務有助於在一個長期運行的環境中有效地進行復制；因此，管理員應制定該週期性維護計劃。清除任務刪除每個發佈的初始快照，並刪除 Msmerge_history 表中的歷史信息。
合併元數據清除

系統存儲過程 sp_mergecleanupmetadata 使管理員得以清除系統表 MSmerge_contents 和 MSmerge_tombstone 中的元數據。儘管這些表可以無限擴展，但在某些情形下清理其中的元數據可提高合併性能。該過程通過壓縮發佈服務器和訂閱服務器中上述表的大小以節省空間。

在執行該存儲過程之前，將來自訂閱服務器的所有數據與發佈服務器合併，以載入所有必須保存的訂閱服務器數據更改。執行該存儲過程之後，所有合併發佈的相關各級快照文件都必須重新生成。如果沒有先運行快照就試圖進行合併，系統將提示運行快照。

注意  當存儲過程 sp_mergecleanupmetadata 執行之後，在發佈涉及的訂閱服務器上，所有在上述兩張表中存儲有元數據的訂閱都被標記爲重新初始化，發佈服務器上的更改都將丟失，而當前快照則標記爲廢棄。

重新初始化自動傳播合併拓撲。管理員不必手工重新初始化每個再次發佈者上的所有訂閱。使用帶有 Service Pack 2 的 SQL Server 7.0 時，重新初始化不會自動通過合併拓撲傳播。

過程 sp_mergecleanupmetadata 的 @reinitialize_subscriber 參數默認設置爲 TRUE，而所有的訂閱都標記爲重新初始化。如果將參數 @reinitialize_subscriber 設置爲 FALSE，則訂閱不會標記爲重新初始化。將參數設置爲 FALSE 必須慎重，因爲如果選擇不對訂閱進行重新初始化，就必須確保發佈服務器與訂閱服務器上的數據是同步的。

如果使用設置爲 TRUE 的 @reinitialize_subscriber 參數執行 sp_mergecleanupmetadata，則將在訂閱服務器上重新應用快照，即使未應用初始快照而創建了訂閱（例如，當手工應用快照數據和架構或者它們已存在於訂閱服務器上時）。如果不想重新初始化訂閱和重新應用快照，則在確保數據在發佈服務器和訂閱服務器之間同步後，必須除去該訂閱並重新創建爲無初始同步的訂閱。

在沒有將訂閱標記爲重新初始化時，如要運行存儲過程 sp_mergecleanupmetadata，必須執行以下步驟：

   1. 同步所有訂閱服務器。

   2. 停止所有對發佈及訂閱數據庫的更新。

   3. 建議在每個訂閱服務器上帶命令行選項 –Validate 運行合併代理程序，藉此執行合併，用發佈服務器驗證訂閱服務器上的數據。

   4. 執行系統存儲過程 sp_mergecleanupmetadata。執行該存儲過程之後，可允許用戶再次更新發布與訂閱數據庫。

在所有的合併（包括連續模式的合併）結束後執行 sp_mergecleanupmetadata。控制此行爲的一種方法是停用發佈並在完成合並清除後再將其激活。

例如，在發佈服務器上執行類似於下面的代碼：

EXEC central..sp_changemergepublication 'publicationname', 'status', 'inactive'

這確保瞭如果已停用發佈，則正在輪詢發佈狀態的所有連續模式的合併都將失敗。在所有連續模式的合併終止後執行下列語句：

EXEC central..sp_mergecleanupmetadata 'publicationname',
   @reinitialize_subscriber='false'
EXEC central..sp_changemergepublication 'publicationname', 'status', 'active'

如果合併清除傳播到還在活動的再次發佈者，將返回一個錯誤信息，指出不能執行合併元數據的清除。

要使用此存儲過程，發佈服務器和所有訂閱服務器都必須運行帶 Service Pack 2 或更高版本的 Microsoft SQL Server 7.0。只有具有 sysadmin 和 db_owner 角色的成員可以使用此存儲過程。要清除合併元數據，須執行系統存儲過程 sp_mergecleanupmetadata。如果指定一個 @tablename 參數，則只清除該表的合併元數據。如果未指定表名，則表 MSmerge_contents 和 MSmerge_tombstone 中的所有合併元數據都將被清除。

如果在數據庫上有多個發佈，並且其中任何都一個使用無限發佈保持期 (@retention=0)，則運行 sp_mergecleanupmetadata 將不會清除數據庫的合併複製更改跟蹤元數據。爲此，請謹慎使用無限發佈保持。