配置 Exchange 后端存储的最佳实践

 

上一次修改主题： 2006-05-09

有几种推荐方法可最大程度地实现后端服务器上的 Exchange 数据的可用性：

• 存储组配置 规划存储组和数据库配置，最大限度地实现性能和可恢复性。
• 邮箱服务器存储大小 规划数据库大小以确保提供足够的性能和可恢复性。
• 后端服务器分区 在不同的磁盘上存储 Windows 操作系统文件、Exchange 应用程序文件、Exchange 数据库文件和事务日志文件，可提高容错能力并优化恢复能力。
• Exchange 数据存储 在磁盘上实现 RAID 解决方案，以便与每个磁盘上数据的类型相符。
• 硬盘空间 确保提供足够的磁盘空间，以保证实现性能和可恢复性。
• 磁盘性能和 I/0 吞吐量 将硬盘性能视为存储解决方案的一部分。
• 磁盘碎片 使用联机碎片整理对磁盘进行碎片整理，并在必要时执行脱机碎片整理。
• 虚拟内存优化 考虑优化服务器，以确保有效而可靠的邮件传输。

还有其他一些方法可增强 Exchange 2003 后端服务器的可用性和性能。有关优化 Exchange 2003 后端服务器的信息，请参阅 Exchange Server 2003 Performance and Scalability Guide（英文）。

存储组配置

Exchange 存储使用两种类型的数据库：邮箱存储和公用文件夹存储。这些存储组成存储组。存储组中的所有数据库都共享一组事务日志文件、一个备份日程安排以及一组与日志记录和备份相关的设置。

在确定存储解决方案应该支持多少存储组和数据库时，灾难恢复策略起着重要的作用。具体地说，恢复规划应该体现公司对还原时间的要求。正是这方面的要求决定了您的存储配置。配置存储组的方式取决于所使用的 Exchange 2003 的版本：

• 如果使用的是 Exchange Server 2003 标准版，则每个 Exchange 服务器可以有一个存储组，其中包含一个邮箱存储和一个公用文件夹存储。
• 如果使用的是 Exchange Server 2003 企业版，则每个服务器可以有多达四个存储组，其中每个存储组可以包含多达五个数据库（邮箱存储或公用文件夹存储）。

注意：
请考虑对存储组、邮箱存储和公用文件夹存储的名称使用说明性命名约定。使用说明性命名约定有助于进行维护和排除故障。

无论是使用 Exchange Server 2003 标准版，还是使用 Exchange Server 2003 企业版，都可以创建一个恢复存储组以及其他存储组。使用恢复存储组可以在从备份还原数据时恢复邮箱数据。有关恢复存储组的信息，请参阅 Using Exchange Server 2003 Recovery Storage Groups（英文）。

邮箱存储

如果使用的是 Exchange Server 2003 企业版，则可以使用多个邮箱存储来提高 Exchange 组织的可靠性和可恢复性。如果将用户分布在多个邮箱存储上，则丢失一个存储只会影响一部分用户而不是整个组织。此外，减少每个存储的邮箱数，会减少从备份恢复已损坏存储所需的时间。

注意：
通常，在多个数据库之间分布用户时系统所使用的资源，要比将所有用户放在一个数据库上使用的资源多。不过，由于可能会减少恢复单个邮箱存储所需的时间，因此使用多个存储所带来的优点通常超过了资源成本增加所带来的缺点。有关磁盘性能的详细信息，请参阅本主题后面的“磁盘性能和 I/O 吞吐量”。

公用文件夹存储

若要在多个服务器上散布公用文件夹，可以使用多个公用文件夹存储。此外，若要提高系统处理用户通信的能力，可以在若干个服务器上放置同一文件夹的多个副本。如果有多个路由组，则可能需要在多个路由组之间分布文件夹。这使用户能够轻松地访问他们最常使用的文件夹。

邮箱服务器存储大小

在选择邮箱服务器的服务设计选项之前，必须先确定需要存储的数据量。通过精确地确定现有的和计划的邮件数据量，可以相应地设计存储系统，从而不必在部署之后立即扩展。

请使用以下公式计算在一个服务器上可以存储的数据量：

（邮箱数 * 邮箱限制的最大大小）* 调整因素

