Freigeben über

容量规划 – 是的，事务日志空间对于正常运行和装入数据库至关重要

  • Artikel

原文发布于 2011 年 11 月 9 日（星期三）

前几天，我和可支持性程序经理 Nino Bilic 聊天时，他提到这样一件令人担忧的事情：导致我们的高级客户公开 Exchange 2010 关键情况的首要原因是，邮箱数据库因事务日志 LUN 上的磁盘空间不足而被卸除。

我想了一会。老实说，我感到很震惊，我一直认为通过提供邮箱要求计算器和 TechNet 上的指导信息，我们现在已解决这个问题。在与我分享此信息后，Nino 决定应由我而不是他撰写一篇以事务日志容量规划为主题的博客文章（感谢 Nino）！

容量规划 101

为了正确规划事务日志 LUN 的大小，我们需要了解有关环境的以下事项：

  1. 数据库中将驻留多少个邮箱？
  2. 什么是数据库中邮箱的邮件配置文件？
  3. 平均邮件大小是多少？
  4. 平均邮箱大小是多少？
  5. 每天移动多少个邮箱？
  6. 什么是备份和还原解决方案？
  7. 解决方案是否需要考虑任何其他失败方案（如网络失败）？

在此讨论中，我们假定每个数据库中将驻留 250 个邮箱。每个邮箱每天发送/接收 150 封邮件，且平均邮件大小为 100KB。通过查看了解邮箱数据库和日志容量因素中的表，我们了解到，平均邮件大小为 75KB 的 150 封邮件的配置文件每天（24 小时）将生成 30 个事务日志。由于我们的邮件大小大于 75KB，因此，我们在计算每个邮箱生成的事务日志数时需要考虑这一点。本指南规定：

如果平均邮件大小翻倍到 150 KB，则每个邮箱生成的日志数增大 1.9 倍。此数字表示包含附件和邮件表（邮件正文和附件）的数据库的百分比。

因此，我们可以通过下面公式来确定 100KB 的平均邮件大小产生的影响：

150 / 1.9 = [配置文件的平均邮件大小] / x

x = (100 * 1.9) / 150

x = 1.266666666666667 ~ 1.27

如果具有的邮件大小比基本大小多 25KB，则每个邮箱每天生成的事务日志数将增大 1.27 倍。因此，30 个事务日志 * 1.27 = 39 个事务日志 / 天 / 邮箱。这意味着，对于包含 250 个邮箱的数据库，每个数据库将生成 39 * 250 = 9,750 个邮箱生成事务日志 / 天 / 数据库。

邮箱移动也会生成事务日志。移动到目标数据库的每个邮箱都会在目标而非源中生成足量日志，其大小等于邮箱（包括可恢复项目文件夹中的内容）。例如，每天移动 1% 的邮箱意味着每天会将 2.5 个邮箱移入数据库。如果每个邮箱的平均大小为 5.4GB（包括启用单个项目恢复的 14 天已删除项目保留期），则 2.5 * 5.4GB / 1024 = 13,888 个邮箱移动事务日志 / 天 / 数据库。

从备份/还原的角度来看，我们需要考虑我们所使用的备份体系结构的类型。在每个备份方案中，从容量角度看，您应对邮箱生成的事务日志设置建议的额外天数。通过设置额外空间，您在经历多次失败后仍能正常工作，而不会遭遇停机事件。有关事务日志截断的详细信息，请参阅了解备份、还原和灾难恢复。

  事务日志截断 建议的备份失败保护
每日完整备份 每日 3 天
每周完整备份/每日增量 每日 3 天
每周完整备份/每日差异 每周 7 天
每两月完整备份/每日增量 每日 3 天
Exchange 本机数据保护 不再需要日志 3 天

当然，还需要考虑其他方案。例如，如果您在两个数据中心内部署一个拉伸的数据库可用性组 (DAG)，则仅当两个数据中心之间的网络链接可操作且数据库副本正常运行时，才会发生日志截断。如果您知道 WAN 链接故障需要 5 天时间才能修复，则应调整您的备份失败保护以将此情况考虑在内。

在我们的方案中，假定我们只需要确保在发生截断失败事件后的 3 天内仍能正常工作。这就意味着我们需要 9,750 / 1024 * 3 = 用于邮箱生成的事务日志的 28.5GB 磁盘空间。

另外，我们需要说明整周的邮箱移动事件所需的磁盘空间：13,888 / 1014 * 7 天 = 用于邮箱移动操作的 94.9GB 磁盘空间。

