建立 Exchange 内容索引重建基准 – 第 1 部分

原文发布于 2012 年 6 月 26 日（星期二）

在解决 Exchange 内容索引 的可疑问题时，大多数 Exchange 管理员通常采取的第一个操作之一是重建受影响的邮箱数据库的内容索引文件（可以采用手动方式，也可以采用 \Exchange Server\Scripts 目录下的 ResetSearchIndex.ps1 脚本）。此外，我还与选择以下操作的许多 Exchange 管理员共事过多年：主动重建日历年不同时间点的搜索索引，或主动将搜索索引重建为遇到的项目（比如在迁移项目中；作为单个示例）中的不同里程碑。

无论重置这些索引的推理为何，大多数管理员都无法应要求实际估计出此过程由始至终需要多长时间。不能准确估计此类时间的不良后果根据组织的不同而有所不同。在证实最终用户生产力下降，技术支持遇到的上报问题数量增加后，某些 IT 部门可能会为不能在工作日向用户提供服务器端索引感到气馁。从运营角度来看，不知道预期重建时间还可能会阻碍 Exchange 管理员在重建过程中获悉潜在问题。无论是什么推理，充分了解此过程可能需要的时间都非常重要。

但不可否认的是，现在重建 Exchange 内容索引需要的时间（更准确的描述是，重建 Exchange 内容索引应占用的时间）的相关可用信息微乎其微。显而易见，这是因为实际重建时间始终变化不定。影响重建速度和重建完成时间的因素很多。最突出的因素包括：

• “驻留”在 Exchange 邮箱数据库上的最终用户邮箱总数的变化性
• Exchange 邮箱数据库上包含的邮箱大小的变化性
• 驻留在 Exchange 邮箱数据库上的用户邮箱之间的项目计数的变化性
• Exchange 邮箱数据库之间的项目计数的变化性（在执行并发重建时）
• 位于 Exchange 邮箱数据库内的项目的大小变化性
• 位于 Exchange 邮箱数据库内的邮件附件的数量和大小的变
• Exchange 邮箱服务器上启用 IFilter 的类型和数量（允许对不同文件格式建立索引）
• 执行爬网的邮箱服务器的总体系统资源使用情况（考虑限制）
• 等等…

在 Microsoft（包括我们的企业实施，以及各种 Office-365（该链接可能指向英文页面）产品）中，我们使用了由我的同事 Anatoly Girko 和我开发的 搜索重建框架 。该框架最初旨在为我们的内部操作人员提供一套全面的验证步骤，以及他们在执行内容索引重建时可利用的进度指示器。整体重建过程中的各种关键里程碑中都使用了这些技术，以确保成功完成。

随着此框架的演变，我们决定添加用于跟踪和存储任何和所有重建操作的历史吞吐量指标的附加功能。随着此类数据集的增长，以及后续趋势数据浮出水面，我们发现我们能够对给定重建操作可能需要的时间做出更合理、更准确的估计。此估计进而使我们的运营团队能够对何时安排重建做出更妥善的决策，以使我们最大程度地减少我们最终用户客户群的服务中断。此框架从一开始就用于监视我们支持的不同环境内的数千项内容索引的重建操作。

我们将在一系列文章中讨论我们的“ 重建框架 ”，以使相关方在产生此类需求的情况下可以将相似的方法应用于他们自己的环境。我们将详细介绍此框架的每个阶段，包括讨论我们编写的用于帮助执行此过程的各种工具集。本系列文章将以一系列图形和表格结束，这些图形和表格将详细介绍我们迄今观察到的内容索引重建统计数据和结论。对于之前未跟踪该领域统计数据的客户，我们希望这些内容成为其宝贵的参考点。它可能可以使您在自己的环境中对 Exchange 内容索引重建时间做出更合理的估计。也就是说，值得注意的是，由于所有 Exchange 环境都是唯一的，因此您的重建指标可能与我们观察到的且在此显示的等级显著不同。

