Exchange 2010 中的資料庫維護

  • Articolo

英文原文已於 2011 年 12 月 14 日星期三發佈

在過去幾個月，有非常多人討論什麼是背景資料庫維護，以及為什麼這對於 Exchange 2010 資料庫很重要。希望這篇文章能解開這些疑問。

我應該為資料庫執行什麼樣的維護工作？

您需要定期為 Exchange 資料庫執行下列工作：

資料庫壓縮

資料庫壓縮的主要目的在於釋放資料庫檔案內未使用的空間 (不過，請特別注意此動作不會將未使用的空間傳回檔案系統)。此動作能夠壓縮最少頁數頁面的記錄來釋放資料庫中的頁面，如此一來，就可以減少所需的 I/O 數量。ESE 資料庫引擎能夠利用資料庫中繼資料來達到相同效果，資料庫中繼資料是資料庫內用來說明資料庫之資料表的資訊，這些資料表會造訪資料表的每一頁面，並嘗試將資料庫移動至邏輯排序的頁面上。

維持較低的資料庫檔案使用量十分重要，包含下列原因：

  1. 減少與備份資料庫檔案相關的時間
  2. 維護可預測的資料庫檔案大小，這對於計劃伺服器/儲存裝置的大小而言十分重要。

在 Exchange 2010 之前，資料庫壓縮作業是在線上維護視窗中執行的。這個程序會在處理資料庫及重新排序頁面記錄時產生隨機的 IO。不僅能夠釋放資料庫頁面，還可以重新排序記錄，看起來這個程序對於頁面總是十分凌亂的舊版本而言非常地有幫助。另外舊版本還具備儲存結構架構，這表示任何提取資料集的要求 (例如下載資料夾內的項目) 最後都會變成隨機 IO。

在 Exchange 2010 中，經過重新設計的資料庫壓縮變得更像是空間壓縮。此外，也將資料庫壓縮移出線上維護視窗，如今轉變為持續執行的背景程序。

資料庫重組

資料庫重組是 Exchange 2010 的新功能，也稱為舊的 v2 和 B+ Tree 重組。此功能可以壓縮並重組 (循序排序) 標示為/提示為循序的資料庫資料表。資料庫重組十分重要，可更有效地維護磁碟機資源的使用率 (讓 IO 更加循序)，並可維護標示為循序的資料表緊密度。

您可以將資料庫重組程序想像成藉由查看其他資料庫頁面作業，來判斷是否有工作需要執行的監視器。它能夠監控可用頁面的所有資料表，並可在資料表達到臨界值時 (可用的 B+ Tree 頁面總數十分多) 將可用頁面傳回至根。它也能夠維護內含循序空間提示之資料表集的相似物件 (利用已知循序使用模式建立的資料表)。如果資料庫重組查看循序資料表上的掃描/預先讀取，或是非儲存在資料表循序頁面的記錄，則此程序會將受影響頁面移動至 B+ Tree 中的新範圍來重組資料表的該區段。您可以使用效能計數器 (如監視區段所述) 來查看資料庫重組如何在穩定狀態中執行。

資料庫重組是能夠在執行作業時持續分析資料庫的背景程序，並可視需要觸發非同步工作。下列兩個案例可控制資料庫重組的速度：

  1. 未解決工作的最大數：可在資料庫發生重大變更時，防止資料庫重組在第一階段執行過多的工作。
  2. 100ms 的延遲節流：當系統超載時，資料庫重組隨即驅策重組工作。在下一次資料庫進行相同的作業模式時，就會執行驅策的工作。建議您記住驅策的重組工作，並在系統具有更多資源時執行這個工作。

資料庫總和檢查

資料庫總和檢查 (又稱為線上資料庫掃描) 是在大型區塊中讀取資料庫時，以及總和檢查每個頁面時 (檢查實體頁面損毀) 所執行的程序。總和檢查的主要目的在於偵測實體損毀和遺失的清除，交易作業 (過時頁面) 可能無法偵測到這些情況。

