英文原文已於 2012 年 6 月 1 日星期五發佈

過去幾個月來，我們收到關於可復原的項目資料夾 (俗稱「垃圾桶」，雖然我們已正名了) 容量暴增的回報。造成檔案大小暴增的原因主要有兩個：

1. 「單項復原」和訴訟暫止的版本設定
2. 行事曆版本記錄

單項復原和訴訟暫止

「單項復原」和「訴訟暫止」可讓資料保存在信箱內部。若您不熟悉這些功能，我之前有篇文章 Exchange 2010 中的單項復原 (可能為英文網頁) 內有詳細說明，歡迎參考。

除了將資料保存在信箱內部外，「單項復原」和「訴訟暫止」也啟用了版本設定。實質上就是說，當有項目變更時，系統就會執行一次「寫入時複製」(copy-on-write，簡稱 COW) 以保存該物件的原始版本。原始項目會置於 Recoverable Items\Versions 資料夾中。此資料夾使用者是看不到的。

由於 Exchange 2010 在用戶端連線與存取信箱相關資料的方式上有一點改變，此 COW 活動會出現在用戶端存取伺服器上的 Exchange 系統物件 (XSO) 層。

什麼情況下會觸發 COW？

• 對於訊息與貼文 (IPM.Note* 和 IPM.Post*)，COW 會捕捉主題、本文、附加檔案、寄件人/收件人以及寄送/收到日期的變更。
• 對於其他類型的項目，COW 會捕捉一切對該項目所做的變更，但資料夾之間的移動以及讀取/未讀取狀態的變更除外。
• 草稿自動儲存時會被 COW 排除在外，以避免產生過多的複本。

Recoverable Items 資料夾容量暴增的可能原因為何？

COW 的行為可能就是罪魁禍首。我們的調查結果發現，在下列使用 Microsoft Outlook 的案例中，會造成過度 COW 的主因：

1. 您在行事曆中建立了一筆約會。
2. 您附加了一份 Office 文件到該約會並加以儲存
3. 稍後，您想要打開這筆約會，以對照那份 Office 文件內寫的某些內容。於是您開啟了文件。
4. Outlook 會在幕後開始自動儲存這份開啟的約會，以及相對應的開啟文件 (Outlook 預設每隔 3 分鐘就會自動儲存一次)。
5. 每筆自動儲存事件只會觸發一次 COW。但由於此自動儲存需同時儲存 Office 文件和約會兩者，因而就產生兩筆 COW 事件了。若還有更多的附加檔案，則每個後續的檔案都會再額外產生一個隨之而來的 COW 版本。

這下可好了。

既然附加檔案算是訊息的一部分，為每個項目的每個附加檔案分別建立複本實在沒什麼道理。當您儲存一封有附加檔案的項目時，Outlook 實際上是執行了下列動作：

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

COW 則是發生在 SaveAttachment 和 SaveMessage 的階段。深入研究程式碼後，我們發現呼叫 SaveAttachment 儲存附加檔案後，最終將會在與它相關的信件上呼叫 Flush 方法 (用戶端與伺服器狀態同步的一種方法)。而不斷通報 COW 程式碼發生作用的，就是這個 Flush 方法。

經過進一步的分析，我們發現只要有「任何」Flush 呼叫，都會觸發 COW 的運作邏輯。這真是個重大的發現，因為在許多種情況下，都可能會啟動到 Flush，進而導致出現上千筆 COW 活動，也就是過去幾位客戶在他們的環境下遭遇的情況。

行事曆版本記錄

「行事曆版本記錄」是當發生在信箱內部的行事曆變更要透過 COW 儲存時，所進行的程序。「行事曆版本記錄」是 Exchange 2010 推出的新功能，目的是為了協助診斷和修復行事曆的可靠性問題。

行事曆版本記錄的設計，會在每次有行事曆項目被更動時，自動建立一份記錄。這些記錄全部組合在一起，就構成了完整的會議歷史。您可以使用 Get-CalendarDiagnosticLog Cmdlet 查閱此歷史記錄，並依此判定哪些客戶曾採取了破壞性的舉動。「行事曆版本記錄」的第二項用途，是它可以讓行事曆修復小幫手在偵測某行事曆項目不一致的情形時，拿來當做判定的依據。

在 Exchange 2010 的信箱上預設啟用「行事曆版本記錄」。您也可以從 CalendarVersionStoreDisabled 屬性停用或加以啟用。請注意，它的屬性名稱是 CalendarVersionStoreDisabled，所以如果將預設值設成 $false 代表「行事曆版本記錄」預設為啟用。依信箱設定之不同，隨後儲存行事曆項目複本的程序可能會有所不同：

1. 如果信箱未啟用「單項復原」或「訴訟暫止」，縮減版的行事曆項目會保存在 Recoverable Items 資料夾的根目錄下 120 天。此縮減版 (已移除本文和重要性非第一級或非內嵌訊息類型的附加檔案) 是由 COW 所建立。
2. 如果信箱已啟用「單項復原」或「訴訟暫止」，Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中則會保存完整版的行事曆項目。每當有 Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中的行事曆項目受到實際刪除的動作時，就會經由 COW 的基礎架構建立一個縮減的版本。此縮減版會置於 Recoverable Items 資料夾的根目錄中 120 天。不會建立縮減版的唯一情況，是當 Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中某項目的保存時間已超過 134 天 (120 + 14) 時。如果您變更了保留時限，如果很久未執行「信箱資料夾助理」，或如果「訴訟暫止」已停用等，就有可能會發生此情況。

由於上述有關 COW 運作邏輯未分辨 Flush 和 Save 作業的問題，「行事曆版本記錄」在某些情況下，有可能佔用掉 Recoverable Items 資料夾容量配額的一大塊空間 (如果您還記得的話，警告臨界值是 20GB，固定配額是 30GB)。

如果該資料夾大小超過 RecoverableItemsWarningQuota，信箱就會停用「行事曆版本記錄」。其所參考的 RecoverableItemsWarningQuota 值會依信箱設定而異：

1. 如信箱的 UseDatabaseQuotaDefaults 設為 $true，就會參考該信箱資料庫的 RecoverableItemsWarningQuota。
2. 若信箱的 UseDatabaseQuotaDefaults 設為 $false，則會參考該信箱的 RecoverableItemsWarningQuota。

當「行事曆版本記錄」停用時，用戶端存取伺服器上的應用程式事件記錄中就會產生下列事件：

Event ID: 5003
Source: MSExchange Mid-Tier Storage
Task Category: CopyOnWrite
Level: Information
Description: User mailbox <legacyExchangeDN> has exceeded the dumpster warning quota. Calendar logging has been disabled for the mailbox.

我們想做的事還不只如此。此開發目前尚屬早期階段，我不打算討論詳情，但我可以說我們正在努力進一步改善「行事曆版本記錄」，以使本功能對您部署的負面影響降到最低。待時機成熟，我便會透過本部落格向大家報告更多消息。

Ross Smith IV
首席專案經理
Exchange 客戶經驗部

這是翻譯後的部落格文章。英文原文請參閱 Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3