共用方式為

建立 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

輸出 ：

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 Search Indexer 服務接著會重新啟動，MonitorAndUpdateMDBList 執行緒會針對為內容索引作業啟用的信箱伺服器，負責判定其上所有信箱資料庫的目前狀態。一旦 MonitorAndUpdateMDBList 執行緒判定每個信箱資料庫的 內容索引健康狀態 之後，它就會將每個信箱資料庫的健康狀態放置到記憶體中。如果內容索引健康狀態的值等於「New」，則 Microsoft Search Indexer 服務 就會作出需要整個 完整編目 的判定，以讓內容索引檔案進入健康狀態 (「健康」指的是索引可透過存放區通知保持在更新狀態的位置點)。此時 Exchange Search Indexer 服務會針對受影響的信箱資料庫啟動 完整編目 作業。

完整編目 作業實際開始的時間會以 事件識別碼 109 標示在應用程式事件記錄檔中。

為了確保所有 完整編目 作業已經在系統上開始，執行作業的操作員會針對每個信箱資料庫驗證 事件識別碼 109 是否存在，之前在 第 2 步驟 中已經重設過這些資料庫的內容索引。

範例

如先前範例所說明，NA1-ERICNOR-1-DB1 和 NA1-ERICNOR-1-DB18 的內容索引檔案會利用 ResetSearchIndex 指令碼加以重設。為了確認 Microsoft Exchange Search Indexer 服務已開始進行完整編目作業，信箱伺服器上的每個信箱資料庫必須具有唯一的 事件識別碼 109。如以下實例所示：

事件類型：資訊
事件來源：MSExchange Search Indexer
事件類別：一般
事件識別碼：109
日期：5/10/2012
時間：2:22:19 PM
電腦：NA1-ERICNOR-1-A
說明：Exchange Search Indexer 已建立新的搜尋索引，並會為信箱資料庫執行完整編目 NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129)。

事件類型：資訊
事件來源：MSExchange Search Indexer
事件類別：一般
事件識別碼：109
日期：5/10/2012
時間：2:22:20 PM
電腦：NA1-ERICNOR-1-A
說明：Exchange Search Indexer 已建立新的搜尋索引，並會為信箱資料庫執行完整編目 NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16)。

附註 ：相對於以觀看方式檢查事件記錄檔而言，另一個可行的技術就是單純使用 Get-EventLog (可能為英文網頁) 指令程式並將開始事件以 CSV 寫入。範例：

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

第 4 階段：驗證 Search Indexer 進度並完成作業

確認 完整編目 作業已開始 (透過檢查 事件識別碼 109 是否存在) 後，操作員會透過 系統監視器 監視整體重建進度。尤其須監視下列物件和計數器：

  • MSExchange Search Indexer\編目的資料庫數目
  • MSExchange Search Indexer\透過通知維持在更新狀態的索引資料庫數目
  • MSExchange Search Indexer\<進行編目的 DB 執行個體>\完整編目模式狀態
  • MSExchange Search Indexer\<進行編目的 DB 執行個體>\文件索引率
  • MSExchange 搜尋索引\<進行編目的 DB 執行個體>\留待編目的信箱數目
  • MSExchange 搜尋索引\<進行編目的 DB 執行個體>\最近移動的編目信箱數目
  • MSExchange 搜尋索引\<進行編目的 DB 執行個體>\未解決的批次數目
  • MSExchange 搜尋索引\<進行編目的 DB 執行個體>\節流延遲值

藉由檢視 MSExchangeSearchIndexer 物件，操作員可以輕易確認伺服器上有多少內容索引處於更新狀態，又有多少是正在接受編目。當信箱伺服器完全處於更新狀態時，「 編目的資料庫數目 」計數器永遠會等於 0，且「透過通知維持在更新狀態的索引資料庫數目」計數器值會等於為伺服器上內容索引而啟用的信箱資料庫數目。

在我的範例中，我在郵件伺服器上總計有十八個信箱資料庫，其中兩個資料庫正在進行 完整編目 。因此， 「編目的資料庫數目」 應該等於 2，而 「透過通知維持在更新狀態的索引資料庫數目」 應該等於 16，其為：

6

當個別的信箱資料庫完成 完整編目 時，您會注意到系統監視器中各種物件計數器所發生的特定變化。

在 MSExchange Search Indexer 層級：

  • 「 編目的資料庫數目」(Number of Databases Being Crawled) 計數器值會減少 1
  • 「透過通知維持在更新狀態的索引資料庫數目」(Number of Indexed Databases Being Kept Up-to-Date by Notification) 會增加 1。