调整因素（例如，使用 1.5）可以为那些不利于邮箱配额的数据提供额外的空间，其中包括位于已删除邮件保留存储和已删除邮箱保留存储中的邮件。配额使空间使用模式更具可预测性。在没有使用邮箱配额的 Exchange 环境中，启用配额是一个重要考虑因素。而且，创建单独的邮箱数据库以及使用带有不同配额限制的多系统策略，可简化管理过程。

注意：
对于需要大邮箱的用户，可以使用一个或多个无限制的数据库。

可以利用总数据量大致推导出服务器所需的磁盘空间大小。但是，计算此估计值取决于服务器上要驻留多少个邮箱数据库。

备份和还原性能注意事项

在 Exchange 2003 企业版中，对单个数据库的大小没有限制。由于缺少内置限制，所以很难确定服务器规模以及在数据库之间划分数据的方式。因此，若要确定如何调整服务器数据大小以及如何划分这些数据，请先考虑下列因素：

• 还原单个数据库有哪些时间要求？
• 所选的还原机制的速度有多快？

若要阐明此过程，请考虑如下情形：

将一个 SLA（可提供四小时的最长中断时间）与一个备份系统（每小时可备份和还原 75 GB）配合使用。因为进行一次备份平均起来就要进行两次恢复，所以服务器上所有数据的最大大小应是 150 GB。（150 GB 表示在两小时内可以还原的数据量。）

确定最大大小之后，就可以确定如何将 150 GB 分为较小的数据块。因为服务器上的所有用户都位于一个数据库内，所以将所有数据放入一个数据库就没有什么灵活性可言。这个决策不是是否分区的问题，而是要使用多少分区。一种常见的解决方案是，采用服务器的最大数据大小，然后将数据平分到数据库中。例如，可以将 150 GB 数据库分成五个 30 GB 数据库（在一个存储组内，可能的数据库最大数目是五个）。遗憾的是，此解决方案会禁止多个数据库进行并发备份和还原。此解决方案还会禁止装入以测试或修复为目的的其他数据库。一个较好的解决方案是，使用多个存储组（在这种情况下，使用两个存储组，每个存储组有四个数据库），每个数据库应该使用约 20 GB。此解决方案将允许来自不同存储组的两个数据库同时进行备份或还原（假定已经安装了适用的备份硬件）。另外，使用较小的数据库文件大小，可以在卷或服务器之间轻松地移动这些文件。

单实例存储注意事项

规划如何将组邮箱组成邮箱数据库也是十分重要的。由于 Exchange 可以在单个数据库内维护单实例存储，因此工作组用户将保留在同一数据库中（如果可能）。利用单实例存储，可以更快速地还原某些用户组。例如，考虑到银行的货币交易操作所要求的可用性要比其他操作高。以上述 150 GB 服务器为例，创建另一个存储组，使一个数据库仅用于货币交易者的邮箱，这样会加快备份和还原过程。对于关键业务邮箱，还有一个选择是使用卷影复制服务来提供更快的恢复。这样，卷影复制服务硬件要求的成本劣势将降至最低。

对后端服务器进行分区的最佳实践

若要提高容错能力，同时更易于进行故障排除，应该对磁盘进行分区，以便使下列文件位于不同的磁盘上：

• Windows Server 2003 文件
• Exchange 应用程序文件
• Exchange 数据库文件
• Exchange 事务日志文件

通常，以这种方式对硬盘进行分区，可以提高性能并减少需要恢复的数据量。本部分的其余部分会介绍将这些文件分别放在不同磁盘上的优点。

将 Exchange 应用程序文件和 Windows Server 2003 文件放在其各自磁盘上的优点

将 Exchange 应用程序文件和 Windows Server 2003 文件放在其各自磁盘上有如下优点：

• 提高性能 对于 Exchange 2003 服务器而言，有一些显而易见的性能优势。例如，如果应用程序位于一个磁盘上，则服务器可以按任意必要的顺序读取 Windows 文件或 Exchange 文件，而无须移动磁盘驱动器磁头。
• 提高容错能力 单点故障不再是一个问题。例如，如果安装了 Exchange 2003 的磁盘出现故障，Windows Server 2003 可以继续正常运行。

将 Exchange 事务日志文件和数据库文件放在其各自磁盘上的优点

