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。
