建立 Exchange 内容索引重建基线 – 第 2 部分

  • Article

原文发布于 2012 年 6 月 27 日（星期三）

在本系列的第 1 部分，我介绍了 E2K7_IndexRebuildAnalyzer.ps1 脚本（该链接可能指向英文页面），在此文章中，我将讨论由 Anatoly Girko 和我开发的搜索重建框架。此框架的最初设计宗旨是为内部操作人员提供一组综合的验证步骤和进度指示器，便于他们在重建内容索引时使用。

第 1 阶段：重建前的统计数据收集

在我们的环境中，无论何时决定重建 Exchange 邮箱数据库的内容索引 文件，操作员首先要做的是在重建前计算受影响存储的统计数据。这些统计数据通常会写入 CSV 文件以进行归档，并最终添加到历史数据集合中。但正如我们所讨论的，可以选择性地使用 -CSVFile 参数。在未传递 -CSVFile 参数的情况下，其相应输出将写入 Shell 控制台窗口中。为获取最佳可读性，应相应调整控制台的 屏幕缓冲区宽度 和 窗口宽度 ，以正好适合输出的各种不同类型的标题和指标，这样您就可以更轻松地读取控制台会话中的值。在这里我通常会使用 -AutoSize (-a) 参数将输出发送至 Format-Table (ft) 。

示例

控制台示例 ：

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 | ft -a

输出 ：

1

CSV 示例：

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -CSVFile c:\ericnor\NA-1ERICNOR-1_PreRebuild.csv

输出 ：

2

3

将 预设指标 与历史数据集合进行比较，由此估算出完成重建的平均时间；另外还要将邮箱数据库和相应最终用户邮箱所在的区域位置考虑在内。然后基于存储的地理位置和完成重建的预估时间来安排重建工作的日期和时间，在该时间段内此存储上的用户活动最少。

第 2 阶段：重设受影响邮箱数据库的内容索引

在我们的环境中，操作员接下来要重设邮箱数据库的内容索引，相关技术可在如何重建全文索引编录中可以找到。

在下面的示例中，我将在当前环境下重设两个邮箱数据库的 内容索引 文件。这两个存储位于 NA1-ERICNOR-1 群集邮箱服务器上，可能具有最大邮箱计数、最大 EDB 文件大小和最大集体数据库项目计数：

4

重设内容索引文件：

5

第 3 阶段：验证搜索索引器是否已检测到所需的完全爬网

现有内容索引文件从文件系统中删除后，重新启动 Microsoft Exchange 搜索索引器 服务，MonitorAndUpdateMDBList 线程将确定邮箱服务器上所有已启用内容索引的邮箱数据库的内容索引的当前状态。MonitorAndUpdateMDBList 线程确定每个邮箱数据库的 内容索引健康状况 后，会将每个邮箱数据库的健康状况值写入内存。如果内容索引健康状况的值为“新”，则 Microsoft 搜索索引器服务 确定需要完整的 完全爬网 ，以便使内容索引文件为健康状况（“健康”是其索引通过存储通知保持最新的重要因素）。此时 Exchange 搜索索引器 服务将针对受影响的邮箱数据库启动 完全爬网 操作。

完全爬网 操作实际开始时间在应用程序事件日志中由 事件 ID 109 指示。

若要确保系统上的所有 完全爬网 操作已开始，执行此工作的操作员需要验证其内容索引在之前 步骤 2 中已重设的每个邮箱数据库是否已显示 事件 ID 109。

示例

如上一示例所示，NA1-ERICNOR-1-DB1 和 NA1-ERICNOR-1-DB18 的内容索引文件是使用 ResetSearchIndex 脚本重设的。若要验证 Microsoft Exchange 搜索索引器 服务是否已开始完全爬网操作，邮箱服务器上每个邮箱数据库应显示唯一的 事件 ID 109。如下所示：

事件类型: 信息
事件源: MSExchange 搜索索引器
事件类别: 常规
事件 ID: 109
日期: 5/10/2012
时间: 2:22:19 PM
计算机: NA1-ERICNOR-1-A
描述: Exchange 搜索索引器已创建新的搜索索引，并将对邮箱数据库 NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129) 执行完全爬网操作。

事件类型: 信息
事件源: MSExchange 搜索索引器
事件类别: 常规
事件 ID: 109
日期: 5/10/2012
时间: 2:22:20 PM
计算机: NA1-ERICNOR-1-A
描述: Exchange 搜索索引器已创建新的搜索索引，并将对邮箱数据库 NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16) 执行完全爬网操作。

注意 ：与直观查看事件日志不同，另外一种可行技术只需使用 Get-EventLog（该链接可能指向英文页面）cmdlet 便可将开始事件写入 CSV 文件。示例：