在 Exchange 中，事务日志文件是按顺序访问的，而数据库则是随机访问的。根据一般存储原则，应该将事务日志文件（顺序 I/O）和数据库（随机 I/O）分开，以便最大程度地提高 I/O 性能和容错能力。单独存储按顺序访问的文件，可以使磁盘磁头保持在最合适的位置，以便执行顺序 I/O，从而减少查找数据所需的时间。具体地说，应该将每组事务日志文件移到各自的阵列中，与存储组和数据库分开。

默认情况下，Exchange 在以下文件夹中存储数据库文件和事务日志文件：

驱动器:\Program Files\Exchsrvr\MDBDATA

此文件夹位于安装 Exchange 2003 的同一分区上。

将 Exchange 事务日志文件和数据库文件放在单独的磁盘上有如下优点：

• 更易于管理 Exchange 数据 为每组文件分配不同的驱动器号。如果用各自的驱动器号代表每组文件，将有助于根据灾难恢复方法跟踪必须备份的分区。
• 提高性能 显著提高硬盘 I/O 性能。
• 将灾难的影响降至最低 根据故障类型，将数据库和存储组放在不同的磁盘上可以明显地将数据损失降至最低。例如，如果将 Exchange 数据库和事务日志文件保存到同一物理硬盘，当磁盘出现故障时，只能恢复那些存在于上次备份中的数据。有关详细信息，请参阅 Exchange Server 2003 Disaster Recovery Planning Guide（英文）中的“Considering Locations of Your Transaction Log Files and Database Files”。

下面的表和图说明了具有六个硬盘（包括两个存储组，每个组包含四个数据库）的 Exchange 服务器的可能的分区方案。因为您的 Exchange 服务器上的硬盘和存储组的数目可能不同于此示例，所以，请根据您自己的服务器配置的实际情况应用本例中的逻辑。在下表中，请注意驱动器 E、F、G 和 H 可能指向外部存储设备。

Exchange 硬盘分区方案

磁盘	驱动器配置
硬盘 1	驱动器 C (NTFS) -- Windows 操作系统文件和交换文件。
硬盘 2	驱动器 D (NTFS) -- Exchange 文件和其他服务器应用程序（例如，防病毒软件和资源工具包）。
硬盘 3	驱动器 E (NTFS) -- 存储组 1 的事务日志文件。
硬盘 4	驱动器 F (NTFS) -- 存储组 1 的数据库文件。
硬盘 5	驱动器 G (NTFS) -- 存储组 2 的事务日志文件。
硬盘 6	驱动器 H (NTFS) -- 存储组 2 的数据库文件。

无论您的 Exchange 数据库文件存储在服务器上，还是使用诸如 SAN 这样的高级存储解决方案，都可以采用此部分介绍的分区建议。另外，还应该采用诸如磁盘镜像 (RAID-1) 和具有奇偶校验的磁盘条带化（RAID-5 或 RAID-6，取决于所存储数据的类型）这样的技术。

有关 Exchange 2003 事务日志文件、数据库和存储组的详细信息，请参阅 Exchange Server 2003 Disaster Recovery Planning Guide（英文）中的“Understanding Exchange 2003 Database Technology”。

存储 Exchange 数据

本部分介绍的信息有助于为下列 Exchange 数据类型正确配置位置和 RAID 级别：

• 数据库文件（.edb 和 .stm 文件）
• 事务日志文件
• SMTP 队列目录数据
• 内容索引文件

数据库文件

Exchange 数据库由 RTF 的 .edb 文件和多用途 Internet 邮件扩展 (MIME) 内容的 .stm 文件构成。

.edb 文件存储下列项目：

• 所有 MAPI 邮件
• Store.exe 进程为定位所有邮件而使用的表
• .edb 文件和 .stm 文件的校验和
• 指向 .stm 文件内数据的指针

.stm 文件包含与固有的 Internet 内容一起传送的邮件。由于对这些文件的访问通常是随机的，因此，可以将它们放在同一个磁盘上。

默认情况下，Exchange 在以下文件夹中存储数据库文件：

驱动器:\Program Files\Exchsrvr\MDBDATA

此文件夹位于安装 Exchange 2003 的同一分区上。

数据库文件注意事项