Exchange 2007 RTM 與所有舊版本都會在進行備份的期間執行總和檢查作業。這會造成複製資料庫的問題，因為能夠進行總和檢查的複本只有備份的複本。對於備份大量複本的案例而言，這表示主動式複本無法進行總和檢查。因此，我們在 Exchange 2007 SP1 中引進了新的選擇性線上維護工作：「線上維護總和檢查」(如需詳細資訊，請參閱 Exchange 2007 SP1 ESE 變更 – 第 2 部分 (可能為英文網頁))。

在 Exchange 2010 中，資料庫掃描會總和檢查資料庫，然後執行 Exchange 2010 Store 當機作業。當機會使空間流失，線上資料庫掃描能夠找出並復原遺失的空間。資料庫總和檢查可利用 256KB IO 每秒讀取 5 MB 的主動掃描資料庫 (主動式與被動式複本)。I/O 必為循序。Exchange 2010 中的系統是以每 7 天會完整掃描資料庫的前提下進行設計的。

如果完成掃描作業的所需時間超過 7 天，則會在應用程式記錄檔中記錄下列事件：

事件識別碼：733
事件類型：資訊
事件來源：ESE
說明：資訊儲存庫 (15964) MDB01：資料庫 'd:\mdb\mdb01.edb' 的線上維護資料庫總和檢查背景工作無法如期完成。此工作開始於 2011 年 11 月 10 日，截至目前已執行 604800 秒 (超過 7 天)。

如果完成主動式資料庫複本掃描工作的時間超過 7 天，則在掃描工作完成時，會在應用程式記錄檔中記錄下列項目：

事件識別碼：735
事件類型：資訊
事件來源：ESE
說明：資訊儲存庫 (15964) MDB01 資料庫 'd:\mdb\mdb01.edb' 的資料庫維護已完成。此工作開始於 2011 年 11 月 10 日，執行時間為 777600 秒。此資料庫維護工作已超過維護完成時間上限 (7 天)。您需要執行下列一或多個動作：提升資料庫容量裝載的 IO 效能/輸送量、減少資料庫大小，以及/或減少非資料庫的維護 IO。

此外，在完成時間超過 7 天時，也會在應用程式記錄檔中記錄警告。

現在，Exchange 2010 有兩個能夠在主動式資料庫複本上執行資料庫總和檢查的模式：

  1. 永遠在背景中執行：此為預設行為。這個模式適用於所有資料庫 (特別是大小超過 1TB 的資料庫)。Exchange 每天只會掃描一次資料庫。此讀取 I/O 必為循序 (這可讓它更易於在磁碟機上使用)，等同於大部分系統上每秒約 5MB 的掃描率。掃描程序為單一執行式，可利用 IO 延遲加以節流。延遲越高，資料庫總和檢查也就越慢，這是因為總和檢查會等候最後一個批次完成，才開始發佈其他的批次掃描頁面 (一次可讀取 8 個頁面)。
  2. 在排程的信箱資料庫維護程序中執行：當您選取此選項後，資料庫總和檢查會變為最後一個工作。您可以變更信箱資料庫維護排程來設定執行這項工作的時間。這個選項只適用於大小低於 1TB 的資料庫，這種資料庫完成完整掃描的所需時間較少。

無論資料庫大小為何，都建議您使用預設行為，不要針對主動式資料庫將資料庫總和檢查設定為排程的程序 (例如，請不要將資料庫總和檢查設定為線上維護視窗內的程序)。

若為被動式資料複本，資料庫總和檢查會在執行階段期間執行，並持續在背景中運作。

頁面修補

頁面修補是使用狀況良好的複本取代損毀頁面的程序。如前所述，損毀頁面偵測是資料庫總和檢查的功能 (此外，將頁面儲存在資料庫快取中時，也能夠在執行階段期間偵測損毀頁面)。頁面修補可在高可用性 (HA) 資料庫複本上運作。修復損毀頁面的方式會依 HA 資料庫複本的類型 (主動式或被動式) 而有所不同。

