瞭解合併式複寫發行項處理順序

本文介紹如何瞭解合併式複寫發行項處理順序。

原始產品版本: SQL S
原始 KB 編號: 307356

摘要

合併代理程式遵循一組特定規則,這些規則會控管在同步處理常式期間,合併程式將變更套用至發行項的順序。

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

其他資訊

發行項處理順序很重要的原因有兩個:

  • 在許多情況下,合併代理程式必須以特定連續處理參與宣告式參考完整性 (DRI) 條件約束之發行項的變更,才能獲得最佳效能。 如果沒有,合併代理程式可能必須重試資料操作語言 (DML) 作業,其嘗試的順序不正確 (也就是,請嘗試在其父系) 前面插入子資料列。

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

注意事項

當合併代理程式將 SQL DML 變更作業套用至夥伴複本時,可以略過 FOREIGN KEY 條件約束評估和使用者觸發程式執行。 若要發生這種情況,必須使用 NOT FOR REPLICATION 選項來建立 FOREIGN KEY 條件約束和使用者觸發程式,或兩者皆已建立。 在這兩種情況下,合併程式都假設SQL Server對物件執行原始使用者起始的變更時,已成功評估商務邏輯,而且當將資料複寫至夥伴複本時,不需要重新評估這些條件。 以這種方式使用 NOT FOR REPLICATION 的主要優點是提升效能。 如需 NOT FOR REPLICATION 選項及其適當使用方式的詳細資訊,請參閱《SQL Server 2000 線上叢書》中的NOT FOR REPLICATION選項主題。

基於稍早列出的兩個原因,合併代理程式將變更傳遞至夥伴複本的順序很重要。

開始討論文章處理順序之前,請務必先瞭解兩個重要概念。 這兩個重要概念如下所示:

  • 文章昵稱。

  • 世代。

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

  • 文章昵稱

    昵稱是整數值,合併代理程式用來識別要合併複寫之SQL Server資料表 (發行項) 。 合併安裝程式會在將發行項新增至合併式發行集時,指派發行項昵稱。 如果發行項參與 DRI 條件約束,合併安裝程式會嘗試產生發行項昵稱,以反映定義的 DRI 條件約束。 合併程式會將 FOREIGN KEY 條件約束所參考的資料表指派 (父系) 比參考資料表 (子資料工作表的名稱小,或是) 定義 FOREIGN KEY 條件約束的資料表。

    如果資料表不參與 DRI 條件約束,合併安裝程式會根據將發行項以遞增順序新增至發行集 () 順序來指派發行項昵稱。

  • 生成

世代是整數值,合併代理程式用來追蹤特定發行項的邏輯變更群組。 在合併同步處理之間的特定複本上對特定發行項所做的所有變更,都會與同一代相關聯。 每次執行合併代理程式時,都會關閉現有的開放式世代,然後開啟新一代,以建立下一組變更的關聯。

處理 INSERT、UPDATE 和 DELETE

合併代理程式會將特定發行集的發行項分割成兩個不同的群組:

  • 此合併代理程式會將不涉及任何聯結篩選關聯性,且未透過 DRI 相關的文章放入一個群組中聯結篩選的任何相關文章。

  • 此合併代理程式會將明確涉及聯結篩選關聯性的文章,以及透過 DRI 將篩選發行項聯結至第二個不同群組的相關文章。

此合併代理程式會將定義到發行集的每一個發行項新增至前述其中一個群組。

合併代理程式會使用群組來判斷所有定義至發行集之發行項的 UPDATEsINSERTsDELETEs 整體處理順序。

在兩個個別群組中,合併代理程式處理 INSERTsUPDATEs 遞增發行項昵稱順序,並以遞減發行項昵稱連續處理程式 DELETEs 。 首先,合併代理程式會在特定群組中完整處理, DELETEs 後面接著 UPDATEsINSERTs (也處理在特定群組) 中。 在概念上,合併代理程式會將上述兩個群組附加至另一個群組, (未依照先前所列的順序合併) 。 合併代理程式從處理 DELETEs 第一個群組開始,然後將處理延伸 DELETE 至第二個群組,並平行處理這兩個群組的其餘變更。 雖然合併代理程式會在每個個別群組中維護髮行項處理順序,但合併代理程式不會在兩個個別群組之間維持嚴格的發行項處理順序。 因此,如果是 INSERTUPDATE ,則從發行項昵稱較高的第一個群組所做的變更,可能會先到達第二個群組中具有較低昵稱的群組。 另一種 DELETE 情況也可能發生。 這兩種行為都是設計方式。

產生批次處理對發行項處理順序的可能影響

如先前所述,透過世代,您可以以邏輯方式將變更分組 (INSERTsUPDATEs 以及 DELETEs 在同步處理會話之間的特定複本上,針對特定發行項所發生的) 。 最後,當合併代理程式決定兩個複本之間必須交換哪些變更時,合併代理程式會與世代搭配運作。 合併代理程式會在同步處理常式的下列幾點交涉一般世代:

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

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

在合併同步處理的上傳和下載階段中,合併代理程式會使用這個一般世代作為起始點,以列舉要傳送至夥伴複本的世代。

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

在交換多個世代批次的情況下,合併代理程式可能會將相關的父代和子系變更分割成兩個個別的產生批次。 如果是這種情況,合併代理程式可能會在包含相關聯父項變更的產生批次之前,于世代批次中傳遞子變更。 在使用重新發行者的階層式合併拓撲中,有一個罕見的情況是,跨產生批次分割父項和子系變更可能會導致非聚合。 如需非聚合的詳細資訊,請參閱下列文章:

當SQL Server以個別的世代批次處理子系和父代時,不會聚合

您可以增加 -UploadGenerationsPerBatch 先前討論過的 -DownloadGenerationsPerBatch 和 參數,以避免在產生批次之間分割父項和子系變更。

發行項處理順序會根據先前討論的規則,在特定的產生批次中維護。 不過,合併代理程式無法在產生批次之間維持發行項處理順序。