在投入讨论之前，同样值得一提的是，本系列文章不能用作故障排除指南。我们希望您自己在排除故障时根据情况决定重建，从而解决问题或用作预防措施。本系列文章中显示的所有示例都以 Exchange 2007 为中心。我之所以决定本文围绕 Exchange 2007 讨论是因为：与 Exchange 2010 相比，重建 Exchange 2007 索引的可能性高得多（与 Exchange 2007 不同，Exchange 2010 能够通过正常的冗余源对内容索引重新设定种子，因此大大减少在多副本体系结构中执行完全索引重建的需要）。在未来几周，在 Anatoly 和我积累了相应使用示例后，我们将发布补充文章，对 Exchange 2010 版本的 内容索引重建分析器 脚本提供参考脚本。

索引重建分析器脚本

在 Microsoft ，我们内部重建内容索引时利用的主要工具集是 IndexRebuildAnalyzer 脚本。此脚本是由 Anatoly 和我专门针对建立内容索引重建基准编写的。如前所述，此脚本有两个版本：Exchange 2007 版本和 Exchange 2010 版本。若要正确计算统计数据，请始终使用与将重建其索引的 Exchange 邮箱数据库版本对应的脚本。IndexRebuildAnalyzer 脚本会根据操作员传递的操作模式生成两种类型的指标。我们内部将这两种模式称为“ 重建前指标 ”和“ 重建后指标 ”（所有属性记录在下面的“参考脚本”一节中）。

虽然此脚本主要用于跟踪内容索引重建操作，但 Exchange 管理员 肯定可以在“ 预先模式 ”中利用此脚本获取 时间点 (PIT) 统计数据，以实现各种以邮箱为中心的用途（例如整个组织的“邮箱数量”、“数据库的项目数量”、“平均邮件大小”等）。如果根据自己的业务要求或需求定期利用此工具，此工具可能会为您提供更多光学系统和功能来获取用户趋势。

执行脚本前在 PowerShell 会话中传递 -Help 参数，可以获取 E2K7_IndexRebuildAnalyzer.ps1 脚本（该链接可能指向英文页面）参数以及使用示例。

下表概述各个参数：

数据库指标标题

重建前

正如上面所定义，脚本的“操作模式”由是否存在 -PostRebuild 开关决定。要获取重建前的指标，不能使用 -PostRebuild 开关。在预先模式中实例化此脚本时，将显示以下标题以及相应指标：

重建后（使用 -PostRebuild 参数）

在使用 -PostRebuild 开关时，IndexRebuildAnalyzer 将尝试计算内容索引重建操作的吞吐量指标。为此，它会解析 应用程序事件日志 来获取邮箱服务器上每个邮箱数据库重建的开始时间（由 事件 ID 109 指示）和完成时间（由 事件 ID 110 指示）。要成功计算重建后指标，必须在重置其相应内容索引的每个邮箱数据库的 事件查看器 中显示完整的事件 ID 对。在事件 ID 对不可用的情况下，此脚本不能计算这些统计数据。在此类情况下，将返回“NoEventsFound”字符串。返回此字符串最常见的原因是：

• 未完成给定数据库或数据库集的内容索引重建操作。
• 应用程序事件日志 已打包或清除（最好将“最大日志大小”值设置为可持续性最长的值。
• 报告“NoEventsFound”的邮箱数据库最近未重置其内容索引（因此事件日志中没有事件 ID 对）。通过使用 -CSVFile 选项和 Excel，可以从结果集中轻松筛选出这些字符串。我将处理并提供在框架的 步骤 5 中进行筛选的示例。

在传递 -PostRebuild 开关执行脚本时，还会计算所有“重建前”标题和指标。使用 -PostRebuild 开关时，将包括添加以下标题和指标：

结束语

您可以在此（该链接可能指向英文页面）下载 Exchange 2007 索引重建分析器脚本。

在本系列的第 2 部分中，我将讨论搜索重建框架，在本系列的第 3 部分中，我将讨论我们目前在 Microsoft 内看到的内容。

Eric Norberg
服务工程师
Office 365 专业服务

这是一篇本地化的博客文章。请访问 Establishing Exchange Content Index Rebuild Baselines – Part 1 以查看原文