頁面修補程序

在主動式資料庫複本上執行 在被動式資料庫複本上執行
  1. 偵測到損毀頁面。
  2. 將標記寫入作用中記錄檔。此標記表示損毀頁數，以及需要替換該頁面。
  3. 新增項目至頁面修補要求清單。
  4. 關閉作用中記錄檔。
  5. 複寫服務將記錄檔傳送至被動式資料庫複本。
  6. 目標信箱伺服器上的複寫服務接收並檢查記錄檔。
  7. 目標伺服器上的資訊儲存庫重新顯示記錄檔以及標記，之後擷取相對應的狀態良好頁面，最後要求重新顯示服務回呼並將頁面傳送至來源信箱伺服器。
  8. 來源信箱伺服器接收狀態良好頁面，確認頁面修補要求清單中是否有項目存在，然後將頁面寫入記錄緩衝區，並同時將頁面插入資料庫快取。
  9. 移除頁面修補要求清單中的對應項目。
  10. 此時，會將資料庫視為已修補 (之後此檢查點會進行提升、清除資料庫快取，以及覆寫磁碟機上的損毀頁面)。
  11. 無訊息地卸除此頁面的其他複本 (接收自其他的被動式複本)，這是因為頁面修補要求清單沒有對應項目。
  1. 偵測到損毀頁面的信箱伺服器會為受影響的資料庫複本暫停重新顯示記錄檔。
  2. 複寫服務會與裝載主動式資料庫複本的信箱伺服器進行協調，並擷取損毀頁面，然後向主動式複本的資料庫標頭要求記錄範圍。
  3. 信箱伺服器更新受影響資料庫複本的資料庫標頭，並插入新要求的記錄範圍。
  4. 信箱伺服器通知要求記錄檔之裝載主動式資料庫複本的信箱伺服器。
  5. 信箱伺服器接收並檢查要求的記錄檔。
  6. 信箱伺服器插入主動式狀態良好的頁面 (擷取自主動式資料庫複本)。將頁面寫入記錄緩衝區，並同時將頁面插入資料庫快取。
  7. 信箱伺服器繼續重新顯示記錄檔。

頁面清空

資料庫頁面清空是使用安全性考量模式 (已清空) 覆寫資料庫中已刪除頁面的程序，會使探索資料變得更加困難。

Exchange 2007 RTM 與所有舊版本會在串流備份程序的期間進行頁面清空作業。此外，因為這些作業是在串流備份程序的期間進行的，所以它們不是記錄作業 (例如，頁面清空不會產生記錄檔)。這會造成覆寫資料庫的問題，其原因為當您執行串流備份時，被動式複本不會清空本身的頁面，只有主動式複本才會清空本身的頁面。因此，我們在 Exchange 2007 SP1 中引進了新的選擇性線上維護工作：「在總和檢查期間清空資料庫頁面」(如需詳細資訊，請參閱 Exchange 2007 SP1 ESE 變更 – 第 2 部分 (可能為英文網頁))。啟用此工作後，它會在線上維護視窗記錄變更 (這些變更會覆寫為被動式複本) 的期間清空頁面。

實作 Exchange 2007 SP1 會在刪除與清空頁面的期間會產生一段很長的延隔時間，這是因為清空頁面程序會在排程維護視窗中執行。因此，我們將 Exchange 2010 SP1 的頁面清空工作變更為持續運作的執行階段事件，清空頁面通常會在強制刪除的異動期間進行。

此外，也可在線上總和檢查程序的期間刪除資料庫頁面。此案例設定的頁面為：

  • 因為卸除的工作 (如果系統超載) 或因為儲存區在工作刪除資料之前發生故障，而造成無法在執行階段期間刪除已刪除的記錄；
  • 已刪除的資料表與次要索引。刪除這兩個物件時，就無法主動刪除其內容，因此，線上總和檢查就會偵測到這些頁面再也不屬於任何有效的物件，並加以刪除。

