Exchange、執行虛設常式以及資料庫空間收回
英文原文已於 2012 年 8 月 28 日星期二發佈
Exchange 2010 SP2 RU1 隨附了一項有關資料庫空間收回問題的修正。關於這項問題似乎有點混亂，所以由我來解釋這個問題的緣由、這項修正，並討論在資料庫裡使用協力廠商產品虛設常式項目時所抱持的期盼 (執行虛設常式係指使用指標物件取代郵件並將原始版本儲存在外部存放庫的過程)。
錯誤與修正
我們發現使用 Exchange 2010 時，項目已永久刪除 (項目已從存放區中清除) 後卻無法收回資料庫空間的案例並不少見；這包括依日期大量刪除項目的封存案例、附件已刪除的虛設常式執行案例，以及日誌信箱和公用資料夾複寫等其他案例。廣大的客戶群因此受到影響，而這個問題也關係著有效的項目刪除方式。
Exchange 2010 通常會在永久刪除項目數分鐘後嘗試清除已刪除項目的列，但如果某些內容仍擁有該項目的開放式參考，便會清除失敗。舉例來說，清除失敗的可能情況包括內容索引正在索引郵件，或是獨立用戶端正在讀取郵件等。若有任何內容擁有開放式參考，也會清除失敗。若在修正之前發生清除失敗，會造成該空間有效遺漏，而且即使未移動信箱也可能無法復原。
結果會造成已刪除郵件上的未完成參考普遍出現在日誌信箱中或是使用協力廠商封存軟體時，因此碰到此錯誤的絕大多數客戶也都會遇到前述兩種情形之一。但是就技術層面而言，任何用戶端都可能擁有開放式參考，以免項目遭到清除。
SP2 RU1 隨附的修正會新增清除重試機制來改正這個問題。假如因為某些項目仍有開啟參考而導致清除失敗，此存放區就會定期重試，直到清除成功為止。
這項「修正」會執行虛設常式嗎？
執行虛設常式係指協力廠商封存產品將大型郵件轉換成較小項目或虛設常式的過程。此過程通常會以刪除附件並將郵件本文改小的方式來進行。
就執行虛設常式刪除附件而言，可能會受到此錯誤的影響，原因是這些已刪除的附件可能會因開放式參考導致清除失敗，但除此之外，此錯誤與執行虛設常式並無其他關聯。
執行虛設常式後獲得的空間不如預期怎麼辦？
近年來，Exchange Information Store 已有大幅度的更動，但就算是 Exchange 2003 和 2007，當信箱大小增加時，即便執行虛設常式，資料庫大小仍遠超出預期，而大部分原因可歸納成兩種額外負荷。
第一種額外負荷是無法計入郵件大小的屬性。當您在 Outlook 查看郵件大小時，看到的大小並非 Exchange 儲存該封郵件所有資料的總計。我們會儲存部分未計算給使用者、也不會反映在郵件大小的屬性。這些可能是 PR_URL_NAME 等公開記錄屬性或其他用戶端無法存取的內部屬性。
第二種額外負荷則是頁面分割。多年來資料庫頁面大小已有所變更，從 Exchange 2003 的 4 K、Exchange 2007 的 8 K，一直到 Exchange 2010 的 32 K 等。資料庫的每項紀錄必須排入這些頁面，而部分空間可能會因執行效率不一遺留在頁面裡，這便是頁面分割；頁面分割會導致維護資料庫時無法收回未佔用的空間。近期新版 Exchange 的頁面尺寸較大，方便將幾個小項目排入單一頁面，有助於減少分割情形，但仍避免不了一定數量的頁面分割。
一般來說，郵件之間額外負荷的量不會有太大的改變。無論郵件是大是小，額外負荷的量都一樣多。正因如此，即便是將小項目填入資料庫，額外負荷的情形也顯而易見。
舉例來說，假設將 1 MB 大小的項目填入資料庫，而各項目的額外負荷大小為 1 K，則表示資料庫的額外負荷比率約為 0.09%。再者，如果針對資料庫所有項目執行虛設常式，將項目大小降低為 4 K，而 1 K 的額外負荷頓時便顯得格外醒目，且佔用了資料庫的 25%。 我個人曾經建立了一個 Exchange 2003 資料庫，填入的項目不大、也全面執行了虛設常式，但額外負荷卻佔了 70%。
如果是 Exchange 2010 呢？
Exchange 2010 的另一個要素可能會影響到執行虛設常式後的空間收回，而這也是資料庫設計上的改變。
Exchange 2010 大幅降低了資料庫的 IOPS。有絕大多數擺脫以往為了將空間最佳化，每晚必須不斷變換資料庫、四處移動內容的線上重組流程。在 Exchange 2010 中，我們更著重於將信箱內容儲存在連續頁面裡，藉此降低 IO，即便這代表到處可能都有一些未使用的空間。換句話說，Exchange 2010 並非單單只是在瞬間壓縮郵件時積極收回空間而已，更是我們縮小架構、改善 IO 時的現象。如需維護變更的詳細資訊，請參閱 Exchange 2010 中的資料庫維護。
這是否表示執行虛設常式後不必儲存空間？不見得。產品執行虛設常式時通常會刪除附件，因此我們希望能夠釋放空間。儘管 Exchange 2010 尚無這樣的設計，仍可觀察到無附件項目執行虛設常式時，Exchange 2010 也會釋放些許空間。
然而，由於這不在 Exchange 2010 的設計範圍內，我們也無法告知使用虛設常式封存時究竟能夠釋放多少空間。這點必須由您親自測試，或是由封存軟體廠商提供的資料才能得知。
也就是說，項目經修改後若屬性變得比原大小還要小，我們無法保證能收回多少空間。若將項目改小後無法釋放任何空間，可視為 Exchange 2010 設計的緣故。一如往常，若使用協力廠商產品時發現 Exchange 的設計能夠發揮作用，我們會建議您向其尋求支援，並發佈資料庫空間支援調查。
結論
Exchange 2010 SP2 RU1 隨附的修正可協助客戶進行各類封存、執行虛設常式等等，原因是這項修正能夠更妥當地清除永久刪除項目，但執行虛設常式後能夠節省多少磁碟空間仍須透過您或封存軟體廠商加以驗證。在佈建存放裝置時，建議您遵照我們發佈的指引 (包括運用大型信箱，如此便無須仰賴協力廠商封存解決方案) 和工具，確保有足夠的空間存放 Exchange 資料。
Bill Long
這是翻譯後的部落格文章。英文原文請參閱 Exchange, Stubbing, and Database Space Reclamation