当为这些文件规划存储解决方案时，请实现一种确保可靠性的解决方案。不建议使用 RAID-0 选项。除了可靠性，还要在性能优化 (RAID-1) 和容量优化 (RAID-5) 之间做出选择，以确定存储解决方案。如果可能，请使用 RAID-1（或 RAID-0+1）来存储这些文件。

可以在 RAID-5 阵列上存储公用文件夹，因为公用文件夹中的数据通常只写入一次，却要读取许多次。RAID-5 可提高读取性能。

事务日志文件

存储组的最重要方面是其事务日志。即使只使用默认的“第一个存储组”，也需要考虑事务日志配置，以确保在存储损坏的情况下可以恢复数据。

在标准的 Exchange 事务日志记录中，存储组中的每个存储事务（如创建或修改邮件）都会先写入日志文件，再写入 Exchange 存储。存储组中的所有存储共享一组事务日志。此日志记录过程可确保：在备份间隔期间存储被损坏时仍然会有事务的记录。在许多情况下，恢复已损坏的存储意味着这样的过程：首先从备份还原该存储，再重播任何已备份的日志文件，然后重播最新的日志文件，以恢复在上次备份之后所执行的事务。

如果发生灾难，必须重建服务器，可使用最新的事务日志文件来恢复数据库。如果您有权访问最新备份以及自备份后产生的事务日志文件，则可以恢复所有数据。但是，如果丢失了任何事务日志文件，那么自上次备份以来没有提交到数据库中的数据就会永久丢失。

注意：
有关事务日志如何工作的详细信息，请参阅 Exchange Server 2003 Disaster Recovery Planning Guide（英文）中的“Understanding Exchange 2003 Database Technology”。

默认情况下，Exchange 在以下文件夹中存储事务日志文件：

驱动器:\Program Files\Exchsrvr\MDBDATA

此文件夹位于安装 Exchange 2003 的同一分区上。

事务日志文件注意事项

在规划 Exchange 事务日志文件的位置时，请考虑下列因素：

• 如果将每组事务日志文件放在不同的驱动器上，可以大大提高 Exchange 服务器的性能和容错能力。
• 因为每个存储组都有自己的一组事务日志文件，所以，服务器的专用事务日志驱动器的数目应等于计划的存储组的数目。利用 SAN 解决方案，可以选择一种产品将虚拟化空间轻松地分成单独的虚拟驱动器，供存储组和事务日志文件使用。
• 此外，由于事务日志文件对服务器的运行至关重要，您应该防止驱动器发生故障，理想方法是使用 RAID 进行硬件镜像。建议采用 RAID-0+1 配置（先镜像数据，然后再进行条带化）。

注意：
请将数据库驱动器分布在许多小型计算机系统接口 (SCSI) 通道或控制器上，但将它们配置为一个逻辑驱动器，以便尽量避免 SCSI 总线发生通信饱和。

磁盘配置示例如下：

• C:\ 系统和引导程序（镜像组）
• D:\ 页文件
• E:\ 存储组 1 的事务日志文件（镜像组）
• F:\ 存储组 2 的事务日志文件（镜像组）
• G:\ 两个存储组的数据库文件（配置为具有奇偶校验的硬盘条带化组的多个驱动器）

注意：
下列驱动器应该始终将格式设置为 NTFS：

• 系统分区
• 包含 Exchange 二进制文件的分区
• 包含事务日志文件的分区
• 包含数据库文件的分区
• 包含其他 Exchange 文件的分区

SMTP 队列目录

SMTP 队列目录在简单邮件传输协议 (SMTP) 邮件排队进程中起着重要的作用。SMTP 队列目录存储 SMTP 邮件，直到这些邮件被写入数据库（根据邮件类型，写入公用数据库或私人数据库）或者发送到另一个服务器或连接器。因为 SMTP 排队进程需要执行大量写入操作，所以配置系统以获得最佳性能是十分重要的。

通常，邮件在 SMTP 队列中只存储很短的时间。不过，在某些情况下（尤其是后续进程发生故障时），可能需要 SMTP 队列存储大量数据。因此，SMTP 队列的存储解决方案应该先尽可能完善性能，然后再考虑容量和可靠性。

默认情况下，Exchange 在以下文件夹中存储 SMTP 邮件：

驱动器:\Program Files\Exchsrvr\Mailroot