总之，这意味着，每个数据库需要为事务日志预留 123GB 磁盘空间。我们还应包含数据开销因素，以说明可能发生的任何无法解释的现象：123GB * 1.2 = 用于事务日志的 148GB 磁盘空间。

如果为事务日志部署一个专用 LUN，则我们将不会设置 150GB 的 LUN，因为这意味着，如果备份失败且邮箱移动次数过多，则会使用所有磁盘空间。通常，您需要确保设置每个 LUN，例如，仅使用 80% 的磁盘容量。适用的公式为：

LUN 空间 = [预计的磁盘空间使用率] / (1 – [所需可用空间百分比])

LUN 空间 = 148GB / (1 – .2) = 148GB / .8 = 用于专用事务日志容量的 185GB LUN 空间

如果您在与数据库相同的 LUN 上部署事务日志，则只需将事务日志磁盘空间要求与 [预计的磁盘空间使用率] 值的数据库磁盘空间要求组合在一起。

如何阻止使用所有的事务日志磁盘空间？

首先，您需要获取环境的基线以确定典型的每日记录生成率。另外，您必须设置监视，并对生成的任何警报采取措施。监视功能应对以下情况进行监视：

  1. 事务日志 LUN 磁盘空间。设置多个阈值和不同的警报机制。您的第一个警报应不是指示已使用 90% 的磁盘空间的警报。如果您了解典型日志生成基线，则可以设置一个阈值以在磁盘空间使用率大于 20% 时进行报告。
  2. 监视是否成功完成备份（如果您未使用 Exchange 本机数据保护）。第一个备份失败指示应不在磁盘空间不足时出现。
  3. 监视应用程序日志中的截断事件。
  4. 监视数据库副本复制运行状况。

如果我的事务日志出现无法解释的增长，该怎么办？

我的朋友 Mike Lagase 就如何解决此情况撰写了一篇很有用的文章 - https://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx（该链接可能指向英文页面）（请注意，这篇文章是针对 Exchange 2007 撰写的，因此，有多个工具和/或建议可能不再适用于 Exchange 2010）。除了 Mike 提及的步骤之外，您还可以在 Exchange 2010 中使用以下工具，帮助确定无法解释的事务日志增长（感谢 Todd Luttinen 提供此列表）：

  1. 您可以使用存储使用率统计信息 cmdlet (get-StoreUsageStatistics with DigestCategory = ‘LogBytes’) 来标识生成高日志字节计数的邮箱。请注意，这并不总是适用于日志字节数不是由邮箱所有者生成或代表客户端（如 CopyOnWrite）执行操作的情况，并且不包含系统服务生成的日志字节数的情况（事件 ID 9826 中进行了报告）。这些统计信息提供了生成日志活动（过去 1 小时最多 6 个示例）最多的邮箱在最后 10 分钟的活动的摘要。以下内容说明如何使用存储使用率统计信息来查找过去 1 小时内生成日志字节数最多的邮箱：

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <数据库名称>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*

    MailboxGuid SampleID SampleTime LogRecordCount LogRecordBytes
    c007c87a-e030-4414-b741-9cf61e88b9de 5 11/7/2011 4:25:05 PM 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 11/7/2011 4:35:05 PM 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 11/7/2011 4:45:06 PM 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 11/7/2011 4:55:06 PM 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 11/7/2011 5:05:06 PM 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 11/7/2011 5:15:06 PM 247 209987

  2. 还为管理客户端生成了应用程序事件（事件 ID 9826）。这些统计信息表示 2 个小时的活动：

    从 <date/time> 开始，服务 <name> 已对服务器执行此活动:
    RPC 操作数: 24168。
    读取的数据库页数: 1329 (其中已预读取 629 页)。
    更新的数据库页数: 12418 (其中已重新更新 11555 页)。
    生成的数据库日志记录数: 13906。
    生成的数据库日志记录字节数: 660331。
    服务器中的时间: 19142 ms。
    用户模式下的时间: 6100 ms。
    内核模式下的时间: 63 ms。

  3. 性能监视器计数器“MSExchangeIS Client(*)\JET Log Record Bytes/sec”可用于标识导致日志增长的客户端类型。

我相信，每个人都知道确保足够容量以保证您的数据库可用性不受影响的重要性。希望此信息能够帮助您规划您的事务日志容量。

Ross Smith IV
主管程序经理
Exchange 客户体验

这是一篇本地化的博客文章。请访问 Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted 以查看原文