瞭解合併複寫文章處理順序

本文說明如何瞭解合併複寫專案處理順序。

原始產品版本:   Sqlserver
原始 KB 編號:   307356

摘要

合併代理程式會遵循一組特定的規則,以控制在同步處理常式期間,合併處理常式對文章套用變更的順序。

本文討論為何的文章處理順序很重要。

詳細資訊

有兩個主要原因:專案處理順序很重要:

  • 在許多情況下,合併代理程式必須處理對參與宣告參照完整性的文章所做的變更 (DRI) 限制以取得最佳效能。 如果不是,合併代理程式可能必須重試資料處理語言 (DML) 操作所嘗試的順序不正確 (也就是說,請嘗試在其上層) 前面插入子列。

  • 使用觸發器來維護參照完整性的應用程式,需要合併代理程式以特定順序傳送變更。 如果合併代理程式以不正確的順序傳送變更,觸發器很可能會復原變更,而且變更也不會傳播整個複寫拓撲。

注意

當合併代理程式將 SQL DML 變更作業套用至夥伴複本時,可以略過外鍵約束評估和使用者觸發器執行。 若要發生此情況,必須已使用 NOT FOR REPLICATION 選項來建立外鍵約束和使用者觸發器(或兩者皆有)。 在這兩種情況下,合併程式會假設 SQL Server 在執行原始使用者所啟動的變更與物件的變更時,已成功評估商務規則,而且在將資料複製到夥伴複本時,不需要重新評估這些條件。 以這種方式使用 NOT 做複寫的主要好處是可提升效能。 如需詳細資訊,請參閱 NOT to REPLICATION 選項,以及如何適當地使用它,請參閱 SQL Server 2000 叢書中的 NOT FOR REPLICATION 選項主題。

針對之前所列的兩個原因,合併代理程式將變更傳送至夥伴複本的順序很重要。

開始討論「專案處理」順序之前,請務必瞭解兩個重要概念。 這兩個重要概念如下:

  • 專案昵稱。

  • 代。

以下是這兩個概念的描述。

  • 文章昵稱

    昵稱是一種整數值,合併代理程式用來識別 (SQL Server 資料表) 合併複寫的專案。 合併設定程式會在將文章加入至合併出版物時,指派一個昵稱。 如果某篇文章參與 DRI 限制,則合併安裝程式會嘗試產生反映定義的 DRI 限制的專案別名。 Merge 程式會指派外鍵約束所參照的表格。 (父系) 一個較小的文章別名,而非參考資料表 (子資料工作表,或是定義外鍵約束的資料表) 。

    如果資料表不參與 DRI 限制,則合併設定程式會根據其將文章加入出版物的順序,將文章別名指派給 (以遞增順序) 。

  • 生成

代是一種整數值,合併代理程式會使用該整數值追蹤特定專案變更的邏輯群組。 在合併同步處理間,對特定副本所做的特定專案所做的所有變更都會與同一個產生產生關聯。 每次合併代理程式執行時,它都會關閉現有的開啟產生,然後開啟新的代,以與下一組變更關聯。

處理插入、更新和刪除

合併代理程式會將特定出版物的文章分割成兩個不同的群組:

  • 合併代理程式會將不會包含在任何聯結篩選關係中的文章,以及與 join 篩選器放入一個群組中的任何文章相關聯。

  • 合併代理程式會將明確包含在聯接篩選關係中的文章,以及與透過 DRI 聯接篩選文章相關的文章放入第二個不同的群組中。

合併代理程式會將每個定義至出版物的本文新增至上述其中一個群組。

合併代理程式會使用群組來決定 UPDATEs INSERTs 針對出版物所定義的所有文章,以及的整體處理順序 DELETEs

在兩個個別的群組中,合併代理程式會 INSERTsUPDATEs 遞增的文章別名順序,以及以 DELETEs 逆序的文章別名連續處理。 首先,合併代理程式會在特定群組中完整處理所有的, DELETEs 然後在 UPDATEs INSERTs 特定群組) 中 (也是一樣。 在概念上,合併代理程式會將上述兩個群組附加到另一個 (不會以先前所列的順序合併) 。 合併代理程式 DELETEs 會先處理第一個群組,然後將處理常式擴充 DELETE 至第二個群組,並以平行方式處理兩個群組的變更的其餘部分。 雖然合併代理程式會維護每個個別群組中的文章處理順序,但合併代理程式不會在兩個個別的群組間維護嚴格的文章處理順序。 在此情況下,如果 INSERT UPDATE 是 or,第一個具有較高的文章昵稱的群組的變更可能會從第二個具有較低昵稱的群組向前抵達。 對的情況也會發生相反情況 DELETE 。 這兩種行為都是由設計所組成。

產生批次處理在專案處理順序上的可能效果

如先前所述,使用世代,您可以在邏輯上將變更分組 (INSERTsUPDATEsDELETEs 在同步處理會話間的特定專案中所發生的) 。 最後,當合併代理程式決定其必須在兩個複本間交換的變更時,它就會與代一起運作。 合併代理程式會在同步處理常式的下列點協商通用代:

  • 將變更從訂閱者上傳至發行者之前。

  • 將變更從發行者下載至訂閱者之前。

合併代理程式會在合併同步處理的上載和下載階段,將此通用代當做開始時,用來列舉要傳送至夥伴複本的起始點。

合併代理程式會成批次處理生成,也稱為產生批次。 根據預設,100代會包含在每個產生批次中,合併代理程式會從訂閱者上傳至發行者,或從發行者下載至訂閱者。 產生的批次大小可透過 -UploadGenerationsPerBatch-DownloadGenerationsPerBatch 合併代理程式參數(或透過合併代理程式設定檔)進行設定。 在預設情況下,如果您需要在發行者 (或重新發佈器) 與訂閱者之間進行 exchange ((即下載和上傳)或兩者) 都超過100個以上的代,則合併代理程式會處理多個產生批次。 批次數目取決於合併代理程式必須對 exchange 執行的各代數目,以及特定合併會話中每批次批次設定的各代數目。

在交換多個產生批次的情況下,合併代理程式可能會在兩個不同的產生批次中分割相關的父項和子項變更。 如果是這種情況,合併代理程式可能會在包含相關聯的父項變更的產生批次中,傳送產生批次中的子項變更。 在使用重新發行者的階層式合併拓撲中,有一個極少的情況,在此情況下,跨產生批次分割父項和子項變更可能會導致非收斂。 如需非收斂的詳細資訊,請參閱下列文章:

當 SQL Server 在個別的產生批次處理子級和父系代時,非收斂

您可以增加 -UploadGenerationsPerBatch 上述所討論的和 -DownloadGenerationsPerBatch 參數,避免跨產生批次分割父項和子項變更。

專案處理順序會依照先前所討論的規則,在特定的批次中維護。 不過,合併代理程式無法跨產生批次維護文章處理順序。