如需 Exchange 2010 頁面清空的詳細資訊，請參閱瞭解 Exchange 2010 頁面清空。

為什麼能夠在排程維護視窗中執行這些工作？

需要排程維護視窗的頁面清空、資料庫重組、資料庫壓縮，以及線上總和檢查作業會引發重大問題，其中包含：

  1. 排程維護作業會使全年無休資料中心 (這個資料中心能夠裝載各種時區的信箱) 的管理工作變得更加繁雜，並大量降低甚至完全占有排程維護視窗可用的時間。由於 IO 為隨機的，因此不具有節流機制的舊版 Exchange 資料庫壓縮就會降低使用者經驗的品質。
  2. 部署在較低階層儲存裝置 (例如，7.2K SATA/SAS) 上的 Exchange 2010 信箱資料庫，具有 ESE用來執行維護視窗工作的較低效率 IO 頻寬。如此會增加維護視窗的 IO 延遲，導致無法在希望的時間內完成維護活動，因而造成使用者的困擾。
  3. 使用 JBOD 會讓資料庫需要進行額外的資料驗證。能夠找出並重新指派損毀磁區的 RAID儲存裝置，是陣列控制器用來背景掃描指定之磁碟群組的常見儲存裝置。損毀磁區是磁碟上因發生永久性損毀 (例如，磁碟粒子上的物理損毀) 而無法使用的磁區。另外，如果在初始讀取要求時偵測到損毀磁區，RAID 也是陣列控制器用來讀取替代鏡像磁碟的常見儲存裝置。陣列控制器會將損毀磁區循序標記為「損毀」，並將資料寫入新的磁區。這些動作會在背景中完成，並只會些許提高磁碟讀取延遲。如果沒有 RAID 或陣列控制器，就無法偵測損毀磁區和進行補救。如果沒有 RAID，則換為應用程式 (ESE) 無法偵測損毀磁區和進行補救 (例如，資料庫總和檢查)。
  4. 較大磁碟上的較大資料庫需要更多時間來維護資料庫循序性/緊密性。

如前所述的問題對於資料庫維護工作移出排程程序，並於執行階段期間在背景持續執行的 Exchange 2010 而言非常重要。

這些背景工作不會影響使用者嗎？

我們將這些背景工作設計成能夠依據資料庫上執行的活動自動進行節流。此外，我們的訊息設定檔大小計劃指南能夠將這些維護工作匯入帳戶中。不過，您在設計儲存裝置架構時必須特別小心。如果您打算將多個資料庫儲存在相同的 LUN 或磁碟區上，請確認所有資料庫的總大小不超過 2 TB。這是因為資料庫維護會依據資料庫/磁碟區的數量執行序列化來進行節流，而資料庫/磁碟區的總數量不可超過 2 TB。

如何監視這些背景維護工作的效能？

舊版 Exchange 會使用應用程式記錄檔中的事件來監視例如線上重組這類的功能。而 Exchange 2010 則不會記錄任何重組和壓縮維護工作的事件。不過，您可以使用效能計數器來追蹤 MSExchange 資料庫 ==> 個體物件下的背景維護工作：

計數器 說明
資料庫維護期間 自上次完成此資料庫維護後所經過的小時數
資料庫維護頁面損毀總和檢查 資料庫維護階段發生的無法修正頁面總和檢查數目
重組工作 目前正在執行的背景資料庫重組工作數目
完成的重組工作 (以秒為單位) 即將完成的背景資料庫重組工作速率

您可以在 MSExchange 資料庫物件底下找到下列頁面清空計數器：

計數器 說明
清空的資料庫維護頁面 表示自上次呼叫效能計數器後資料庫引擎清空的頁面數
清空的資料庫維護頁面 (以秒為單位) 表示資料庫引擎清空頁面的速率

如何檢查資料庫中的空白區域？

您可以使用 Shell 來檢查資料庫中可用的空白區域。若為信箱資料庫，請使用：

