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
Source: MSExchangeIS Private
Type: Information
Category: General
Description: The database has nnn megabytes of free space after online defragmentation has terminated.
這表示Exchange Server在線碎片整理過程中發現并計算出數據庫中含有的碎片空間的大小。在線碎片整理只會標示出碎片的位置并計算其空間，并不會物理的移動數據頁面以消除這些碎片空間。如果需要物理的消除這些碎片空間，需要執行離線碎片整理。當上面事件中顯示的碎片空間達到一定的比例時(占數據庫文件的10%~15%)，我們需要執行離線碎片整理。
對于離線碎片整理，我們通常按照如下的流程:
1. 在進行離線碎片整理之前，對所操作的Store進行全備份
2. Dismount Store
3. 使用eseutil /mh確認edb和stm文件是“Clean shutdown”(在上期中有詳細的論述)
4. 執行如下的命令來進行碎片整理
C:\Program Files\Exchsrvr\BIN>eseutil /d
X:\Exchsrvr\Mdbdata\SG1MS1.edb
/tX:\Exchsrvr\Mdbdata\SG1MS1_temp.edb /o /p <回車>
命令會有如下的輸出:
Initiating DEFRAGMENTATION mode...
Database: F:\Exchsrvr\Mdbdata\SG1MS1.edb
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
Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.
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
Source: EDB
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)
The data read from disk is not the same as the data that was written to disk.
-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。
