文章編號: 307356 - 上次校閱: 2003年10月3日 - 版次: 3.3

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

系統提示本文適用於您使用的作業系統之外的作業系統。與您不相關的文章內容已停用。

在此頁中

全部展開 | 全部摺疊

結論

「 合併代理程式 」 將遵循一組特定的控制的順序的合併程序套用變更至發行項同步處理程序期間的規則。

本文將告訴您,為什麼文件處理順序是很重要。

其他相關資訊

文章處理順序的重要性的兩個主要理由有:
  • 在許多情況下 「 合併代理程式 」 必須處理參與完成所能獲得最佳效能的特定順序的宣告性參考完整性 (DRI) 條件約束的文件的變更。如果不,「 合併代理程式 」 可能要再試一次資料操作語言 (DML) 作業它會嘗試以不正確的順序 (也就,請試著 INSERT 預先,其父系的子資料列)。
  • 使用觸發程序,以維持參考完整性的應用程式需要 「 合併代理程式 」 將變更傳送特定的順序。如果 「 合併代理程式 」 會將變更傳送不正確的順序,將這項工作的觸發程序會很可能是回復變更,並變更不會傳播整個複寫拓樸。
請注意 「 合併代理程式 」 可以略過 FOREIGN KEY 條件約束評估,而且使用者觸發程序執行時它適用於 SQL DML 變更為夥伴複本的作業。這會發生 FOREIGN KEY 條件約束和使用者觸發程序或兩者皆,必須已建立以 NOT FOR 複寫選項。在這兩種情況下合併程序會假設 SQL Server 已評估過商務邏輯順利執行原始使用者啟動變更對該物件時,而且它不需要重新評估這些條件,它會將資料複寫到夥伴複本時。在這種方式使用 NOT FOR 複寫的主要優點就是提升的效能。如需有關 NOT FOR 複寫] 選項,以及如何適當地使用的詳細資訊,請參閱 SQL Server 2000 線上叢書 》 中的 < NOT FOR 複寫選項 」 主題]。

稍早列出的原因有二,在其中 「 合併代理程式 」 將變更傳遞給夥伴複本的順序是很重要的。

開始討論文章處理順序前, 務必了解的兩個主要概念。兩個主要概念是:
  • 發行項的別名。

    -以及-

  • 層代。
以下為兩個概念的摘要說明。

發行項的暱稱

暱稱是 「 合併代理程式 」 會使用來識別合併複寫發行項 (SQL Server 資料表) 的整數值。合併安裝程序指派文章暱稱時它將發行項加入至合併式發行集。如果發行項參與 DRI 條件約束,合併安裝處理程序會嘗試產生反映已定義的 DRI 條件約束的發行項暱稱。合併處理序會指派較小的發行項別名與參考的資料表 (子系] 表格或 FOREIGN KEY 條件約束定義的資料表) 的 FOREIGN KEY 條件約束 (父系) 所參照的資料表。

如果資料表不參與 DRI 條件約束,合併安裝程序會指派文章暱稱根據它將發行項新增至出版物 (以遞增順序) 的順序。

產生

生成集為合併代理程式使用特定的發行項中追蹤變更的邏輯群組的整數值。所有對特定的發行項,在合併同步之間的特定複本所做的變更都是相同的層代相關聯。每次 「 合併代理程式 」 執行時,它會關閉現有的開啟產生,然後開啟新的生成集要變更的下一組與產生關聯。

處理插入更新,及刪除

「 合併代理程式 」 的分割區分成兩個不同群組的特定發行集 「 文件:
  • 「 合併代理程式 」 會放置都不涉及其他的聯結篩選關係而不與透過 DRI 參與組成一個群組的聯結篩選任何發行項的文件。
  • 「 合併代理程式 」 會將明確涉及的文件放在聯結篩選條件關聯性和聯結篩選發行項透過 DRI 到第二個不同的群組與相關的文件中。
「 合併代理程式 」 新增到以下其中一個以上的群組對發行集定義每個發行項。

