瞭解信箱資料庫及記錄檔容量的因素

上次修改主題的時間： 2010-02-03

本主題說明在 Microsoft Exchange Server 2010 信箱伺服器儲存設計中規劃信箱資料庫與記錄容量時，應該要考量的因素。

信箱資料庫容量

許多因素都會影響 Exchange Server 2010 信箱資料庫的容量大小規劃。本節的重點如下：

• 信箱儲存區配額
• 資料庫空白字元
• 信箱資料庫可復原項目
• 實際信箱大小
• 內容索引
• 離線資料庫維護
• 復原資料庫
• 資料庫大小
• 資料庫成長負擔

信箱儲存區配額

儲存大小限制是必須了解的第一項要素，亦即組織中有效的信箱儲存配額。知道使用者在信箱中可以儲存的資料量之後，就可以決定伺服器可容納的使用者信箱數目。儘管信箱儲存配額可以因應變動的組織需求而改變，不過確立信箱儲存配額目標，卻是決定您所需信箱資料庫容量的第一步。

例如，如果您的伺服器上含有 5,000 個 250 MB 的使用者信箱，則至少需要 1.25 TB 的磁碟空間 (不包括復原項目所需的空間)。如果沒有針對信箱儲存配額設定限制，您會發現很難預估資料庫容量。Exchange 2010 的信箱儲存配額，需要包含主要信箱與個人封存信箱 (如果有使用) 的空間。如需詳細資訊，請參閱管理信箱伺服器及管理個人封存。

資料庫空白字元

實體磁碟上的資料庫大小不只是使用者數目乘以信箱儲存配額。當大多數使用者都未接近其信箱儲存配額時，資料庫會耗用較少空間，此時空白字元不會造成容量問題。整個資料庫中總是會到處散佈空白頁面或空白字元。在背景資料庫維護期間，會移除標示為要從資料庫移除的項目，進而釋放這些頁面。由於全天候 (24x7) 線上重組程序的不斷進行，所以空格百分比一直改變。

您可以了解資料庫中使用者信箱所接收與傳送的郵件數量，來預估資料庫中的空格數量。舉例來說，如果資料庫中有一百個 2 GB 的信箱 (總共 200 GB)，使用者每天平均傳送和接收 10 MB 的郵件，則空白字元大約為 1 GB (100 個信箱 × 每個信箱 10 MB)。如果背景資料庫維護作業無法完成完整作業，則空格數量可能會超出此約略數量。

回到頁首

信箱資料庫可復原項目

每個資料庫都有一個暫放空間可儲存虛刪除的項目。依據預設，Exchange 2010 中的虛刪除的項目會存放 14 天，而行事曆項目則會存放 120 天。

此外，Exchange 2010 還包含在超過刪除的項目保留期限之前，預防資料遭到清除的功能。這項功能稱為單一項目復原。單一項目復原功能一經啟用 (預設停用)，在刪除的項目 14 天保留期限內信箱大小，便會額外地增加 1.2%。如果是行事曆版本的記錄資料 (預設為啟用)，信箱大小會額外增加 5.8%。

判斷啟用單一項目復原與行事曆版本記錄功能之刪除的項目 14 天保留期限暫放空間需求時，所使用的公式如下：

暫放大小 = (每日內送/外寄郵件 x 平均郵件大小 x 刪除的項目保留期限) + (信箱配額大小 x 0.012) + (信箱配額大小 x 0.058)

例如，假如信箱大小為 2 GB，則啟用刪除的項目 14 天保留期限之單一項目復原時，需要額外的 25 MB 空間，而啟用行事曆記錄功能則需要額外的 119 MB。

如需相關資訊，請參閱下列主題：

• Understanding Recoverable Items
• 管理可復原的項目
• 瞭解行事曆修復
• 管理行事曆修復

實際信箱大小

當時間一久，使用者的信箱達到信箱儲存配額時，需要刪除的郵件量就等於內送郵件量，以維持低於信箱儲存配額的數量。這表示暫放的大小會增加至每天所傳送與接收的電子郵件數量，乘以刪除的項目保留期限內所經過天數的值。如果大多數使用者未達到儲存配額，則只會刪除部分內送/外寄郵件。因此，暫放會隨著信箱大小而成長。

下列是以 2 GB 信箱 (不使用個人封存功能) 來計算資料庫大小的公式：

資料庫大小 = 信箱配額 + 空格 + 暫放大小