此文件夹位于安装 Exchange 2003 的同一分区上。在某些情况下（例如，配置桥头服务器时），如果将 Mailroot 文件夹移到其他硬盘或分区上，则可以提高 Exchange 2003 服务器的性能。

SMTP 队列注意事项

在规划 SMTP 队列数据的位置时，请考虑下列因素：

• 不要认为 RAID-0 阵列是 SMTP 队列的最佳存储解决方案。通常，只有在可接受邮件丢失的情况下，才能采用 RAID-0。RAID-1 是一个很好的解决方案，因为它不但具有足够的吞吐量，还提供了一定的可靠性。不过，如果要追求最佳的性能和可靠性，那么为 SMTP 队列使用 RAID-0+1 则堪称额外投资了。
• 在 Exchange 2003 中，现在可以使用 Exchange 系统管理器来更改队列目录的位置。在 Exchange 系统管理器中，此选项可在 SMTP 虚拟服务器对象的“邮件”选项卡中找到。

内容索引文件

在扫描数据库时，内容索引会造成过多的分页操作，以及对内容索引文件的过多写入操作。因此，内容索引文件不应放在与页文件相同的磁盘上（尽管这是默认位置）。因为内容索引文件是随机访问的文件，可以将其放在数据库所在的同一驱动器上（前提是磁盘子系统可以处理这些负载）。

硬盘空间考虑因素

请确保硬盘有足够的容量供 Exchange 服务器使用。硬盘上应该有足够的空间来存储数据库和日志文件。

您的备份可能因为过大而无法还原到原来的位置。例如，每周进行一次常规备份，再加上六天的差异备份，因而还原时需要的磁盘空间可能会超过服务器的可用空间。还原时所需的磁盘空间是否超过可用空间，取决于一周的时间内会生成多少日志文件。例如，除了数据库需要的空间，在一周内生成 2,000 个日志文件的服务器还需要 10 GB 的日志文件空间。

每天进行常规备份可减少还原 Exchange 数据库所需的空间量。之所以所需空间会减少，是因为常规备份会删除截止到您进行备份为止的事务日志文件。如果需要还原 Exchange 数据库，请每天进行常规备份，以确保不必还原一天以上的日志文件。

另外，永远不要使数据库驱动器（包含 .edb 和 .stm 文件的硬盘）的已用空间量超过一半。虽然已用空间量只达到一半的数据库驱动器会有一些磁盘空间没有使用，但从长远的角度来看，这样可以减少服务器停机时间，原因如下：

• 还原数据库的速度比已满的驱动器更快（尤其在文件系统有很多碎片的情况下）。
• 可以在同一个物理磁盘上执行脱机碎片整理，而不必将数据库复制到维护服务器上（此任务所用的时间大大超过了将数据库文件复制到同一个物理硬盘上的临时目录所用的时间）。
• 可以在还原数据库之前，将数据库副本备份到同一个物理磁盘上。通过这种方法，可以在还原期间发生问题（例如，现有备份有错误）时尝试修复该数据库。为此，建议您在还原数据库之前，移动或复制当前数据库和日志文件。有关还原 Exchange 数据库的信息，请参阅 Exchange Server 2003 Disaster Recovery Operations Guide（英文）。

  注意：
  如果平均来看，数据库很大，那么在将最新数据库复制到其他物理磁盘驱动器或另一个服务器时，可能会增加几个小时的停机时间。但是，如果同一个物理驱动器上有足够的本地磁盘空间，则可以在进行还原之前，使用命令提示符或 Windows 资源管理器将最新的数据库文件移动到另一个文件夹。

磁盘性能和 I/O 吞吐量

具有足够的磁盘 I/O 吞吐量来支持特定数量的用户，与具有足够的磁盘空间同等重要。这对于 Exchange 2003 等耗费磁盘空间的应用程序来说尤其重要。通常，物理磁盘的速度和数目对存储系统总体性能的影响最大。如果在 SAN 中使用大型或低速的磁盘来提供所需的存储空间，那么磁盘 I/O 要求（而不是存储空间）会成为评估存储配置的决定性因素。在这种情况下，可能会需要更多的磁盘，这并不是为了获得额外的存储空间，而是为了获得由额外的磁盘心轴提供的已增加的 I/O。