「 合併代理程式 」 使用群組來決定整體的更新、 插入和刪除對發行集定義的所有發行項處理順序。

在每個兩個個別的群組中 「 合併代理程式 」 處理 INSERT,並更新以遞增的發行項的別名順序和處理程序刪除遞減發行項的別名。第一次,所有合併代理程式 」 處理程序會刪除完整地在後面跟著更新和插入 (也在特定的群組) 中的特定群組中。在概念上,「 合併代理程式 」 會將兩個先前提到的群組,以另一個 (不合併) 附加先前列出的順序。「 合併代理程式 」 來處理刪除第一個群組開始,並再延伸 DELETE 處理第二個群組,其餘的兩個群組的變更平行處理。雖然 「 合併代理程式 」 會維護每一個個別的群組中的文件處理順序,「 合併代理程式 」 不會維護嚴格的發行項的處理順序跨兩個個別的群組。像這樣的情況下一個 INSERT 或 UPDATE,很可能具有較高的發行項暱稱第一個群組的變更可以到達超前從第二個群組具有較低的暱稱。對於一個 DELETE,也可能發生 converse 這種情況。這兩這些行為都是經過設計的。


儘可能會影響產生的批次處理文章處理順序

如稍早所述,與生成集您可以以邏輯方式群組 (插入、 更新和刪除) 進行的變更在特定的複本之間同步處理工作階段特定的發行項。「 合併代理程式 」 搭配它會判斷哪些變更的層代的最終,它必須交換兩個複本之間。「 合併代理程式 」 會交涉常見產生在同步處理程序中下列的點:
  • 之前它將上載訂閱者對發行者的變更。
  • 之前它下載變更從發行者到訂閱者。
「 合併代理程式 」 使用這個常見的層代做為起始點列舉在層代時在上載期間傳送給夥伴複本,並下載階段合併同步處理。

「 合併代理程式 」 處理也稱為 「 層代批次的批次中的層代。預設狀況下,100 的層代包含在每一個生成集批次,「 合併代理程式 」 從 「 訂閱者將上載至發行者或從發行者到訂閱者下載。產生的批次大小是可透過設定
-UploadGenerationsPerBatch-DownloadGenerationsPerBatch 合併代理程式參數或透過 「 合併代理程式 」 設定檔。在預設情況下如果有多個 100 的層代您發行者 (或一 re-publisher) 間需要交換 (也就是下載和上載,或兩者),而且訂閱者合併代理程式處理多個層代批次。批次數量取決於 「 合併代理程式 」 已交換的層代和每個批次設定中-強制為特定的合併工作階段層代的數量。

在多個層代批次交換的何處的狀況 「 合併代理程式 」 可能會分割相關的父代和子變更跨越兩個不同的層代批次。如果是這種情況,「 合併代理程式 」 可能會產生批次超前生成集批次包含關聯的父代變更中傳送子變更。在使用 re-publishers 的階層式合併拓樸,沒有一個罕見的情況,在其中父和子變更分割跨層代批次可能會導致非交集。如需有關未交集的詳細資訊,請參閱下列的 「 Microsoft 知識庫 」 中的文件:
308266? (http://support.microsoft.com/kb/308266/EN-US/ ) PRB: 非-交集當 SQL Server 處理不同的層代批次中的子系和父層代

您可以增加 -UploadGenerationsPerBatch
-DownloadGenerationsPerBatch 參數先前討論以避免跨層代批次分割父與子系的變更。

發行項處理順序是在遵守先前所討論的規則至一特定的生成集批次中進行維護。不過,「 合併代理程式 」 無法維護跨層代批次中處理順序的發行項。

這篇文章中的資訊適用於:
  • Microsoft SQL Server 2000 Standard Edition
關鍵字:?
kbmt kbinfo KB307356 KbMtzh
機器翻譯機器翻譯
重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤,就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本:307356? (http://support.microsoft.com/kb/307356/en-us/ )
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。