Share via

容量規劃 - 預留足夠的交易記錄空間，才能確保資料庫狀態良好及正確地掛接

  • Article

英文原文已於 2011 年 11 月 09 日星期三發佈

有一天在和我們的支援專案經理 Nino Bilic 聊天時，他提到了一件令人擔心的事情，說 Premier 客戶在開啟 Exchange 2010 時所遇到之嚴重情況排名第一的原因，竟然是因為儲存交易記錄 LUN 的磁碟空間不足，導致信箱資料庫卸載。

很吃驚嗎？我先暫停一會兒，等大家回神。當然，我聽了也十分驚訝。老實說，我以為有了「信箱需求計算器」加上我們在 TechNet 上的說明，這問題早就該解決了。當 Nino 和我說了這件事之後，他老兄甚至覺得應該由小弟我而不是他來寫一篇部落格文章，討論交易記錄容量規劃這項主題 (Nino，你還真夠朋友)。

容量規劃基本注意事項

為能正確地規劃交易記錄 LUN 的大小，我們必須先了解一些有關於環境事項：

  1. 資料庫中會存放多少信箱？
  2. 資料庫中信箱的訊息設定檔為何？
  3. 每則訊息的平均多大？
  4. 每個信箱的平均多大？
  5. 一天平均會移動多少個信箱？
  6. 使用什麼備份及還原解決方案？
  7. 使用的解決方案需要考慮到其他的錯誤狀況嗎？好比網路問題等等。

在開始討論之前，讓我們假設每個資料庫將會裝載 250 個信箱。每個信箱一天平均會傳送/接收 150 則訊息，而每則訊息的平均大小為 100KB。從了解信箱資料庫與記錄容量因素中所列的表格我們知道，當訊息設定檔為 150 則，且每則訊息的平均大小為 75KB 時，一天 (以 24 小時計) 之內就會產生 30 個交易記錄檔。由於訊息大小超過 75KB，因此在計算每個信箱所產生的交易記錄檔數量時，也必須將這點考慮進去。規則中明定：

當訊息平均大小加倍到 150 KB 時，每個信箱所產生的交易記錄檔數量，將會以 1.9 倍的比率增加。此數字代表包含附件與訊息表格 (本文與附件) 之資料庫的比例。

因此，我們可以利用這組公式，計算當訊息平均大小為 100KB 時的影響：

150 / 1.9 = [設定檔的訊息平均大小] / x

x = (100 * 1.9) / 150

x = 1.266666666666667 ~ 1.27

由此可得，當訊息大於基準 25KB 時，每天每個信箱所產生的交易記錄檔數量，將會增加 1.27 倍；也就是每個信箱每天會產生 30 個交易記錄檔 * 1.27 = 39 個交易記錄檔。這表示假使資料庫包含 250 個信箱，則每個資料庫每天所產生的交易記錄檔數量將是 39 * 250 = 9,750 個交易記錄檔。

移動信箱也會產生交易記錄檔。每個移動到目的地資料庫的信箱，會在目的地 (而非來源) 產生約略等於該信箱大小 (包含 [可復原的項目] 資料夾的內容) 的交易記錄。舉例來說，一天若移動信箱總數的 1%，表示每天會有 2.5 個信箱移入資料庫。如果每個信箱的平均大小為 5.4GB (包括啟用 [單一項目搜索] 後保留 14 天的刪除項目)，則每個資料庫每天所產生的移動交易記錄數量，將會是 2.5 * 5.4GB / 1024 = 13,888 個信箱移動交易記錄檔。

從備份/還原的角度來看，我們必須考慮到我們所要使用的備份架構類型。在規劃每種備份解決方案的容量時，都應就信箱所產生的交易記錄檔數量，再額外加上建議的天數。藉由預留額外空間，即使發生多項錯誤，也無須擔心空間不足的情況。如需交易記錄截斷的詳細資訊，請參閱了解備份、還原及災害復原。

  交易記錄截斷 建議的備份失敗保護
每日完整備份 每日 3 天
每週完整備份/每日增量備份 每日 3 天
每週完整備份/每日差異備份 每週 7 天
隔週完整備份/每日增量備份 每日 3 天
Exchange 原生資料保護 不需要記錄檔 3 天

當然，您還可能需要考慮其他的狀況。比方說，假設您打算將資料庫可用性群組 (DAG) 跨部署在兩個資料中心，並且只有在兩個資料中心間的網路連線正常運作，以及資料庫複本狀態良好的情況下，才會產生交易記錄檔。如果您知道 WAN 連線一旦發生中斷，至少需要 5 天的時間才能修復，則您在設定備份失敗保護時，就應將這點列入考量，同時加以調整。

以我們的案例為例，假設我們在發生截斷的問題時，需要 3 天的時間才能回復正常運作。這就表示我們需要 9,750 / 1024 * 3 = 28.5GB 的磁碟空間，儲存信箱所產生的交易紀錄檔。