例如，假设一个大小适中且平衡的逻辑单元号 (LUN) 由十个 18 GB 15,000 RPM 的磁盘驱动器组成，将该 LUN 用于邮箱配额设置为 50 MB 的数据库。使用五个 36 GB 15,000 RPM 的磁盘驱动器会提供相同的存储量，却只有一半磁盘心轴，因此，每秒钟只有一半的 I/O 操作（可能会造成磁盘 I/O 性能不足）。还需要特别注意的是，使用十个 36 GB 15,000 RPM 的磁盘驱动器可以使 LUN 的大小增加一倍，但这并不一定意味着邮箱配额可以从 50 MB 增加到 100 MB。虽然这样的配置每秒钟有可能提供同等的或更好的 I/O 性能，但是数据库大小可能增加一倍很可能会延长数据库恢复时间，从而超出了 SLA 所提出的要求。

以下是 Exchange 2003 MAPI Messaging Benchmark 版本 3 (MMB3) 中的性能假设，一般情况下，每个用户对包含他们邮箱的数据库每秒钟生成 0.5 个 I/O 请求。通过分析磁盘 I/O 分级，可以从 I/O 角度估计出所需的心轴数。

注意：
有关 MMB3 的详细信息，请参阅 Exchange Server 2003 MAPI Messaging Benchmark 3 (MMB3)（英文）。

为了帮助说明这一概念，下表列出了每秒磁盘 I/O 分级示例。

每秒磁盘 I/O 分级示例

磁盘速度	已分级的每秒 I/O	每个磁盘的 MMB3 用户
7,200 RPM	100	200
10,000 RPM	125	250
15,000 RPM	166	332

7,200 RPM 磁盘（列在表 4.3 中）的磁盘 I/O 分级显示一个 7,200 RPM 心轴可为 200 个并发 MMB3 用户提供足够的磁盘 I/O。如果一个存储组含有 2,000 个用户，那么该存储组所用的条带化组将需要十个 7,200 RPM 磁盘。在 RAID 0+1 集中（可以提供比纯条带化阵列好得多的可恢复性），2,000 个用户的存储组数据库需要使用 20 个磁盘。

按照表 4.3 中的数据，在一个存储组中使用 36 GB 10,000 RPM 的磁盘支持 2,000 个 MMB3 用户（每个用户的邮箱配额是 50 MB），需要条带化组中有八个磁盘（对于 RAID 0+1 集，则为 16 个磁盘）。八个 36 GB 的磁盘可转换为 288 GB LUN，这远远超过了 110 GB LUN 的存储大小要求。在这种情况下，如果 360 GB 10,000 RPM 磁盘足够使用，则对 I/O 的要求决定了整个存储要求，而不是存储空间。

在 Exchange 组织中，优化 SAN 上的磁盘 I/O 是增强性能的最有效措施之一。每个 SAN 供应商对此都提供了不同的选项和要求。因此，应该根据特定的 I/O 要求来了解和设计 SAN 实现。对于 Exchange，这些要求包括：

• Exchange 使用 4 KB 页作为本地 I/O 大小，即使许多事务可能会导致对多个页的读或写请求也是如此。
• 事务日志 LUN 应该针对顺序写入进行优化，因为日志总是先按顺序写入，再按顺序读取。
• 数据库 LUN 应该针对随机读取和写入的适当权重进行优化。通过使用 Exchange 压力和性能 (ESP) 工具及 Jetstress 工具，可以用实验方法确定此权重。
• 应考虑可恢复性和 SLA 要求。

有关如何规划存储系统以最大程度发挥性能和可用性的详细信息，请参阅 Solution Accelerator for MSA Enterprise Messaging（英文）。

有关规划存储体系结构的信息，请参阅 MSA Reference Architecture Kit（英文）中的“MSA Storage Architecture”。

磁盘碎片整理

磁盘碎片整理包含重新安排服务器硬盘上的数据，使文件更加连续，从而可以更有效地读取。对硬盘进行碎片整理有助于提高磁盘性能，并确保 Exchange 服务器平稳有效地运行。

因为磁盘碎片过多可导致性能问题，所以要定期运行磁盘碎片整理软件（例如“磁盘碎片整理程序”），或者在服务器性能下降到正常级别以下时运行。由于备份碎片化程度很严重的文件系统需要更多地读取磁盘，因此，请确保您最近已经对磁盘进行了碎片整理。