在信箱資料庫索引層級：

  • 在特定資料庫上「 完整編目模式狀態 」的值已減少為 0 (會反映 內容索引健康 狀態的新值，如同 MonitorAndUpdateMDBList監視器執行緒所判定的一樣)。
  • 「 留待編目的信箱數目 」(Number of Mailboxes Left to Crawl) 應該會反映出 0的值。
  • 雖然「 最近移動的編目信箱數目 」(Number of Recently Moved Mailboxes Being Crawled) 並未與 完整編目 重建作業本身有具體關聯性，其針對每個索引的計數器值亦應為 0。當 Exchange 信箱成功在 Exchange 信箱資料庫間移動時 (假設目標已針對內容索引作業啟用)，目標資料庫上的搜尋通知會暫時停止。Exchange Search Indexer 服務 採取此措施以便為最近移動的信箱執行 1-off 編目，並藉此完全更新主要索引。一旦 1-Off 編目完成時，存放區通知就會繼續。請注意，雖然技術上已經完成 完整編目 ，如果信箱移動與內容索引重建同時發生，還是可能會發生 1-off 編目。假設此計數器等於 0，則發生在信箱資料庫上的所有編目活動就會整個完成。因此，它就應當驗證為已完成。

在所有內容索引完全更新的 Exchange 伺服器上，您將可觀察到下列事項：

  • 「MSExchange Search Indexer\編目的資料庫數目 (Number of Databases Being Crawled) 」等於 0。
  • 「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。

在我的範例中，所有這些值皆為 真 ，因此我可以合理假設索引已重建成功，且就內容索引的觀點來看，伺服器完全 健康 ：

7

透過系統監視器觀察，一旦所有內容索引皆處於更新狀態之後，執行作業的操作員會繼續檢視應用程式事件記錄檔，並驗證 事件識別碼 110 是否存在，此為代表 Microsoft Exchange Search Indexer 完成 完整編目 的事件。和事件識別碼 109 一樣，完成 完整編目 的每個信箱資料庫會有唯一的 110 事件項目：

事件類型：資訊
事件來源：MSExchange Search Indexer
事件類別：一般
事件識別碼：110
日期：5/10/2012
時間：5:39:47 PM
電腦：NA1-ERICNOR-1-A
說明：Exchange Search Indexer 已為信箱資料庫 NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129) 完成完整編目 (索引作業)。

事件類型：資訊
事件來源：MSExchange Search Indexer
事件類別：一般
事件識別碼：110
日期：5/10/2012
時間：5:11:47 PM
電腦：NA1-ERICNOR-1-A
說明：Exchange Search Indexer 已為信箱資料庫 NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16) 完成完整編目 (索引作業)。

附註 ：相對於以觀看方式檢查事件記錄檔而言，另一個可行的技術就是單純使用Get-EventLog (可能為英文網頁) 指令程式並將完成事件以 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 會剖析應用程式事件記錄檔以檢查 事件識別碼 109 和 事件識別碼 110 是否存在。在發生 持續叢集複寫 的情況下，則須評估 CCR 叢集中每個節點的應用程式事件記錄檔。如果指令碼可找到這些事件識別碼，指令碼就會針對每個信箱資料庫計算完成 完整編碼 所需的時間總計 (以各種時間遞增)。然後它會傳回給操作員每個唯一重建作業的輸送量特性。

請再次注意，無論所有信箱資料庫是否已重建搜尋索引，將會對信箱伺服器上的所有信箱資料庫進行評估。另外，如果未使用 -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 信箱資料庫已處理完畢。許多 Exchange 信箱資料庫會傳回字串 「NoEventsFound」，因為系統無法找到 Search Indexer 事件識別碼配對組合。在範例中，有 16 個信箱資料庫通報「NoEventsFound」，兩個信箱資料庫具有有效的重建後指標：

9

在 Excel 中套用簡單的文字篩選器可對此結果進一步進行精簡。對任何重建後欄位標頭套用篩選器，並取消勾選「NoEventFound」字串，就可僅顯示具有有效重建後指標的資料庫。

10

在範例結果集上套用此篩選器，僅會顯示 NA1-ERICNOR-1-DB1 和 NA1-ERICNOR-1-DB18 (例如，重設內容索引的信箱資料庫)。當然，重建後指標已經成功確認，因為各種重建後標頭皆具有有效值。

文章字串篩選應用程式：

11

第 6 階段：Test-ExchangeSearch 驗證

重建架構中的 第 6 階段 會驗證，位於重設內容索引之信箱資料庫上的每個信箱現在可傳回有效的搜尋回應。此目標可藉由利用包含於 Test-ExchangeSearch 指令程式中的核心功能來達成。只有在所有信箱向指令程式傳回 真 回應，才可完成最終驗證作業。

範例：

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 內容。在部分情況下，將所有結果以 CSV 儲存以供參考之用的作法非常實際。

向 Test-ExchangeSearch 測試通報為 假 的任何使用者信箱會視為 1-off 問題，並適當地受到修復。

第 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