此外，我們也必須將整個星期內，信箱移動事件所需的磁碟空間一併計算進去：13,888 / 1014 * 7 天 = 94.9GB 的磁碟空間，以備信箱移動作業之用。

整體而言，這代表每個資料庫都需要 123GB 的磁碟空間儲存交易記錄。另外也應將額外的資料負荷考慮進去，以防任何意料之外的情況發生，因此交易記錄檔將會需要：123GB * 1.2 = 148GB 的磁碟空間。

如果要為交易記錄部署專屬 LUN，那麼這個 LUN 的大小，就不應該是 150GB，因為這在發生備份錯誤或出現超量的信箱移動時，將會用盡所有的磁碟空間。一般來說，在您佈建 LUN 時，應該確保 LUN 只用到 80% 的磁碟容量。算法是：

LUN 大小 = [預計的磁碟空間使用量] / (1 – [所需要的可用空間百分比])

LUN 大小 = 148GB / (1 – .2) = 148GB / .8 = 185GB 的 LUN 空間做為交易記錄檔專屬磁碟區

假如您要將交易記錄檔部署到資料庫所使用的 LUN 上，只要將交易記錄檔所需的磁碟空間，和 [預計的磁碟空間使用量] 兩個值相加即可。

如何預防用盡所有的交易記錄磁碟空間？

首要之務是您必須為您的環境訂定基準，算出在一般情況下每天的記錄檔產生率。此外還須設置一套監視系統，以便在警告出現時能夠立即採取行動。這套監視系統應監視下列狀況：

  1. 交易記錄 LUN 的磁碟空間。訂定幾個臨界值與各種不同的警告機制。不過，您可別設定在磁碟空間已用掉 90% 時，才發出第一道警告。如果您知道所產生的記錄檔常規數量基準，就可以依此設定回報的臨界值，好比在超過基準 20% 時通知您。
  2. 監視備份是否成功地完成 (假使您不是使用 Exchange 原生資料保護)。千萬不要設定在磁碟空間快用完時，才發出第一道備份失敗警示。
  3. 監視應用程式記錄檔中的截斷事件。
  4. 監視您的資料庫複本的狀態是否良好。

當交易記錄檔數量異常增加時，該怎麼辦？

我的朋友 Mike Lagase 曾經寫過一篇文章，告訴大家在發生這種情況時該如何找出問題並加以解決 (https://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (可能為英文網頁)，請注意他的這篇文章是針對 Exchange 2007，所以其中有某些工具或建議可能已經不適用於 Exchange 2010)。除了 Mike 提到的步驟之外，您也可以在 Exchange 2010 中利用下列作法來判斷交易記錄檔增加的原因 (感謝 Todd Luttinen 幫我們整理出這份清單)：

  1. 您可以利用存放區使用量統計 Cmdlet (get-StoreUsageStatistics 與 DigestCategory = ‘LogBytes’) 找出產生大量記錄檔位元組數的信箱。請注意，當記錄檔的位元組不是由信箱擁有者所產生，或該作業是代表用戶端 (例如 CopyOnWrite) 執行，而未包含系統服務產生的記錄檔位元組時 (回報事件識別碼 9826)，這個方法可能不管用。這個方法會提供過去 10 分鐘內，產生記錄檔數量最多的前幾名信箱活動 (最多可以涵蓋 6 個樣本在過去一小時內的活動)。以下將告訴您如何利用存放區使用量統計資料，找出過去一小時內，產生最多記錄檔位元組數的信箱：

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*

    MailboxGuid 樣本識別碼 取樣時間 記錄檔數量 記錄檔位元組數
    c007c87a-e030-4414-b741-9cf61e88b9de 5 11/7/2011 4:25:05 PM 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 11/7/2011 4:35:05 PM 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 11/7/2011 4:45:06 PM 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 11/7/2011 4:55:06 PM 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 11/7/2011 5:05:06 PM 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 11/7/2011 5:15:06 PM 247 209987

  2. 管理用戶端也會產生應用程式事件 (事件識別碼 9826)。下列統計資料代表了 2 小時內的活動：

    自 <日期/時間> 起，服務 <name> 在伺服器上執行了這項活動：
    RPC 作業數：24168。
    讀取的資料庫頁數：1329 (其中有 629 頁為預先讀取)。
    更新的資料庫頁數：12418 (其中有 11555 頁為再次更新)。
    產生的資料庫記錄數：13906 筆。
    產生的資料庫記錄位元組數：660331。
    在伺服器中的時間：19142 毫秒。
    在使用者模式中的時間：6100 毫秒。
    在核心模式中的時間：63 毫秒。

  3. 效能監視器計數器「MSExchangeIS Client(*)\JET Log Record Bytes/sec」可用來找出造成記錄檔增加的客戶端類型。

相信現在大家應該都已經知道，唯有足夠的容量，才能確保資料庫的可用性不受影響。希望上述資訊對您的交易記錄容量規劃有所幫助。

Ross Smith IV
專案總經理
Exchange 客戶經驗小組

這是翻譯後的部落格文章。英文原文請參閱 Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted