公用資料夾複寫疑難排解 – 第 2 部分：疑難排解現有資料的複寫
英文原文已於 2011 年 11 月 28 日星期一發佈
英文原文張貼於美國部落格：2006 年 1 月 20 日
這是有關疑難排解公用資料夾複寫問題的第二篇部落格文章。在第一篇文章 (可能為英文網頁)中，我們討論到疑難排解新變更的複寫。此部落格文章則是討論疑難排解現有資料的複寫，而本系列中的最後一篇文章 (可能為英文網頁)，將會討論疑難排解複本刪除及常見問題。若希望能有全面性的了解，請閱讀所有參考資料！
疑難排解現有資料的複寫
當新變更進行了複寫但舊的未變更項目沒有進行複寫時，就會發生回填問題。最常發生階層回填的情況，就是在建立新的公用儲存區時。最典型的內容回填情境，就是當公用儲存區新增至資料夾的複本清單時。
當您有這類回填問題時，可能會想到一個簡單的因應措施，就是直接對所有項目進行變更。這麼做會規避掉中斷的回填程序，並會將所有項目以新變更進行複寫。雖然我曾寫過常用於這種情形的兩項工具 (PFDAVAdmin 和 ModifyItems)，但是一般來說最好是進行回填程序的疑難排解，並修正根本原因。如果您只是變更所有項目以讓複寫能進行，那麼未來當複本又不同步時，最後還是會發生相同的回填問題。明白了這一點，就讓我們繼續討論回填這件事。若要了解回填程序，首先必須了解如何追蹤變更。
在建立以及每次修改儲存區中的每個資料夾與郵件時，系統都會指派一個「變更號碼」(CN)。在進行複寫時，會用每個物件的 CN 來判定該物件是否需要複寫。一組 CN 稱為 CNSet。特定伺服器上之特定資料夾的 CNSet，稱之為狀態資訊。此狀態資訊內含於每個複寫郵件中，而每個郵件類型 0x2 都含有傳送伺服器的階層狀態。同樣地，每個郵件類型 0x4 都含有傳送伺服器的該特定資料夾之狀態資訊。所有其他複寫郵件類型也都含有其各自資料夾的狀態資訊。
第一次裝載新的公用儲存區時，會將階層的狀態要求 (類型 0x20) 傳送至所有現有的公用儲存區。同樣地，當新的儲存區新增至資料夾的複本清單時，該儲存區將會傳送 0x20 至該資料夾的所有其他複本。就像所有複寫郵件一樣，狀態要求含有 CNSet (其中包含送出儲存區擁有之發生問題資料夾 (或階層) 的所有 CN)，並且會要求其他儲存區回應它們是否擁有送出儲存區所沒有的 CN。請注意，在 Exchange 2003 SP2 之前，並不會要求每個複本回應狀態要求，所以有些儲存區會忽略狀態要求，即使它們有送出儲存區所沒有的變更也是一樣。2003 SP2 伺服器會要求所有複本的回應，而且只要它有送出伺服器所沒有的變更，則即使送出伺服器沒有特別要求，它也會回應。如此可以大幅加強回填程序期間所做的決定。狀態要求的獨特之處，在於它沒有包含任何要複寫的資料，它只有變更號碼的清單而已。其他儲存區會以狀態郵件 (0x10) 進行回應，其中會列出它們自己用於該相同資料夾 (或階層) 的 CNSet。當送出伺服器收到 0x10 郵件時，會比較其中所包含的 CNSet 與其本身的 CNSet。如果 0x10 包含的變更是儲存區所沒有的，就會開始回填程序。
回填程序的第一個步驟，就是新增項目至發生問題之資料夾的回填陣列。這些項目有 CNSet，說明遺失的變更，並且有逾時值，說明儲存區何時會要求遺失的資料。回填逾時值會依狀況而有所不同。在新的公用儲存區上線或新增資料夾新的複本之情況下，一開始的逾時值為 15 分鐘。
在正常的作業程序期間，回填項目可能也會新增至回填陣列。請考量特定公用儲存區已在兩個不同 0x2 郵件中廣播兩項變更的情況。假設系統管理員將第一個 0x2 郵件從佇列中刪除，而第二個 0x2 郵件繼續進行。當其他伺服器收到此 0x2 時，會發現狀態資訊中的 CNSet 包含它們從未取得的 CN。因此，它們就會建立該資料的回填項目。在正常的複寫程序期間發現之遺失資料的回填項目，一開始的逾時值為 6 小時 (如果相同「路由群組」(RG) 中提供該資料) 或 12 小時 (如果只有不同的 RG 中提供該資料)。每次發出回填要求時，下一次內部 RG 要求的逾時值將會是 12 小時然後是 24 小時，而 RG 要求之間的逾時值會是 24 小時及 48 小時。
儲存區每隔 5 分鐘就會查看是否有任何回填項目達到逾時值。如果有的話，就會針對遺失的 CN 發出回填要求 (類型 0x8)，而逾時值會設為下一個間隔。回填要求不是廣播，它會導向至單一伺服器 (先前在傳送至要求伺服器的狀態資訊中指出有遺失 CN 的伺服器之一)。當該伺服器收到內送 0x8 時，會立刻處理具有一或多個回填回應 (0x80000002 表示是階層，而 0x80000004 表示是內容) 的要求及回應，其中包含所要求之變更號碼的實際資料。就像是回填要求一樣，回填回應不是廣播，它們只會傳送到要求伺服器。
如果要求伺服器成功地處理了內送回填回應，則其包含的 CN 就會從該儲存區的回填陣列中清除。實際上，含有回填陣列中未解決之 CN 的任何內送郵件，都會讓那些 CN 從陣列中清除。
疑難排解
如您所見，在疑難排解回填程序時，還有許多問題需要回答。
1. 儲存區知道它遺失資料嗎？
首先，您應該判斷伺服器是否甚至了解其他儲存區有它需要要求的變更。可惜的是，沒有支援的工具或公用程式可讓您直接檢視回填陣列，查看其中是否有任何項目。但是，有其他較多間接的方法可以讓您弄清楚。
其中一個方法就是等待。如果伺服器知道它遺失資料，則每 24 小時或 48 小時會至少要求一次遺失資料。這表示您只要開啟記錄功能，然後等著看 0x8 郵件是否會不見。如果您從未看到出問題的資料夾有 0x8，但有看到其他資料夾出現 0x8，那可能是已達到未處理回填限制，我們會簡短簡地討論這件事。
另一個選項是確定伺服器會收到最新的狀態資訊。請記住，伺服器只會在新增複本之後傳送一次狀態要求。在那之後，就只會透過正常的複寫程序收到狀態資訊。所以如果因為回應中的 0x20 或 0x10 遺失或遭刪除，而失去了一開始嘗試取得狀態的機會，就會無限期枯等，而且甚至不知道它遺失了任何東西。有幾個方法可以確定伺服器已收到資料夾的狀態資訊。
- 前往擁有所有資料的伺服器，並利用新增、刪除或修改郵件，以對資料夾進行變更。如果是階層，則請建立、刪除或變更資料夾內容。所產生的 0x4 或 0x2 會分別包含該資料夾或階層的狀態資訊。當遺失資料的伺服器成功地處理內送複寫郵件時，您就知道它已新增了所有適當的項目至回填陣列。
- 使用 Exchange 2003 ESM 中的 [同步處理內容] 選項。這是一般很少用但其實非常實用的選項。請到公用資料夾樹狀目錄底下，再前往發生問題的資料夾即可找到此選項。反白左側窗格中的資料夾。在右側窗格中按一下 [狀態] 索引標籤。於擁有所有資料的伺服器上按一下滑鼠右鍵，再選擇 [同步處理內容]。如此會進行兩件事：它會讓伺服器針對資料夾發出狀態要求 0x20，並讓它立即使所有回填項目逾時。請注意，我有提過您應該要從已具備資料的伺服器進行「同步處理內容」。您可能會想知道當其他伺服器有需要逾時的回填項目時，您為什麼要這麼做。請記住，在這個時候，我們只是嘗試確定遺失資料的伺服器「知道」它有東西需要回填。因此，我們可以從擁有資料的伺服器使用 [同步處理內容]，傳送 0x20 至沒有資料的伺服器。在此情況下，我們並不是真的想要看狀態 0x10 回應 0x20。我們只是想要讓遺失內容的儲存區，從含有內容的儲存區接收資料夾的複寫郵件，這樣它才可以新增適當的項目至回填陣列。來自含有資料之伺服器的 0x20 可達到此目的。請注意，在 Exchange 2003 SP2 中，現在只要於公用資料夾節點本身上按一下滑鼠右鍵，即可將「同步處理內容」用於階層。
- 使用「複寫旗標」登錄值 (KB813629)。如果您將這個值隨著 KB321082 的 [啟動時啟用複寫郵件] 值一起設定好，就會使儲存區在啟動時為每個資料夾傳送狀態要求 0x20。同樣地，您會想要在擁有內容的伺服器上使用此功能；此步驟的重點是要讓擁有內容的伺服器，傳送其狀態資訊至遺失內容的伺服器。
- 使用 2003 ESM 傳送回填回應。在 2003 Sp1 中，您可以使用 [傳送階層] 選項來傳送階層回填回應，以及使用 [傳送內容] 選項來傳送資料夾內容回填回應。在 2003 SP2 中，這兩個選項都變成了 [重送變更]。如此會針對您指定的資料範圍傳送回填回應，但是您或許不應該指定整個資料範圍，因為那樣可能會滿足所有未解決的回填項目，而最後導致解決了原始問題。您應該只指定一天或兩天的範圍。這樣會使 0x80000002 或 0x80000004 傳送至目標伺服器，又達到針對擁有資料的儲存區提供其狀態資訊之目的。
一旦使用了上述其中一個選項強制狀態資訊，並已查看應用程式記錄檔，確認遺失資料的儲存區收到了內送郵件之後，您就知道儲存區知道自己遺失資料了。
2. 儲存區有要求遺失的資料嗎？
在您確定儲存區在知道自己需要回填某些資料之後，儲存區是否曾經發出回填要求？請在儲存區嘗試回填資料幾次之後回想一下。您可能需要等待 24 小時或 48 小時，才會進行下一次的回填要求，因為那分別是網站內部及網站之間回填的最長逾時間隔。有一個方法可以加速此作業，那就是再次使用「同步處理內容」，但這次要從遺失資料的伺服器進行。如此可以立即讓該資料夾的回填項目逾時。但是，您可能還是會發現儲存區沒有針對您想要的資料夾發出回填要求。如果發生這種情況，請查看接下來 24-48 小時的應用程式記錄檔。如果儲存區為其他資料夾傳送了回填要求，但沒有為您想要的資料夾傳送回填要求，則可能已達到未解決的回填限制。
如果您已將許多資料夾的複本新增至新的儲存區，而複寫一開始似乎很正常，但之後有一兩天的時間漸漸停止，當您遇到這種情形，可能是已經達到未解決的回填限制。未解決的回填限制是用以控制複寫流速的機制。儲存區預設一次只允許 50 個未解決的回填要求。一旦有 50 個未解決的回填要求，就會一再重新要求那 50 個要求，直到滿足那些要求為止。只要滿足任一未解決的項目，就會在 OBL 中開啟一個空位，以供所要要求的新資料集使用。這表示，如果 50 個要求有因為任何原因而需要解決問題，複寫就無法繼續。
如果您觀察到這種行為，應查看應用程式記錄檔，看看儲存區要求什麼。您會看到目前 50 個未解決回填要求的定期 0x8 郵件，而且會發現沒有收到任何回填回應，這就是為什麼它們仍未解決的原因。在這個時候，您應該將重點轉向為疑難排解儲存區目前嘗試回填的資料夾之一，因為解決此問題可讓它能繼續處理其他資料夾。
還有另一個選擇，就是增加未解決的回填限制 (OBL)。若要執行此作業，您可以針對該儲存區，在登錄機碼之下建立一個名為「複寫未解決回填限制」的登錄值。最大值為 5000 小數位數。但是，一旦您這麼做之後，就會開啟複寫防洪閘門，也就很難判斷是哪 50 個資料夾造成堵塞。您要等到一切穩定之後，才能開始進行疑難排解。一般而言，我建議將限制保留在 50，並修正問題，而不是用增加限制的方式加以解決。
如果看起來不是 OBL 的問題，而且您仍然看不到發生問題之資料夾的外寄 0x8 郵件，請參閱本系列最後一篇文章 (可能為英文網頁)中的＜常見問題＞。
3. 其他儲存區是否回應要求？
一旦您有要注意的回填要求，就需要判斷回填目標是否曾經收到要求。請在該伺服器的應用程式記錄檔中查看是否有內送 0x8。您也可以在應用程式記錄檔中搜尋是否有傳送端之外寄事件中提到的郵件識別碼。如果在應用程式記錄檔中找不到任何跡象，請使用郵件追蹤以查看它最遠到哪裡了。如果有收到 0x8，它應該是會幾乎立刻以一或多個 0x80000002 或 0x80000004 郵件加以回應 (您會常常看到許多對單一回填要求的回填回應，因為變更不是全都在單一郵件中傳送)。當然，產生回填回應郵件所花費的時間，會因為資料夾中的資料以及複寫郵件大小限制而有所不同。例如，如果您將複寫郵件大小上限設為 1 GB，則回應伺服器會嘗試將整個階層封裝在單一回填回應中，所以只是為了封裝就可能會花到一個小時以上！
4. 要求伺服器是否收到回應？
現在是時候來檢查要求伺服器上的應用程式記錄檔，以查看它是否收到了回填回應。如果沒有，請追蹤郵件，看它最遠到哪裡。如果收到了回填回應，並將它記錄在應用程式記錄檔中，則該回填要求應已滿足，可以繼續進行。
如上述，如果您發現郵件追蹤顯示這些郵件之一已傳遞至儲存區，但應用程式記錄檔並沒有顯示該內送複寫郵件，請參閱本系列最後一篇文章 (可能為英文網頁)中的＜常見問題＞。
下一篇部落格文章：疑難排解複本刪除及常見問題 (可能為英文網頁).
這是翻譯後的部落格文章。英文原文請參閱 Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data