Get-EventLog "Application" | Where-Object {$_.EventID -eq 109} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_StartEvents.csv

第 4 阶段：验证搜索索引器进度和完成情况

验证 完全爬网 操作是否已开始（通过 事件 ID 109 指示）后，操作员可通过 系统监视器 来监控重建整体进度，尤其要监控以下对象和计数器：

  • MSExchange 搜索索引器\正在爬网数据库数
  • MSExchange 搜索索引器\通知保持最新的已索引数据库数
  • MSExchange 搜索索引\<正在爬网的数据库实例>\完全爬网模式状态
  • MSExchange 搜索索引\<正在爬网的数据库实例>\文档索引速率
  • MSExchange 搜索索引\<正在爬网的数据库实例>\其余要爬网的邮箱数
  • MSExchange 搜索索引\<正在爬网的数据库实例>\最近移动的正在爬网的邮箱数
  • MSExchange 搜索索引\<正在爬网的数据库实例>\正在处理的批数
  • MSExchange 搜索索引\<正在爬网的数据库实例>\限制延迟时间

通过查看 MSExchangeSearchIndexer 对象，操作员可轻松确定服务器上保持最新内容索引的数据库个数以及正在爬网数据库个数。当邮箱服务器已全部为最新时，“正在爬网数据库数”计数器的值将始终等于 0，“通知保持最新的已索引数据库数”计数器的值将等于服务器上启用内容索引的邮箱数据库个数。

在此示例中，邮箱服务器上一共有 18 个邮箱数据库，其中两个数据库正在进行 完全爬网 。因此，“正在爬网数据库数”计数器的值应等于 2，“通知保持最新的已索引数据库数”计数器的值应等于 16，如下所示：

6

单个邮箱数据库完成 完全爬网 时，您会注意到系统监视器中各种对象计数器都发生了特定更改。

在 MSExchange 搜索索引器 级别：

  • “正在爬网数据库数”计数器递减 1
  • “通知保持最新的已索引数据库数”计数器递增 1。

在“邮箱数据库索引”级别：

  • 特定数据库上“完全爬网模式状态”的值已递减为 0（这将影响由 MonitorAndUpdateMDBList 监视器线程确定的 内容索引健康 状况的新值）。
  • “其余要爬网的邮箱数”计数器的值应为 0。
  • 虽然与 完全爬网 重建操作本身没有特别关系，但是针对每次索引，“最近移动的正在爬网的邮箱数”计数器也应为 0。因为 Exchange 邮箱已在 Exchange 邮箱数据库间成功移动（提供的目标数据库已启用内容索引），目标数据库上的搜索通知将暂时中止。Exchange 搜索索引器服务 启动以便对最近移动的邮箱进行不完全爬网，使主索引全部为最新。不完全爬网一旦完成，存储通知将恢复操作。需要注意的是，虽然 完全爬网 从技术上来讲已经完成，但如果在内容索引重建时移动邮箱，仍有可能会发生不完全爬网。如果该计数器等于 0，则表示邮箱数据库上发生的所有爬网活动已明确完成。这样，便通过了验证。

Exchange Server 上所有内容索引全部为最新时，您会看到以下内容：

  • “MSExchange 搜索索引器\正在爬网数据库数”等于 0。
  • “MSExchange 搜索索引器\通知保持最新的已索引数据库数”等于邮箱服务器上启用索引的邮箱数据库数。
  • 邮箱服务器上每个 Exchange 邮箱数据库实例的“完全爬网模式状态”等于 0。
  • 邮箱服务器上每个 Exchange 邮箱数据库实例的“其余要爬网邮箱数”等于 0。
  • 邮箱服务器上 每个 Exchange 邮箱数据库实例的“最近移动的正在爬网的邮箱数”等于 0。

在此示例中，所有值都是 True，这样就可以合理假设索引已成功重建，从内容索引透视图中可以判断服务器完全 健康 。

7

通过系统监视器，所有内容索引都显示为最新后，执行此工作的操作员需要继续查看应用程序事件日志并验证是否显示 事件 ID 110，该事件是 Microsoft Exchange 搜索索引器 的 完全爬网 完成事件，与事件 ID 109 类似，已完成 完全爬网 的每个邮箱数据库都有唯一的 110 事件项：

事件类型: 信息
事件源: MSExchange 搜索索引器
事件类别: 常规
事件 ID: 110
日期: 5/10/2012
时间: 2:22:19 PM
计算机: NA1-ERICNOR-1-A
描述: Exchange 搜索索引器已创建新的搜索索引，并将对邮箱数据库 NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129) 执行完全爬网操作。

事件类型: 信息
事件源: MSExchange 搜索索引器
事件类别: 常规
事件 ID: 110
日期: 5/10/2012
时间: 5:11:47 PM
计算机: NA1-ERICNOR-1-A
描述: 搜索索引器已创建新的搜索索引，并将对邮箱数据库 NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16) 执行完全爬网操作。