Exchange 数据库也需要碎片整理。不过，Exchange 数据的碎片整理是在 Exchange 数据库自身内进行的。具体地说，Exchange 数据库碎片整理指的是重新安排邮箱存储和公用文件夹存储的数据，以便更有效地填充数据库页，从而消除了未使用的存储空间。

Exchange 数据库碎片整理有两种类型：联机和脱机。

联机碎片整理

默认情况下，在 Exchange 2003 服务器上，联机碎片整理是在每天 01:00（上午 1:00）至 05:00（上午 05:00）之间进行。联机碎片整理可以自动检测和删除那些不再使用的对象。此过程可提供更多的数据库空间，而无须实际更改进行碎片整理的数据库的文件大小。

注意：
若要提高碎片整理和备份过程的效率，请为您的维护过程和备份操作做好日程安排，使其在不同的时间运行。

下面是为数据库碎片整理做日程安排的两种方法：

• 若要为单个数据库的数据库碎片整理做出日程安排，请使用邮箱存储或公用文件夹存储对象的“数据库”选项卡上的“维护间隔”选项。
• 若要为邮箱存储和公用文件夹存储集合的数据库碎片整理做出日程安排，请使用邮箱存储或公用文件夹存储策略的“数据库（策略）”选项卡上的“维护间隔”选项。

有关如何创建邮箱存储策略或公用文件夹策略的信息，请参阅 Exchange 2003 帮助中的“创建邮箱存储策略”和“创建公用文件夹存储策略”。

脱机碎片整理

脱机碎片整理涉及使用 Exchange Server 数据库实用程序 (Eseutil.exe)。Eseutil.exe 会创建一个新的数据库，将旧数据库记录复制到新数据库中，然后丢弃未使用的页，从而生成一个新的压缩数据库文件。若要减小数据库的物理文件大小，必须在下列情况下执行脱机碎片整理：

• 执行数据库修复之后（使用 Eseutil /p）
• 从 Exchange 数据库中移出大量数据之后
• 当 Exchange 数据库大小比其应有大小大很多时

注意：
只有在将许多用户从 Exchange 2003 服务器中移出时或修复数据库之后，才应该考虑执行脱机碎片整理。如果在不需要时执行脱机碎片整理，则会导致性能降低。

当使用 Eseutil.exe 对 Exchange 数据库进行碎片整理时，请考虑下列因素：

• 若要在备用位置重建刚刚碎片整理过的数据库，请在碎片整理模式下运行 Eseutil.exe（使用 Eseutil /d 命令），同时要在命令中包含 /p 开关。在执行碎片整理操作时使用额外的 /p 开关，可以保留原来碎片整理过的数据库（如果需要还原此数据库）。使用此开关，还可以大大减少对数据库进行碎片整理所需的时间。
• 因为脱机碎片整理会完全改变数据库页，所以在执行脱机碎片整理之后应立即创建 Exchange 2003 数据库的新备份。如果使用备份实用程序执行 Exchange 数据库备份，请创建 Exchange 数据库的新的常规备份。如果不创建新的常规备份，则先前的增量备份或差异备份将不起作用，这是因为它们引用的数据库页已经被碎片整理过程重新排序。

优化内存使用

当部署 Exchange 邮件系统时，虚拟地址空间是一个需要考虑的重要因素。服务器的虚拟地址空间使用情况决定了邮箱服务器的整体性能和可伸缩性。当虚拟内存不足时，性能将明显降低。虽然 Exchange 2003 会自动为中小型服务器优化内存使用情况，但对于物理内存大于 1 GB 的服务器而言，还需要做进一步的调整。

有关虚拟内存碎片的影响的信息，以及优化内存使用的准则，请参阅 Exchange Server 2003 Performance and Scalability Guide（英文）。

其他 Windows 和 Exchange 配置问题

在规划高可用性邮件系统时，要考虑许多配置建议。不过，这些配置建议的详细说明超出了本指南的范围。有关配置邮件系统以实现高可用性、高可伸缩性和高性能的完整信息，请参阅 Exchange Server 2003 Performance and Scalability Guide（英文）。