浅谈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的性能状态。下面的一些性能计数器是我们需要时刻关注的：
上面这两个计数器，反映了当前服务器上的活动用户数和登陆用户数。一般性，Active User Count总是小于User Count。由于Exchange Server内部使用了一些系统邮箱用来进行服务器间通信，因此即使没有任何使用者在线，User Count也总是维持在20左右，这是正常的。
上面四个计数器，反映了Exchange Server Store的RPC处理响应能力。这几个计数器，最能体现当前服务器的负载和响应速度。RPC Operations/sec、RPC Packets/sec分别表示服务器每秒接收到的RPC请求（所有Outlook MAPI客户端连接在读取、发送邮件时都会向服务器发送大量的RPC请求）。RPC Requests表示Exchange Server当前正在处理的请求，一般情况下，Exchange Server最多能同时处理100个请求，因此如果这个计数器超过了100，Exchange Server将会有严重的性能问题。最后一个也是最重要的一个，RPC Averaged Latency，这个计数器表示当前时刻之前的1024个RPC请求的平均响应时间，这个时间的单位是毫秒，一般性，这个计数器应该小于20。如果该计数器大于100并且持续较长的时间，客户端Outlook的响应速度将变得很慢甚至死机。
对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信息时，使用了一些特殊格式的数据包，因此对网络链路有较高的要求。交换机一般都是上电之后直接使用，对它的设定往往很容易被管理员们所忽略。
这四个计数器跟Exchange Server Store进程的内存使用情况有关。我们都知道，在Exchange Server上，store.exe进程往往是内存消耗的大户，ESE数据库引擎为了提高它的性能，需要申请大量的内存作为其缓存空间，在有300个以上用户的Exchange Server系统上，store.exe进程的物理内存占用量一般都在1GB以上。在Windows操作系统中，内存分为物理内存和虚拟内存。物理内存指机器上安装的内存条；虚拟内存指CPU可以寻址的内存范围。对于Windows 2000来说，物理内存的大小由安装的内存多少决定，虚拟内存默认情况下都是4GB。（关于Windows 2000内存的更进一步知识，读者可以参考Inside Windows 2000这本书的第六章：内存管理。）如下图的左面部分所显示，每一个进程都有4GB的地址空间，默认情况下，2GB为操作系统所有，2GB为应用程序使用。
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日志。
这种情况出现，说明Exchange Server的虚拟地址空间中已经存在了大量的碎片，由于无法满足内存的分配，Exchange Server的性能和稳定性都会出现问题。
对于这类问题，大家可以参考微软的知识库文档“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。
正常情况下，在线碎片整理会在管理员规定的时间停止，并在事件日志中记下如下的内容
这表示Exchange Server在线碎片整理过程中发现并计算出数据库中含有的碎片空间的大小。在线碎片整理只会标示出碎片的位置并计算其空间，并不会物理的移动数据页面以消除这些碎片空间。如果需要物理的消除这些碎片空间，需要执行离线碎片整理。当上面事件中显示的碎片空间达到一定的比例时（占数据库文件的10%~15%），我们需要执行离线碎片整理。
对于离线碎片整理，我们通常按照如下的流程：
1.在进行离线碎片整理之前，对所操作的Store进行全备份
2.Dismount Store
3.使用eseutil /mh确认edb和stm文件是“Clean shutdown”（在上期中有详细的论述）
4.执行如下的命令来进行碎片整理
命令会有如下的输出：
碎片整理的实际时间取决于数据库文件的大小，在Exchange 2000中，一般一小时可以处理7~10GB的数据。在碎片整理完成后，系统会根据制定的文件名生成两个不含碎片的edb和stm文件。
5.在把新的数据库文件Mount之前，需要确保其完整性，我们要执行如下的命令
其输出如下：
此项操作也需要较长的时间，一般的速度是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就会认为数据库已经发生了物理损坏。在事件日志中，会有如下的内容被记录下来：
另外，当事件日志的错误描述中出现如下的代码，基本上也可以认定数据库发生了物理损坏：
数据库的物理损坏往往会带来数据丢失和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。
在了解了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\User Count |
上面这两个计数器，反映了当前服务器上的活动用户数和登陆用户数。一般性，Active User Count总是小于User Count。由于Exchange Server内部使用了一些系统邮箱用来进行服务器间通信，因此即使没有任何使用者在线，User Count也总是维持在20左右，这是正常的。
| MSExchangeIS\RPC Averaged Latency MSExchangeIS\RPC Operations/sec MSExchangeIS\RPC Packets/sec MSExchangeIS\RPC Requests |
上面四个计数器，反映了Exchange Server Store的RPC处理响应能力。这几个计数器，最能体现当前服务器的负载和响应速度。RPC Operations/sec、RPC Packets/sec分别表示服务器每秒接收到的RPC请求（所有Outlook MAPI客户端连接在读取、发送邮件时都会向服务器发送大量的RPC请求）。RPC Requests表示Exchange Server当前正在处理的请求，一般情况下，Exchange Server最多能同时处理100个请求，因此如果这个计数器超过了100，Exchange Server将会有严重的性能问题。最后一个也是最重要的一个，RPC Averaged Latency，这个计数器表示当前时刻之前的1024个RPC请求的平均响应时间，这个时间的单位是毫秒，一般性，这个计数器应该小于20。如果该计数器大于100并且持续较长的时间，客户端Outlook的响应速度将变得很慢甚至死机。
对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 16MB Free Blocks MSExchangeIS\VM Total Free Blocks MSExchangeIS\VM Total Large Free Block Bytes |
这四个计数器跟Exchange Server Store进程的内存使用情况有关。我们都知道，在Exchange Server上，store.exe进程往往是内存消耗的大户，ESE数据库引擎为了提高它的性能，需要申请大量的内存作为其缓存空间，在有300个以上用户的Exchange Server系统上，store.exe进程的物理内存占用量一般都在1GB以上。在Windows操作系统中，内存分为物理内存和虚拟内存。物理内存指机器上安装的内存条；虚拟内存指CPU可以寻址的内存范围。对于Windows 2000来说，物理内存的大小由安装的内存多少决定，虚拟内存默认情况下都是4GB。（关于Windows 2000内存的更进一步知识，读者可以参考Inside Windows 2000这本书的第六章：内存管理。）如下图的左面部分所显示，每一个进程都有4GB的地址空间，默认情况下，2GB为操作系统所有，2GB为应用程序使用。
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 Category: Performance 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. |
这种情况出现，说明Exchange Server的虚拟地址空间中已经存在了大量的碎片，由于无法满足内存的分配，Exchange Server的性能和稳定性都会出现问题。
对于这类问题，大家可以参考微软的知识库文档“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 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。