Get-MailboxDatabase MDB1 -Status | FL AvailableNewMailboxSpace

若為公用資料夾資料庫，請使用：

Get-PublicFolderDatabase PFDB1 –Status | FL AvailableNewMailboxSpace

如何回收空白區域？

一般而言，在查看資料庫中可用的空白區域之後，您一定會想問：如何回收空白區域？

大部分的人會使用 ESEUTIL 執行離線資料庫重組來回收空白區域。然而，我們不建議您這麼做。當您執行離線重組時，會建立全新的資料庫，且無法在交易記錄檔中記錄用來建立此新資料庫的作業。這個新資料庫也具有新的資料庫簽章，這表示您會讓與此資料庫相關的資料庫複本失效。

在您遇到的事件中，具有許多空白區域的資料庫和您意料之外的一般作業都可以回收空白區域，建議您：

  1. 建立新的資料庫與相關的資料庫複本。
  2. 將所有信箱移動至新的資料庫。
  3. 刪除原始的資料庫與其相關的資料庫複本。

詞彙誤解

許多的誤解皆肇因於背景資料庫維護。整體而言，所有先前所述的工作可構成背景資料庫維護。然而，Shell (EMC) 和 JetStress 都會將資料庫總和檢查視為背景資料庫維護，而這些就是您使用這些工具來啟用或停用背景資料庫維護時所設定的項目。


圖 1：使用 EMC 來啟用資料庫的背景資料庫維護

使用 Shell 來啟用背景資料庫維護：

Set-MailboxDatabase -Identity MDB1 -BackgroundDatabaseMaintenance $true


圖 2：在 JetStress 測試期間執行背景資料庫維護

儲存裝置廠商建議我停用背景維護工作的資料庫總和檢查，我應該怎麼做？

如果儲存裝置設計不正確 (即使儲存裝置為循序的)，資料庫總和檢查會變成 IO 的重擔，這是因為設計不正確的儲存裝置會執行 256K 讀取 IO，每個資料庫每秒大約會產生 5MB 的 IO 量。

如我們的儲存裝置指南所述，建議您將儲存裝置陣列等量大小 (寫入每個陣列磁碟的等量大小；又稱為區塊大小) 設定為 256KB 以上。

使用 JetStress 測試您的儲存裝置 (可能為英文網頁)以及確認測試階段包含資料庫總和檢查也非常重要。

最後，如果因為資料庫總和檢查造成 JetStress 無法執行的話，您可以參考下列做法：

  1. 不要使用等量磁碟：使用 RAID-1 組或 JBOD (可能需要變更架構)，善用 Exchange 2010 中的循序 IO 模式。

  2. 進行排程：將資料庫總和檢查設定為排程程序，而非背景程序。將資料庫總和檢查當作背景程序實作時，我們發現某些儲存裝置陣列會針對隨機 IO 進行最佳化 (或具有頻寬限制)，因此，這些儲存裝置陣列就無法控制循序讀取 IO。這也就是為什麼我們要將儲存裝置陣列設計為可關閉的原因 (這會將總和檢查作業移動至維護視窗)。

    若要這樣做，建議您減少資料庫的大小。並請記住，被動式複本仍然可以將資料庫總和檢查當做背景程序來執行，因此，您仍需占用儲存裝置架構的輸送量。如需此主題的詳細資訊，請參閱 Jetstress 2010 與背景資料庫維護 (可能為英文網頁)。

  3. 使用不同的儲存裝置或提升儲存裝置的容量：選擇符合 Exchange 最佳做法的儲存裝置 (256KB 以上的等量大小)。

結論

變更 Exchange 2010 資料庫引擎的架構能夠大幅改善效能和強度，但會變更舊版資料庫維護工作的行為。希望這篇文章能協助您了解 Exchange 2010 中的背景資料庫維護。

Ross Smith IV
資深專案經理
Exchange 客戶經驗

這是翻譯後的部落格文章。英文原文請參閱 Database Maintenance in Exchange 2010