注意 ：与直观查看事件日志不同，另外一种可行技术只需使用 Get-EventLog（该链接可能指向英文页面）cmdlet 便可将完成事件写入 CSV 文件。示例：

Get-EventLog "Application" | Where-Object {$_.EventID -eq 110} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_CompletionEvents.csv

第 5 阶段：收集重建后指标

在 第 5 阶段 ，假设操作员已验证了每个邮箱数据库均已完成 完全爬网 。此时操作员需要收集 重建后 指标以确定每个已经历爬网邮箱数据库的吞吐量特征。

若要收集这些指标，请使用 E2K7_IndexRebuildAnalyzer 脚本通过 -PostRebuild 开关来收集。

如前所述， -PostRebuild 解析应用程序事件日志以确定是否显示 事件 ID 109 和 事件 ID 110。在 连续群集复制 的情况下，CCR 群集中每个节点的应用程序事件日志已经过评估。如果脚本能找到这些事件 ID，则可以计算每个邮箱数据库完成 完全爬网 所需要的总时间（以各种时间递增），然后将每个唯一重建操作的吞吐量特征返回给操作员。

同样再次需要注意的是：将对邮箱服务器上的所有邮箱数据库进行评估，而无论邮箱数据库是否已重建搜索索引。另外，如果在不使用 -CSVFile 选项的情况下进行实例化，结果集将输出到控制台窗口中。计算重建后统计数据时，强烈建议您使用 -CSVFile，因为使用 Excel 进行报告、排序、筛选和透视易如反掌。

示例

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -PostRebuild -CSVFile c:\ericnor\NA1-ERICNOR-1_PostRebuild.csv

8

E2K7_IndexRebuildAnalyzer 执行完成后，才能检查 CSV 文件。查看 CSV 文件，显示邮箱服务器上的所有 Exchange 邮箱数据库都已处理。由于找不到搜索索引器事件 ID 对组合，许多 Exchange 邮箱数据库将返回 NoEventsFoundis 字符串。在该示例中，有 16 个邮箱数据库报告“NoEventsFound”，两个邮箱数据库具有有效重建后指标：

9

在 Excel 中，可通过应用简单的基于文本的筛选器对结果集进行进一步的优化。对任何重建后列标题进行筛选并取消勾选“NoEventsFound”字符串，以便仅显示具有有效重建后指标的数据库：

10

对示例结果集应用此筛选器后的结果是仅显示 NA1-ERICNOR-1-DB1 和 NA1-ERICNOR-1-DB18（例如重设其内容索引的邮箱数据库）。同样明确的一点是，因为各种重建后标题都具有相应的有效值，重建后指标已成功确认：

重建后字符串过滤器应用程序：

11

第 6 阶段：Test-ExchangeSearch 验证

重建框架中的 第 6 阶段 将验证驻留在邮箱数据库中每个已重设其内容索引的邮箱现在是否可以返回有效搜索响应。可通过 Test-ExchangeSearch cmdlet 中包含的核心功能来实现此目标。当所有邮箱对于 cmdlet 验证都返回 True 响应时，才表示最终验证已完成。

示例：

Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG1\ NA1-ERICNOR-1-DB1 | Test-ExchangeSearch | ft -a

Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG18\ NA1-ERICNOR-1-DB18 | Test-ExchangeSearch | ft -a

此过程可能需要很长的时间才能完成，具体取决于数据库包含的邮箱个数。同样需要注意的是，使用 Test-ExchangeSearch 进行批量操作时，ResultFound 和 SearchTime 属性在处理完所有邮箱后，仅在控制台窗口中可见（无论其结果为 True 还是 False。）在某些情况下，将所有结果存储到 CSV 文件中以进行归档也是一件非常有意义的事情。

如果某个最终用户邮箱在进行 Test-ExchangeSearch 验证时报告 False，则该测试将被视为不完全问题，需要进行相应的修正。

第 7 阶段：分析重建后指标

为方便阅读，我将以表格格式显示各种指标，这与在 Excel 列中本地显示指标不同。如前所述，在 NA1-ERICNOR-1 群集邮箱服务器上有两个已重建其内容索引的 Exchange 邮箱数据库：NA1-ERICNOR-1-DB1 和 NA1-ERICNOR-1-DB18

邮箱重建后指标：

12

 

邮箱数据库重建后指标：

13

各种重建后和重建前指标最终都会添加到历史数据集合中，使历史数据平均值更具参考价值，便于以后重建练习。

结束语

在本系列的第二篇文章中，涵盖了搜索重建框架的各个阶段，在下一篇文章和最后一篇文章中，将涵盖在 Microsoft 部署范围内观察到的平均值。

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

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