了解邮箱数据库和日志容量因素
适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3
上一次修改主题： 2015-03-09
本主题介绍当在 Microsoft Exchange Server 2010 的邮箱服务器存储设计过程中规划邮箱数据库和日志容量时应考虑的因素。
有许多因素会影响 Exchange Server 2010 邮箱数据库的容量规划。 本节包括下列内容：
邮箱存储配额
数据库空白空间
邮箱数据库可恢复的项目
实际邮箱大小
内容索引
脱机数据库维护
恢复数据库
数据库大小
数据库增长开销
要了解的第一个指标是存储大小限制，也称为邮箱“存储配额”，它在组织中有效。 通过了解允许一位最终用户在其邮箱上存储的数据量，能够确定在该服务器上可驻留多少个用户邮箱。 尽管邮箱存储配额可以更改以适应不断变化的组织要求，但对邮箱存储配额设定目标是确定所需的邮箱数据库容量的第一步。
例如，如果您的服务器上有 5,000 个 250-MB 的用户邮箱，那么您至少需要 1.25 TB 的磁盘空间（不包括可恢复的项目的空间要求）。 如果没有为邮箱存储配额设置限制，您会发现很难估计数据库容量。 Exchange 2010 的邮箱存储配额需要同时包括主邮箱和个人存档邮箱（如果使用）的空间。 有关详细信息，请参阅管理邮箱服务器和管理个人存档。
物理磁盘上的数据库大小并非只是用户数乘以邮箱存储配额得出的值。 当大多数用户未接近其邮箱存储配额时，数据库将占用较少空间，在计算容量时不考虑空白空间。 数据库本身将始终具有分散在各处的可用页（或称空白空间）。 在后台数据库维护期间，删除数据库中标记为删除的项目会释放这些页。 空白空间的百分比随着 24x7 联机碎片整理过程的工作而不断变化。
根据用户使用数据库中的邮箱发送和接收的邮件量，可以估计数据库中的空白空间量。 例如，如果数据库中拥有 100 个 2 GB 的邮箱（共 200 GB），其中用户平均每天发送和接收 10 MB 的邮件，则空白空间量大约为 1 GB (100 * 10 MB)。 如果后台数据库维护不能完成全面检查，则空白空间量可能会超过此近似值。
返回顶部
每个数据库都包含用于存储软删除邮件的垃圾站。 默认情况下，软删除邮件在 Exchange 2010 中存储 14 天，日历项目存储 120 天。
此外，Exchange 2010 还可以防止在超过已删除项目保留期之前清除数据。 此功能称为“单个项目恢复”。 默认情况下禁用单个项目恢复。 但是，启用单个项目恢复后，在已删除项目保留期（14 天）内，邮箱大小会额外增大 1.2%。 对于日历版本日志记录数据（默认情况下已启用），邮箱大小会额外增大 3%。 默认情况下启用日历版本日志记录数据。
对于启用了单个项目恢复和日历版本日志记录的 14 天已删除项目保留期，用于确定该期限的垃圾站空间要求的公式为：
垃圾站大小 =（每日传入/传出邮件 x 平均邮件大小 x 已删除项目保留期）+（邮箱配额大小 x 0.012）+（邮箱配额大小 x 0.03）
例如，如果邮箱大小为 2 GB，为 14 天的已删除项目保留期启用单个项目恢复需要额外 25 MB 空间，日历日志记录功能需要额外 61 MB。
有关详细信息，请参阅下列主题：
随着时间的推移，用户邮箱将达到邮箱存储配额，所以将需要删除相当于传入邮件的邮件量以使其保持低于邮箱存储配额。 这一要求意味着，垃圾站将增大到最大大小（等于每天发送和接收的电子邮件量乘以已删除项目保留期中的天数）。 如果大多数用户尚未达到存储配额，则只删除一部分传入/传出邮件。 因此，增长将在垃圾站和邮箱大小增加之间划分。
若要确定使用 2 GB 邮箱而不使用个人存档功能的数据库大小，请参阅 Exchange 2010 邮箱服务器角色设计示例主题中的“邮箱容量要求”部分。
确定预计实际邮箱大小后，可以使用该值确定每个数据库的最大用户数。 用预计邮箱大小除以建议的数据库大小。 此值还有助于确定处理预计用户数所需的数据库数（假设为完全填充的数据库）。 请注意，由于存在非事务输入/输出 (I/O) 或硬件限制，可能必须修改位于单个服务器上的用户数。 某些管理员希望使用更多数据库来进一步减小数据库大小。 此方法有助于备份和还原窗口，但其代价是在每个服务器上管理更多数据库增加了复杂性。
内容索引将创建索引或编录，使用户可以快速轻松地搜索其邮件项目，而不用手动搜索邮箱。Exchange 2010 将创建大约为总数据库大小的 10％ 的索引，该索引与数据库位于同一个 LUN 上。 因此，还需考虑对数据库 LUN 大小增加额外的 10% 容量，以用于内容索引。
返回顶部
如果需要脱机压缩某数据库，则需要目标数据库大小加 10％ 的容量。 无论是否为单个数据库或备份集分配了足够空间，都需要有可用的额外空间以执行下列操作。
.gif "重要") 重要说明： |
|---|
| 脱机维护过程只能按照 Microsoft 客户服务和支持部门的请求来实现，这是因为脱机维护过程会使所有数据库副本失效并需要对数据库进行完全的种子重新设定。 |
如果计划在灾难恢复规划中使用恢复数据库，则需要有足够的可用容量以处理您希望能够在该服务器上同时还原的所有数据库。 有关详细信息，请参阅恢复数据库。
数据库大小最终确定在每个数据库中部署多少个邮箱以及部署多少个数据库。 所部署的数据库大小取决于以下若干因素：
备份/还原服务级别协议 (SLA) 数据库大小最终决定可在合理的时间内备份和还原数据的速度。
高可用性体系结构 如果计划拥有多个数据库副本，可将您的数据库大小设计为 2 TB，这是因为就恢复操作而言，数据库副本是第一道防线。
存储体系结构 如果计划在 JBOD 存储（一个磁盘同时容纳数据库及其相应的事务日志）上部署，则所使用的磁盘大小决定了最大数据库大小。 例如，在 1 TB 磁盘（格式化的容量约为 917 GB）上，还需要包括事务日志和内容索引的空间，并确保您不会占用所有可用空间。
在考虑并计算所有因素后，建议您还要考虑增加用于数据库逻辑单元号 (LUN) 的 20％ 的开销。 此值将考虑到在计算邮箱大小和空白空间时未必会看到的驻留在数据库中的其他数据。
返回顶部
事务日志文件将记录数据库引擎执行的每个事务。 所有事务将先写入日志，然后再慢慢写入数据库。 与 Exchange Server 2003 不同，Exchange 2010 中的事务日志文件大小已从 5 MB 减小到 1 MB。 此更改旨在支持连续复制功能，并将主存储失败时的数据损失量降到最低。
可以使用下表来估计将在 Exchange 2010 邮箱服务器上生成的事务日志数量，其中平均邮件大小为 75 KB。
“每天生成的事务日志数”的值取决于选择的邮件配置文件和平均邮件大小。 它表示每天每个邮箱将生成的事务日志数。 每个邮件配置文件的日志生成数需考虑以下因素：
邮件大小的影响
发送/接收的数据量
数据库运行状况维护操作
记录管理操作
不是邮件但存储在邮箱中的数据（任务、本地日历约会、联系人）
强制的日志滚动（定期关闭当前事务日志文件的机制）
每个邮箱配置文件生成的事务日志数量
| 邮件配置文件（75 KB 的平均邮件大小） | 每日生成的事务日志的数量 |
|---|---|
50 |
10 |
100 |
20 |
150 |
30 |
200 |
40 |
250 |
50 |
300 |
60 |
350 |
70 |
400 |
80 |
450 |
90 |
500 |
100 |
可以使用以下准则来了解邮件大小如何影响事务日志的生成速度：
如果平均邮件大小是 150 KB 的两倍，则每个邮箱生成的日志增加 1.9 倍。 该数字表示包含附件和邮件表（邮件正文和附件）的数据库的百分比。
因此，邮件大小超过 150 KB 的两倍时，每个邮箱的日志生成速率也会增加一倍，从 1.9 增加到 3.8。
例如，如果您每天有 100 封邮件，并且：
平均邮件大小为 150 KB，每个邮箱生成的日志为 20 × 1.9 = 38。
平均邮件大小为 300 KB，每个邮箱生成的日志为 20 × 3.8 = 76。
以下部分讨论影响日志大小容量的因素：
备份和还原因素
移动邮箱操作
日志增长开销因素
高可用性因素
LUN 容量规划
日志 LUN 大小在一定程度上取决于备份和还原设计。 例如，如果设计允许后退两周并重播自那时起生成的所有日志，则需要两周日志文件的空间。 如果备份设计包括每周完整备份和每日差异备份，则日志 LUN 需要大于整周日志文件的空间，以允许在还原期间进行备份和重播。 大多数执行夜间完全备份的企业，会将所需的每天日志生成容量的分配提高到两到三倍。 采用该方法可防止备份失败导致填满日志驱动器而卸除数据库。
如果计划在 Exchange 2010 中使用邮箱恢复和单个项目恢复功能作为备份基础结构（从而启用循环日志记录），那么最佳做法是，您应该确保将所需的每天日志生成容量的分配提高到三倍。 这样可确保当复制已挂起或在正常参数下无法运行时，数据库不会由于截断故障而卸除。
移动邮箱是大型邮箱部署的主要容量因素。 许多大型公司每夜或每周将一定百分比的用户邮箱移动到不同的数据库、服务器或网站。 如果您的组织也是如此，您可能会发现为日志 LUN 多提供一些空间以容纳邮箱移动是非常必要的。
尽管源服务器会记录小型记录删除，目标服务器仍必须先将所有传输数据写入事务日志。 如果一天生成 10 GB 的日志文件，并且将 30 GB 的缓冲区保留三天，则移动 50 个 2 GB 的邮箱 (100 GB) 将填满目标日志 LUN 并导致停机。 在上述情况下，可能必须为日志 LUN 分配额外容量以支持移动邮箱。
对于大多数部署来说，我们建议您在创建日志 LUN 时向日志大小增加 20% 的开销因素（考虑其他所有因素之后），这样可以确保出现意外的日志生成时存在必要的容量。
高可用性会在三个重要方面影响日志容量要求：
数据库副本计数 整个系统的日志容量会基于在高可用性部署中选择的数据库副本的数量而增加。 如果有三个数据库副本分布在三个服务器上，则需要为每个服务器上的每个副本设置日志容量。
日志截断机制 由于 Exchange 2010 中的高可用性最多可以提供每个邮箱数据库的 16 个副本，因此它可提供将连续复制循环日志记录作为日志截断/删除机制的基础（与运行完整/增量备份来截断/删除旧日志相对）。 有关详细信息，请参阅了解备份、还原和灾难恢复和高可用性和站点恢复中的“日志截断而不备份”部分。
数据库副本重播延迟 Exchange 2010 中的高可用性提供了一种选择，可以延迟被动数据库副本上的日志重播（按副本配置）。 此功能用于当将日志播放到延迟数据库副本中时提供延迟。 这种延迟可能有利于防止发生导致将不需要的内容复制到所有数据库副本的事件。 通过在将带有不需要的内容的日志播放到数据库中之前挂起重播，可以防止将该内容播放到延迟数据库副本中。
为数据库副本启用重播延迟后，日志容量要求会相应地发生更改。 如果配置了 14 天延迟，则需要设置 17 天的日志。 只有配置了延迟的数据库副本需要额外的日志容量，该数据库的其他副本（没有延迟）将具有正常的（非延迟）日志容量要求。
有关详细信息，请参阅了解高可用性因素。
LUN 的容量要求将基于数据集（数据库、事务日志、内容索引和恢复空间）的大小以及其他一些可用空间。 多数操作管理程序都具有容量阈值，当 LUN 的利用率超过 80％ 时，容量阈值可提供警报。
可以使用以下公式来确定 LUN 的相应大小：
LUN 容量 = 数据大小 /（1 - 可用空间百分比要求）
例如，如果数据大小要求为 3000 MB，可用空间要求为 20％，则承载该数据的 LUN 的大小必须为 3750 MB。
若要避免消耗所有事务日志磁盘空间，必须先计算环境的基线以确定典型的每日日志生成率。 其次，必须设置监视，并针对生成的任何警报执行操作。应该监视的项目如下：
事务日志 LUN 磁盘空间。设置多个阈值和不同的警报机制。 例如，如果您知道自己的典型日志生成基线，则可设置一个阈值以便在超出基线 20% 时报告。
成功完成您的备份（如果您不使用 Exchange 本机数据保护）。
截断应用程序日志中的事件。
您的数据库副本复制状况。
若要帮助解决事务日志中不明原因的增长，请参阅在命令行管理程序中使用 Troubleshoot-DatabaseSpace.ps1 脚本管理数据库日志增长。
© 2010 Microsoft Corporation。保留所有权利。