淺談Exchange Server郵件存儲系統---技巧篇
作者/喻勇
導讀：
在瞭解了Exchange Server Store的工作方式和特點以後，我們接下來介紹一些郵件存儲系統的管理技巧。管理員在掌握了原理以後會對這些技巧有更深刻地認識，在實際工作中做到胸有成竹、遊刃有餘。
Exchange存儲系統軟硬件的選擇和設計
我們首先來看一下如何爲Exchange Server的數據庫文件和Log文件選擇適當的磁盤硬件。
根據上一期的文章中所闡述的Log文件對數據庫恢復的作用，我們得知，當數據庫損壞時，通過還原磁帶上的備份和利用系統現有的日誌文件，可以把數據庫恢復到發生問題之前的一個狀態。因此，數據庫文件和日誌文件需要存放在不同的物理磁盤之上，以防止磁盤硬件故障導致數據庫和日誌同時損壞。微軟的文檔中明確的指出，在存在有效備份的前提之下，數據庫或日誌兩者中的任何一個發生損壞，都是可以恢復的。但是如果數據庫和日誌同時損壞，就只能通過還原備份來恢復到備份時刻的狀態了。
通常企業中重要的服務器存儲系統一般都採用通過硬件系統來實現的RAID陣列。 常用的RAID系統有RAID 5和RAID 1。這兩種的系統特點如下：
RAID 5：向陣列中的磁盤寫數據，奇偶校驗數據存放在陣列中的各個盤上，允許單個磁盤出錯。RAID 5也是以數據的校驗位來保證數據的安全，但它不是以單獨硬盤來存放數據的校驗位，而是將數據段的校驗位交互存放於各個硬盤上。這樣任何一個硬盤損壞，都可以根據其它硬盤上的校驗位來重建損壞的數據。硬盤的利用率爲（n-1/n）%。
RAID1 把磁盤陣列中的硬盤分成相同的兩組，互爲鏡像，當任一磁盤介質出現故障時，可以利用其鏡像上的數據恢復，從而提高系統的容錯能力。對數據的操作仍採用分塊後並行傳輸方式。所以RAID 1不僅提高了讀寫速度，也加強系統的可靠性。但其缺點是硬盤的利用率低，冗餘度爲50％。
從上述的特點來看，RAID 5偏重於數據的安全性；RAID 1（鏡像磁盤）在數據的安全得到保障的前提之下，強調了讀寫速度。
下圖是微軟推薦的Exchange Store系統存儲硬件需求。
從中我們可以看出來，數據庫文件（edb文件和stm文件）被置於RAID 5的系統之上；Log文件的存放是採用了每一個Storage Group一套RAID 1的策略。
微軟這樣的設計，是爲了充分的提升Exchange Store的性能。對於數據庫文件，這些文件的尺寸往往非常的大，並且在日常的運行過程中，需要被非常頻繁的讀寫。從安全的角度考慮，數據庫文件的重要性要遠遠大過日誌文件。因此，採用RAID 5系統保存數據文件，可以最大限度的保證文件的數據安全：在頻繁的讀寫時，能通過校驗位來保證數據不會發生錯誤；在磁盤硬件故障發生時，能夠使系統不受影響。
對於日誌文件，請讀者先回憶一下上一期中我們談到的日誌文件的作用：使內存中的事務儘快的寫入到硬盤中。Exchange的日誌文件，在不發生從備份磁帶恢復的情況之下，終其一生，只會被寫入一次，讀取一次。寫入的時候，是Exchange Server把內存中的數據寫入到以5MB爲單位的日誌文件中，讀取的時候，是Exchange Server把日誌中的內容寫入數據庫時發生的。因此，我們可以發現，對於保存日誌文件的磁盤系統，它的讀寫壓力並不是非常的大，但是要求有非常快的寫入速度。非常快的寫入速度由兩點來得到保證：第一，採用具有較快寫入速度的RAID 1系統（相對於RAID 5，不需要計算校驗位，這節省了大量的時間）；第二，每一個Storage Group獨佔一個RAID 1系統（既該RAID 1陣列只用來保存特定的Storage Group的日誌文件，別無它用），這樣做，我們就把磁盤上的碎片數量降低到了最小的限度。理想情況下，日誌文件每個扇區都是緊挨着的，磁盤在寫數據時，不需要因爲磁盤碎片的緣故而重新定位磁頭，這最大的提高了寫入的性能。
在確定了磁盤的類型以後，我們需要爲選用什麼容量的磁盤進行規劃。存放數據庫文件的RAID 5系統的磁盤空間容量由實際的郵箱數量和郵箱的大小決定。但是，需要在這個基礎留有一定的空餘空間。我們以300個用戶的企業爲例，每個用戶的郵箱大小是100M。理論上，郵箱Store的空間佔用量上限爲300*100M，也就是30GB。其實不然，我們還需要考慮如下的因素：
第一：Delete Item的保留時間。一般在Exchange Server上，我們都會設定刪除的郵件在服務器上保留多少時間（Store->Limit->Deletion Settings）。這樣做，可以方便用戶把誤刪除的郵件恢復回來。Exchange Server的備份結構決定了恢復單獨一封郵件是非常困難的，因此，設定Delete Item保留時間，有助於恢復誤刪除的信息。這個時間一般設定在15天到30天左右。我們需要注意，這樣的設定一旦開啓，所有刪除掉的郵件都不會在數據庫裏馬上被清除掉，因此這項設定會佔用一定的磁盤空間。如果設定Delete Item的保留時間爲15天，我們需要估算每個用戶在這兩週的時間內刪除郵件的數量和尺寸，來做進一步的規劃。如果設定爲15天，保守的情況下，刪除郵件數量是郵箱的30%至50%。通常這樣的估算是不準確的，如果我們想掌握服務器上每一個郵箱的動態，可以使用一個名爲“Quest Reports”的產品，這個基於網頁的程序會給管理員提供每一個郵箱容量的詳細動態報告。該公司的網址是：http://www.quest.com/messagestats/
第二：數據庫維護時所需要的空間。在我們進行Exchange Server數據庫的離線碎片（Offline defrag）整理時，對於一個大小爲20GB的數據庫文件（edb文件加上stm文件），我們需要額外的20GB左右空間來存放整理過碎片的數據庫文件。另外，當需要進行數據庫修復時，通常我們都會在服務器上做一個備份，這些空間，也是需要考慮的。
因此，存放數據庫文件的RAID 5系統的容量，一般是郵箱數*用戶數計算出來的容量的1.5至2倍。
日誌文件的磁盤空間大小，由進行全備份的週期決定（在進行全備份時，系統會自動清除日誌文件）。如果企業每週進行一次全備份，那麼日誌文件磁盤的空間至少要能容納一週之內產生日誌文件（考慮到備份可能失敗，磁帶機故障等意外因素，這個容量還需要留有餘地）。通常情況下，我們可以採用18GB的SCSI磁盤組成鏡像陣列，然後根據日誌文件的增長速度，來動態的調整全備份的時間。
存儲引擎的性能檢測和優化
作爲管理員，我們需要密切的監控Exchange Server Store的性能狀態。下面的一些性能計數器是我們需要時刻關注的：
|
MSExchangeIS/Active User Count |
|
MSExchangeIS/RPC Averaged Latency MSExchangeIS/RPC Packets/sec MSExchangeIS/RPC Requests |
對RPC Averaged Latency有影響的因素很多。執行備份、在線碎片整理、防病毒軟件掃描數據庫等等都會使RPC Averaged Latency的值升高。另外，值得注意的是，網絡環境的不正確配置，也會引起問題。筆者曾遇到過由於交換機端口的速度與Exchange Server上的網卡速度不匹配而引起的嚴重性能問題。詳細的情況是這樣的，客戶郵件系統的性能突然大幅度的下降，RPC Averaged Latency的值高達5位數，所有用戶都不能打開郵箱。在排除Exchange和Windows的問題後，我們從客戶處瞭解到，他們前一天更換了與Exchange Server相連的交換機。按理說，Exchange Server是應用層的軟件，它不會也不應該對數據鏈路層的設備有任何的依賴。但是查過微軟的知識庫以後，我們找到這了這篇文章：“Poor Performance When Network Adapter Is Set to Auto Sense”，文章的知識庫號碼爲330343。文中提到，對於Exchange Server，如果網卡或者交換機端口設置爲自動檢測速度，這可能會造成嚴重的性能問題。首先查看Exchange Server，其網卡的設定爲100M 全雙工，符合微軟的要求；再連接到交換機上察看，發現交換機上跟Exchange Server網卡相連的那個端口，被設定爲Auto即自動檢測速度，當前的連接情況爲100M 半雙工。改爲固定的100M全雙工設定以後，故障立刻消失，RPC Averaged Latency的值恢復到了20以下，用戶收發郵件都沒有問題了。
事後我們分析，對於Exchange Server的系統，有可能微軟在傳送RPC信息時，使用了一些特殊格式的數據包，因此對網絡鏈路有較高的要求。交換機一般都是上電之後直接使用，對它的設定往往很容易被管理員們所忽略。
|
MSExchangeIS/VM Largest Block Size MSExchangeIS/VM Total Free Blocks MSExchangeIS/VM Total Large Free Block Bytes |
Exchange Server在運行過程中，會頻繁的在它所擁有的2GB用戶地址空間中分配和釋放內存。這樣會引起內存地址空間的“碎片”：內存地址中的空餘的空間變得不連續。上述的四個計數器中，VM Largest Block Size表示用戶地址空間中最大的連續空餘內存塊；VM Total 16MB Free Blocks表示尺寸在16MB以上的連續空餘內存塊的數目；VM Total Free Blocks表示總的空餘內存塊的數量；VM Total Large Free Block Bytes表示空餘內存的總數量。當VM Largest Block Size的數量小於32M時，事件察看器中會記錄下編號爲9582 的Warning日誌；當VM Total 16MB Free Blocks爲零也就是最大可分配內存空間小於16MB時，事件察看器中會記錄下編號爲9582 的Error日誌。
|
Source: MSExchangeIS ID: 9582 Type: Warning/Error Description: The virtual memory necessary to run your Exchange server is fragmented in such a way that performance may be affected. It is highly recommended that you restart all Exchange services to correct this issue. |
對於這類問題，大家可以參考微軟的知識庫文檔“Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000”，其文檔代號爲325044。這篇文章詳細地分析了虛擬內存碎片產生的原因和應對辦法。
爲了滿足服務器軟件對內存的要求，微軟公司的Windows 2000 Advanced Server和Data Canter版本的操作系統支持把用戶地址空間擴大爲3GB，這樣可以有效的緩解虛擬內存碎片的問題。該項功能需要在系統分區的boot.ini中做一定的修改纔可以開啓，具體的操作方法請參考微軟文檔“A Description of the 4 GB RAM Tuning Feature and the Physical Address Extension Switch”其文章代號爲291988。
對於Exchange 2000 Server，當服務器安裝了1GB以上的RAM時，微軟推薦開啓操作系統的3GB開關，否則可能會有性能上的問題。參考文檔：
266096 Exchange requires /3GB switch with more than 1 GB RAM
328882 Exchange memory use and the /3GB switch
Exchange Server Store性能優化的建議
1. 確保Exchange Server的網卡和交換機端口設置正確。
2. 有1GB以上物理內存的服務器要安裝Windows 2000 Advanced Server版並在開啓boot.ini中開啓/3GB開關。
3. 需要補充的是，在可能的情況下，要儘量少的創建Storage Group。上一期文章中，我們知道，每一個Storage Group，都對應於一個ESE數據庫引擎的實例。在store.exe中，每生成一個ESE數據庫引擎的實例，都會消耗10M的內存空間。
數據庫碎片整理的作用和注意事項
運行中的Exchange Server會根據管理員指定的時間在後臺不斷地進行在線碎片整理（Online Defrag）。在線碎片整理主要執行如下的操作：
1. 通過查詢活動目錄來確定Store中是否有被刪除的郵箱。
2. 物理的刪除所有超過保留時間的郵件和郵箱。
3. 執行在線碎片整理。
對於第一項操作，Exchange Server會向活動目錄發起查詢，以確保活動目錄中的用戶信息和Exchange Store中保存的郵箱信息是同步的，對於刪除的郵箱，Exchange Server會作特殊的標記。這項操作不會對Exchange Server帶來太多的額外負擔，但是對活動目錄的域控制器卻有一定的壓力。一般我們是在晚上進行在線碎片整理的操作，所以此時活動目錄的負載不會有什麼問題，但如果對於一些大型的跨國企業，其活動目錄的域控制器往往要服務於各時區的用戶時，在線碎片整理的時間需要認真地調整以避免給用戶帶來影響。
第二和第三項操作會對Exchange Server本身帶來一定的負載，主要是一些密集的磁盤操作。在線碎片整理期間，用戶訪問郵箱的速度會明顯的變慢。當Exchange Server的備份和在線碎片整理的時間發生衝突時，在線碎片整理會被終止並直到備份完成才能得以恢復。關於在線碎片整理的詳細細節，請參考微軟知識庫文檔“Understanding Performance and Scalability Characteristics of Exchange 2000 MDB Online Maintenance”，其文檔代號爲271222。
正常情況下，在線碎片整理會在管理員規定的時間停止，並在事件日誌中記下如下的內容
|
Event: 1221 Type: Information Category: General Description: The database has nnn megabytes of free space after online defragmentation has terminated. |
對於離線碎片整理，我們通常按照如下的流程：
1. 在進行離線碎片整理之前，對所操作的Store進行全備份
2. Dismount Store
3. 使用eseutil /mh確認edb和stm文件是“Clean shutdown”（在上期中有詳細的論述）
4. 執行如下的命令來進行碎片整理
|
C:/Program Files/Exchsrvr/BIN>eseutil /d /tX:/Exchsrvr/Mdbdata/SG1MS1_temp.edb /o /p <回車> |
Initiating DEFRAGMENTATION mode...
Streaming File: F:/Exchsrvr/Mdbdata/SG1MS1.STM
Temp. Database: F:/Exchsrvr/Mdbdata/SG1MS1_temp.edb
Temp. Streaming File: F:/Exchsrvr/Mdbdata/SG1MS1_temp.STM
Defragmentation Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|-----|-----|-----|-----|-----|-----|------|------|------|------|
.................................................................................
Note:
It is REQUIRED that you immediately perform a full backup of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the state it was in at the time of that backup.
Operation completed successfully in 13.110 seconds.
碎片整理的實際時間取決於數據庫文件的大小，在Exchange 2000中，一般一小時可以處理7~10GB的數據。在碎片整理完成後，系統會根據制定的文件名生成兩個不含碎片的edb和stm文件。
5. 在把新的數據庫文件Mount之前，需要確保其完整性，我們要執行如下的命令
C:/Program Files/Exchsrvr/BIN>eseutil /g X:/Exchsrvr/Mdbdata/SG1MS1_temp.edb /sX:/exchsrvr/mdbdata/SG1MS1_temp.stm <回車>
Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0
Initiating INTEGRITY mode...
Database: priv1.edb
Streaming File: priv1.stm
Temp. Database: TEMPINTEG3976.EDB
Checking database integrity.
Scanning Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|-----|-----|-----|-----|-----|-----|------|------|------|------|
.................................................................................
Integrity check successful.
Operation completed successfully in 9.62 seconds.
此項操作也需要較長的時間，一般的速度是10GB每小時。
6. 文件改名。把舊的edb文件和stm文件從mdbdata文件夾中移走。把執行過碎片整理的臨時文件改爲同舊的edb文件和stm文件相同的名字。然後Mount數據庫。
7. 如果Mount數據庫失敗，最快的恢復辦法就是把舊的edb文件和stm文件再複製到mdbdata文件夾。Defrag過程中，舊的edb文件和stm文件沒有被更改，即使defrag失敗，也可以恢復到defrag之前的狀態。
關於碎片整理得更多細節，我們可以參考下面的文檔：
192185 XADM: How to Defragment with the ESEUTIL Utility
如果避免Exchange Server的數據庫文件損壞
對於數據庫損壞的問題，防患於未然要遠遠比事後亡羊補牢來的有效。數據庫的損壞一般可以分爲物理損壞和邏輯損壞。
物理損壞往往是由磁盤介質、控制卡等硬件設備的故障引起的。這種類型的損壞都會引起數據丟失，唯一的解決辦法就是從備份的磁帶進行恢復。
Exchange Server爲了確保數據的一致性，會在向數據庫寫入內容時（寫入的單位是4KB的頁面），把根據數據內容計算得出的校驗和跟實際的數據一併寫入。當讀取時，系統會重新計算校驗和，並跟保存的校驗和進行比較，如果這兩個值不同，說明讀出的數據和當初寫入的數據相比，已經發生了變化。這種變化往往是由磁盤故障、控制器總線傳輸故障等引起的。爲了排除干擾因素，當校驗和不匹配的情況出現時，Exchange Server會再次到磁盤上去讀取那個頁面，如此循環16次。如果連續讀取16次，校驗和跟原始的值仍然無法匹配，Exchange Server就會認爲數據庫已經發生了物理損壞。在事件日誌中，會有如下的內容被記錄下來：
Event ID: 23
Type: Error
Category: Database Page Cache
Description: MSExchangeIS ((455)) Direct read found corrupted page error -1018 ((1:251563) (0-2295758), 251563 379225672 381322824). Please restore the database from a previous backup.
另外，當事件日誌的錯誤描述中出現如下的代碼，基本上也可以認定數據庫發生了物理損壞：
-1018 (JET_errReadVerifyFailure)
-1022 (JET_errDiskIO)
The hardware, device driver, or operating system is returning errors.
-510 JET_errLogWriteFail
The log files are out of disk space or there is a hardware failure with the log file disk.
數據庫的物理損壞往往會帶來數據丟失和Exchange Server停機等等損失。我們可以採取下面的一些建議來避免物理損壞的發生：
1. 採用高質量的磁盤和磁盤控制系統，對硬件RAID系統進行正確的配置。
2. 不要使用文件級別的工具或防病毒軟件掃描數據庫文件和日誌文件。
3. 避免使用磁盤控制卡上的寫入緩存（Write-back caching）。
4. 定期地進行全備份。全備份一方面保證了數據的安全，另一方面也能及早地發現數據庫的物理損壞。在執行全備份時，備份程序會把數據庫的每一個頁面讀取出來並重新計算校驗和，如果有損壞的頁面存在，管理員可以及早的發現問題並採取行動。
當物理損壞發生時，我們可以採取如下的步驟來進行恢復：
1. 如果有全備份，一定要先從備份進行恢復。
2. 在沒有備份的情況下，可以使用Eseutil /p來進行手工的修復。但這是不推薦的做法，從備份恢復是最好的解決辦法。
關於數據庫的物理損壞，更詳細的內容請參考微軟知識庫文檔“Understanding and analyzing -1018, -1019, and -1022 Exchange database errors”，這篇文章的代號是314917。
另外一種常見的數據庫損壞是邏輯損壞。數據庫的內容本身沒有問題，但是一些內部的視圖、關聯發生問題時，就會發生邏輯損壞。邏輯損壞的症狀往往表現爲：大部分用戶使用正常，某些用戶在點擊特定的郵箱文件夾或者郵件時，會發生死機等現象。對於這種故障，一般可以使用ISINTEG命令來進行修復。
關於Exchange Server數據庫的更多內容，大家可以閱讀微軟知識庫文檔“Overview of Exchange Server Database Architecture and Database Engine”這篇文章的代號是217987。