例如，在每個當天信箱配額為 250 MB (共可收取 100 封郵件) 中，每週 (五個工作天) 收到 37 MB 的郵件 (平均郵件大小為 75 KB)，則在啟用 14 天單一項目復原功能的暫放區內會耗用 120 MB 的空間，並且耗用 7.3 MB 的空格，而信箱總大小為 378 MB。另一個例子是，每週接收 37 MB 郵件的 2 GB (100 封郵) 件設定檔信箱，同時會在暫放中耗用 246 MB (5%) 的空間，再加上 7.3 MB 的空白字元，信箱總大小為 2.25 GB。

在您決定所規劃的實際信箱大小後，您可以使用該值來判斷每個資料庫的使用者數目上限。將預估的信箱大小，除以建議的資料庫大小。這也有助於判斷您需要多少資料庫來處理規劃的使用者數目 (假設是完全植入的資料庫)。請注意，因為非交易輸入/輸出 ( I/O) 或硬體限制的原因，您可能必須修改單一伺服器上的使用者數目。有些系統管理員偏好使用較多的資料庫來進一步縮小資料庫大小。這種方式對備份和還原視窗有幫助，但會增加在每個伺服器上管理多個資料庫的複雜性。

內容索引

內容索引會建立索引或目錄，可讓使用者輕易且快速地搜尋其郵件項目而不必手動搜尋整個信箱。Exchange 2010 會建立約佔資料庫總大小 10% 的索引，該索引放在與資料庫相同的 LUN 上。因此，計算資料庫 LUN 大小時，需針對內容索引部分額外計入容量的 10%。

回到頁首

離線資料庫維護

需要離線修復或壓縮的資料庫，所需的容量將等於目標資料庫大小加 10%。不管您為單一資料庫或備份組配置的空間是否足夠，都要有額外空間來執行這些作業。

復原資料庫

如果您計劃使用復原資料庫作為嚴重損壞修復計劃的一部份，則需要足夠容量才能夠依您的期望同時還原該伺服器上的所有資料庫。如需相關資訊，請參閱復原資料庫。

資料庫大小

資料庫大小最終會決定您在每個資料庫中所部署的信箱數量，以及您所部署的資料庫數量。您所部署的資料庫大小，取決於下列幾個因素：

• 備份/還原的服務等級協定 (SLA)   資料庫大小最終會指定您在合理的時間範圍內，對資料的備份與還原速度。
• 高可用性架構   如果您打算擁有多重資料庫副本，由於您的副本會在復原作業期間成為第一線防禦機制，因此您可以將資料庫大小設計為 2 TB。
• 儲存架構   如果您打算在 JBOD 儲存裝置 (一顆磁碟同時包含資料庫與對應的交易記錄) 上部署，則您使用的磁碟大小會要求最大資料庫大小。例如，在 1 TB 的磁碟上 (格式化容量約為 917 GB)，您還需要納入交易記錄與內容索引的空間，並確定您沒有用盡所有可用的空間。

資料庫成長負擔

在考慮及計算過所有因素之後，建議為資料庫資料庫邏輯單元編號 (LUN) 納入 20% 的額外負荷因素。此值將說明在計算信箱大小和空白字元時，資料庫中不一定會顯示的其他資料。

回到頁首

記錄容量

交易記錄檔在記錄資料庫引擎執行的每筆交易。所有交易都會先寫入記錄，然後慢慢地寫入資料庫。和 Exchange Server 2003 不同，Exchange 2010 中的交易記錄檔大小已從 5 MB 減少為 1 MB。此變更的目的是為了支援連續複寫功能，以及盡量減少主要儲存故障時遺失的資料量。

您可以使用下表預估會在 Exchange 2010 Mailbox Server 上產生的交易記錄數目，其平均郵件大小為 75 KB。

每一個信箱設定檔所產生的交易記錄檔數目

您可以使用下列指南，了解郵件大小會如何影響交易記錄的產生速率：

• 如果平均郵件大小加倍而變成 150 KB 時，則每個信箱產生的記錄會以 1.9 的係數增加。此數字代表包含附件和郵件表格 (郵件內文和附件) 的資料庫百分比。
• 此後，當郵件大小加倍超過 150 KB 時，每個信箱的記錄產生速度也會加倍，從 1.9 增為 3.8。

例如，您每天會收到 100 封郵件，而且：

• 平均郵件大小為 150 KB，則每個信箱所產生的記錄檔數量為 20 × 1.9 = 38。
• 平均郵件大小為 300 KB，則每個信箱所產生的記錄檔數量為 20 × 3.8 = 76。

下列各節將討論會影響您的記錄檔容量大小的因素：

• 備份及還原因素
• 移動信箱作業
• 記錄成長負荷因素
• 高可用性因素
• LUN 容量規劃

備份及還原因素

決定記錄 LUN 的大小仍然要根據備份和還原設計。例如，如果您的設計可讓您回到兩週前並重新顯示之後產生的所有記錄，則您需要兩週的記錄檔空間。如果您的備份設計包括每週執行完整備份及每日執行差異備份，則記錄 LUN 必須大於整週份的記錄檔空間，才能在還原期間進行備份和重新顯示。大多數在夜間執行完整備份的企業，會依據每日所需的記錄檔產生容量來配置 2-3 倍容量。這是為了防止因備份失敗造成記錄磁碟機填滿，迫使資料庫卸載的情況。

如果您打算使用 Exchange 2010 內的信箱回復性與單一項目復原功能，做為備份基礎結構 (因而啟用循環記錄功能)，最好的作法，應該是確定依據每日所需的記錄檔產生容量來配置 3 倍的容量。如此一來，當複寫作業在正常情況下暫停或是無法運作時，資料庫不會因為記錄檔截斷失敗而卸載。

移動信箱作業

移動信箱是大型信箱部署的主要容量因素。許多大型公司會每晚或每週將某個百分比的使用者信箱移至不同的資料庫、伺服器或站台。如果您的組織這樣做，您會發現需要提供記錄 LUN 額外的容量以應付使用者信箱移動作業。

雖然來源伺服器會記載記錄的刪除，而且都不大，但目標伺服器必須先將所有傳輸的資料寫入交易記錄。如果 1 天內產生 10 GB 記錄檔，並且保留 3 天的緩衝 (30 GB)，則移動五十個 2 GB 信箱 (100 GB) 會填滿目標記錄 LUN 而造成停機。在這種狀況下，您可能必須為記錄 LUN 配置更多容量以應付移動信箱作業。

記錄成長負荷因素

針對大多數部署，我們建議您在建立記錄 LUN 時於記錄大小中增加 20% 的額外負荷係數 (在考慮所有其他係數之後)，以確保在非預期記錄產生的時候備有所需的容量。

高可用性因素

在以下三個重要情況下，高可用性會影響記錄檔容量需求：

• 資料庫副本計數   整個系統的記錄檔容量，會依據高可用性部署作業中選定的資料庫副本數量而增加。如果您將三個資料庫副本平均分配到三台伺服器上，則需要為每一台伺服器上的每個副本佈建記錄檔容量。
• 記錄檔截斷機制   Exchange 2010 中的高可用性，以及每個信箱資料庫最高可容納 16 個副本的功能，共同提供了使用連續複寫循環記錄功能，以做為記錄檔截斷/刪除機制的基礎，而不用執行完整/遞增備份來截斷/刪除較舊的記錄檔。如需詳細資訊，請參閱瞭解備份、還原和嚴重損壞修復和高可用性及站台恢復中「記錄檔截斷而不備份」一節。
• 資料庫副本重新顯示延遲   Exchange 2010 中的高可用性，可讓您選擇在被動資料庫副本上延遲記錄檔的重新顯示 (在個別副本上設定)。當記錄檔在延遲的資料庫副本中顯示時，您可透過此功能來提供延遲機制。此延遲機制可有效防止不需要的內容複寫至所有資料庫副本的事件，並在資料庫開始顯示含有不需要內容的記錄檔之前暫停重新顯示，藉此防止在延遲的資料庫副本內顯示這些內容。
  一旦資料庫副本啟用重新顯示延遲功能，記錄檔容量需求會跟著改變。如果您已設定 14 天的延遲，就需要佈建相當於 17 天的記錄檔。只有當資料庫副本已設定延遲時，才需要設定額外的記錄檔容量，其他沒有設定延遲的資料庫副本，將維持正常 (沒有延遲) 的記錄檔容量需求。

如需相關資訊，請參閱瞭解高可用性的因素。

LUN 容量規劃

LUN 的容量需要，將取決於資料集 (資料庫、交易記錄檔、內容索引與復原空間) 與其他額外可用的空間。大多數作業管理程式都設有容量閾值，可在 LUN 容量使用超過 80% 的時候發出警示。

您可以使用下列公式，來決定適當的 LUN 大小：

LUN 容量 = 資料大小 / (1 - 可用空間百分比需求)

例如，如果您的資料大小需求為 3000 MB，且可用空間需求為 20%，則裝載此資料的 LUN 大小必須為 3750 MB。