建立 Exchange 内容索引重建基准 – 第 2 部分
原文发布于 2012 年 6 月 27 日（星期三）
在本系列的第 1 部分中，我介绍了 E2K7_IndexRebuildAnalyzer.ps1 脚本（该链接可能指向英文页面）。在本文中，我将讨论 Anatoly Girko 和我开发的搜索重建框架。此框架最初旨在向我们的内部操作人员提供一组他们在重建内容索引时可以利用的全面的验证步骤和进度指示器。
阶段 1：收集重建前统计数据
在我们的环境下，如果决定重建 Exchange 邮箱数据库的内容索引 文件，操作员会先对受影响的存储计算重建前统计数据。这些统计数据始终会被写入 CSV 进行存档，并且最终会被插入历史数据收集组。但如之前所述， -CSVFile 参数是可选项。在不传递 -CSVFile 参数的情况下，系统会将相应输出写入外壳控制台窗口。为获得最佳可读性，您应调整控制台的“屏幕缓冲区大小宽度”和“窗口大小宽度”来完全适应将输出的所有不同标题和指标。这样，您才可以在控制台会话中更轻松地读取这些值。我通常使用 -AutoSize (-a) 参数将输出从那里“输送”到 格式表 (ft) 。
示例
控制台示例 ：
.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 | ft -a
输出 ：
CSV 示例：
.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -CSVFile c:\ericnor\NA-1ERICNOR-1_PreRebuild.csv
输出 ：
这些 预先指标 随后与历史数据集合对比，因此派生出完成重建的估计平均时间。我们将邮箱数据库和相应最终用户邮箱的区域位置纳入考虑范畴。根据存储的地域和完成的估计时间，我们在该存储的用户活动最少的日期和时间内安排重建工作。
阶段 2：重置受影响邮箱数据库的内容索引
在我们的环境中，操作员随后使用如何重建全文检索目录中记录的任一方法，继续重置邮箱数据库的内容索引。
在随后的示例中，我将在我的环境内对两个邮箱数据库重置 内容索引 文件。此外，这两个存储碰巧在 NA1-ERICNOR-1 群集邮箱服务器上具有最大的邮箱计数、EDB 文件大小和集体数据库项目计数：
重置内容索引文件：
阶段 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
计算机：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
计算机：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”，而“通过通知保持最新的索引数据库的数量”计数器值等于服务器上启用内容索引的邮箱数据库的数量。
在我的示例中，我的邮件服务器上共有十八个邮箱数据库，其中有两个数据库目前正在进行 完全爬网 。因此，“进行爬网的数据库的数量”(Number of Databases Being Crawled) 的值应等于“2”，而“通过通知保持最新的索引数据库的数量”(Number of Indexed Databases Being Kept Up-to-Date by Notifications) 的值应等于“16”，如下所示：
在单个邮箱数据库完成 完全爬网 时，您将在系统监视器中看到不同对象计数器的具体更改。
在“MSExchange 搜索索引器”(MSExchange Search Indexer) 级别：
- “进行爬网的数据库的数量”(Number of Databases Being Crawled)计数器减少 1
- “通过通知保持最新的索引数据库的数量”(Number of Databases Being Crawled) 增加 1。
在“邮箱数据库索引”级别：
- 特定数据库上“完全爬网模式状态”(Full Crawl Mode Status) 的值已减少到“0”（这反映了 MonitorAndUpdateMDBList 监视器线程确定的“内容索引运行状况”的新值）。
- “剩下的要爬网的邮箱的数量”(Number of Mailboxes Left to Crawl) 应为值“0”。
- 虽然本身并非与 完全爬网 重建操作明确相关，但每个索引的“最新移动的进行爬网的邮箱的数量”(Number of Recently Moved Mailboxes Being Crawled) 计数器的值也应为“0”。在 Exchange 邮箱数据库之间成功移动 Exchange 邮箱（如果目标已启用内容索引）时，目标数据库上的搜索通知将临时挂起。Exchange 搜索索引器服务 会执行此操作，以便对最新移动的邮箱执行 1 次性爬网，以使主索引完全处于最新状态。在完成 1 次性爬网后，将恢复存储通知。此处的要点是，虽然从技术角度而言已完成 完全爬网 ，但仍可以在重建内容索引的同时移动邮箱的情况下执行 1 次性爬网。如果此计数器等于“0”，则邮箱数据库上发生的所有爬网活动定将结束。因此，同样应对其进行验证。
在所有内容索引处于完全最新状态的 Exchange Server 上，您有望看到以下内容：
- “MSExchange 搜索索引器\进行爬网的数据库的数量”(MSExchange Search Indexer\Number of Databases Being Crawled) 等于“0”。
- “MSExchange 搜索索引器\通过通知保持最新的索引数据库的数量”(MSExchange Search Indexer\Number of Indexed Databases Being Kept Up-to-Date by Notifications)等于邮箱服务器上启用索引的邮箱数据库的数量。
- 邮箱服务器上每个 Exchange 邮箱数据库实例的“完全爬网模式状态”(Full Crawl Mode Status) 等于“0”。
- 邮箱服务器上每个 Exchange 邮箱数据库实例的“剩下的要爬网的邮箱的数量”(Number of Mailboxes Left to Crawl) 等于“0”。
- 邮箱服务器上每个 Exchange 邮箱数据库实例的“最新移动的进行爬网的邮箱的数量”(Number of Recently Moved Mailboxes Being Crawled) 等于“0”。
在我的示例中，以上所有值都是 正确 的，因此我可以合理假设这些索引已成功重建，并且从内容索引角度而言，服务器完全 正常 ：
通过系统监视器，所有内容索引都看似处于最新状态后，执行此工作的操作员将继续查看应用程序事件日志，并验证是否存在 事件 ID 110，后者是 Microsoft Exchange 搜索索引器 的 完全爬网 完成事件。与事件 ID 109 相似，完成 完全爬网 的每个邮箱数据库都将有唯一的 110 事件项：
事件类型：信息
事件源：MSExchange 搜索索引器
事件类别：常规
事件 ID：110
日期：5/10/2012
时间：下午 5:39:47
计算机：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
计算机：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 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
在 E2K7_IndexRebuildAnalyzer 执行完毕后，随后可以检查 CSV 文件。在查看 CSV 时，它将显示邮箱服务器上的所有 Exchange 邮箱数据库已处理。由于无法找到“搜索索引器事件 ID”对组合，因此对许多 Exchange 邮箱数据库返回“NoEventsFound”字符串。在本示例的情况中，报告“NoEventsFound”的邮箱数据库有 16 个，有有效重建后指标的邮箱数据库有两个：
通过在 Excel 中应用基于简单文本的筛选器，可以进一步优化此结果集。通过对任何重建后列标题应用筛选，并且不勾选“NoEventFound”字符串，将仅显示具有有效重建后指标的数据库：
对示例结果集应用此筛选器的结果现在仅显示 NA1-ERICNOR-1-DB1 和 NA1-ERICNOR-1-DB18（例如，重置其内容索引的邮箱数据库）。此外，很明显，由于各个重建后标题有有效值，因此可以成功确定重建后指标：
字符串筛选后的应用：
阶段 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 执行批量操作时，在处理完所有邮箱后（不管结果是“True”还是“False”），控制台窗口中仅显示 ResultFound 和 SearchTime 属性。在某些情况下，以 CSV 格式存储所有结果进行存档也可能很重要。
任何最终用户邮箱对 Test-ExchangeSearch 测试报告“False”被视为 1 次性问题，可进行相应修正。
阶段 7：分析重建后指标
出于可读性目的，与原本在 Excel 列中显示指标的方式不同，我将以表格格式显示各种指标。如前所述，NA1-ERICNOR-1 群集邮箱服务器上重建其内容索引的 Exchange 邮箱数据库有两个：NA1-ERICNOR-1-DB1 和 NA1-ERICNOR-1-DB18
邮箱重建后指标：
邮箱数据库重建指标：
各种重建指标和重建前指标随后会添加到历史数据收集组中，以便可以用于计算历史平均值，以供将来重建练习使用。
结束语
在本系列的第二篇文章中，我介绍了搜索重建框架的各阶段。我的下一篇，也是最后一篇文章将介绍我们在 Microsoft 的部署中观察到的平均值。
Eric Norberg
服务工程师
Office 365 专业服务
这是一篇本地化的博客文章。请访问 Establishing Exchange Content Index Rebuild Baselines – Part 2 以查看原文