本文介紹如何了解合併式復寫發行項處理順序。
原始產品版本：SQL Server
原始 KB 編號： 307356
摘要
合併代理程式 遵循一組特定的規則，以控管合併程式在同步處理過程中將變更套用至發行項的順序。
本文討論發行項處理順序為何重要。
其他相關資訊
發行項處理順序很重要的原因有兩個主要原因：
在許多情況下，合併代理程式 必須處理參與宣告式引用完整性 （DRI） 條件約束的文章變更，以達到最佳效能。 如果沒有，則 合併代理程式 可能必須重試數據操作語言 （DML） 作業，其嘗試順序不正確（也就是嘗試在其父系前面插入子數據列）。
使用觸發程式維護引用完整性的應用程式需要 合併代理程式 以特定順序傳送變更。 如果 合併代理程式 以不正確的順序傳送變更，觸發程式很可能會回復變更，而且變更不會在整個復寫拓撲中傳播。
注意
合併代理程式 可以在將 SQL DML 變更作業套用至夥伴復本時略過 FOREIGN KEY 條件約束評估和使用者觸發執行。 若要發生這種情況，FOREIGN KEY 條件約束和使用者觸發程式，或兩者都必須使用 NOT FOR REPLICATION 選項來建立。 在這兩種情況下，合併程式假設 SQL Server 在對物件執行原始使用者起始的變更時，已成功評估商業規則，而且當 SQL Server 將數據復寫至夥伴複本時，就不需要重新評估這些條件。 以這種方式使用 NOT FOR REPLICATION 的主要優點是提升效能。 如需 NOT FOR REPLICATION 選項以及如何適當使用的詳細資訊，請參閱 《SQL Server 2000 在線叢書》中的 NOT FOR REPLICATION 選項主題。
基於先前所列的兩個原因，合併代理程式 傳遞變更給夥伴複本的順序很重要。
開始討論文章處理順序之前，請務必瞭解兩個主要概念。 這兩個主要概念如下：
文章昵稱。
世代。
以下是這兩個概念的描述。
文章昵稱
昵稱是整數值，合併代理程式 用來識別合併復寫的發行項（SQL Server 數據表）。 合併安裝程式會在將發行項新增至合併式發行集時，指派發行項昵稱。 如果發行項參與 DRI 條件約束，合併設定程式會嘗試產生反映已定義 DRI 條件約束的文章昵稱。 合併程式會指派 FOREIGN KEY 條件約束所參考的數據表（父系）比參考數據表小的發行項昵稱（子數據表，或定義 FOREIGN KEY 條件約束的數據表）。
如果數據表未參與 DRI 條件約束，合併設定程式會根據發行項加入發行項的順序來指派發行項昵稱（以遞增順序）。
第幾代
世代是整數值，合併代理程式 用來追蹤特定發行項變更的邏輯群組。 合併同步處理之間對特定發行項所做的所有變更都會與同一代相關聯。 每次執行 合併代理程式 時，它會關閉現有的開啟層代，然後開啟新一代，讓下一組變更產生關聯。
處理 INSERT、UPDATEEs 和 DELET
合併代理程式 會將特定發行集的發行項分割成兩個不同的群組：
合併代理程式 會將未參與任何聯結篩選關聯性的發行項放入一個群組中，而未透過 DRI 將加入篩選中涉及的任何發行項建立關聯。
合併代理程式 會將明確參與聯結篩選關聯性的發行項，以及透過 DRI 將篩選發行項相關的發行項加入第二個相異群組。
合併代理程式 會將每個定義的發行項新增至發行集，只新增至上述其中一個群組。
合併代理程式 會使用群組來判斷 、、 和 DELETEs 定義至發行集之所有發行項的整體處理順序。UPDATEsINSERTs
在這兩個個別群組中，合併代理程式 會以遞增的發行項昵稱順序處理INSERTs和UPDATEs遞增發行項昵稱順序，並以遞減的發行項昵稱順序處理DELETEs。 首先，合併代理程式 會在整個特定群組中處理所有DELETEs專案，後面接著 UPDATEs 和 INSERTs （也在特定群組中）。 就概念上講，合併代理程式 會依照先前所列的順序，將上述兩個群組附加至彼此（未合併）。 合併代理程式 會從第一個群組的處理DELETEs開始，然後將處理延伸DELETE至第二個群組，而兩個群組的其餘變更則會平行處理。 雖然 合併代理程式 在每個個別群組中維護發行項處理順序，但 合併代理程式 不會維護這兩個個別群組的嚴格發行項處理順序。 因此，在 或 UPDATE的情況下INSERT，如果變更第一個具有較高文章昵稱的第一個群組，可能會比第二個群組的昵稱較低。 相反的情況也可能發生在 DELETE。 這兩種行為都是設計方式。
產生批處理對發行項處理順序的可能影響
如先前所述，使用世代，您可以在同步處理會話之間的特定複本上，將特定發行項發生的變更（INSERTsUPDATEs和DELETEs） 分組在一起。 最後，當 合併代理程式 決定必須在兩個複本之間交換的變更時，合併代理程式 會與世代搭配運作。 合併代理程式 會在同步處理程式的下列幾點交涉一般產生：
將訂閱者變更上傳至發行者之前。
在將發行者變更下載到訂閱者之前。
合併代理程式 在上傳和下載合併同步處理階段期間列舉要傳送至夥伴復本的世代時，會使用此一般世代作為起點。
合併代理程式 會分批處理世代，也稱為產生批次。 根據預設，合併代理程式 從訂閱者上傳至發行者的每一代批次都會包含100個世代，或從發行者下載至訂閱者。 產生批次大小可透過 -UploadGenerationsPerBatch 和 -DownloadGenerationsPerBatch 合併代理程式 參數，或透過 合併代理程式 配置檔來設定。 在預設案例中，如果發行者（或重新發行者）與訂閱者之間有 100 個以上的世代需要交換（也就是下載和上傳，或兩者），則 合併代理程式 會處理多個世代批次。 批次數目取決於 合併代理程式 必須交換的世代數目，以及特定合併會話的各批次設定世代。
在交換多個世代批次的情況下，合併代理程式 可能會將相關的父代和子變更分割成兩個不同的世代批次。 如果是這種情況，合併代理程式 可能會在包含相關聯父變更的產生批次之前，在產生批次中傳遞子變更。 在使用重新發行者的階層式合併拓撲中，有一種罕見的情況，跨世代批次分割父系和子系變更可能會導致非聚合。 如需非聚合的詳細資訊，請參閱下列文章：
當 SQL Server 在不同的世代批次中處理子代和父代世代時，非聚合。
您可以增加 先前討論的 -UploadGenerationsPerBatch 和 -DownloadGenerationsPerBatch 參數，以避免跨世代批次分割父代和子變更。
根據先前所討論的規則，文章處理順序會在特定世代中維護。 不過，合併代理程式 無法跨產生批次維護發行項處理順序。