建立 Exchange 內容索引重建基準 – 第 2 部分

英文原文已於 2012 年 6 月 27 日星期三發佈!>!>!>

在本系列的第 1 部分，我說明了 E2K7_IndexRebuildAnalyzer.ps1 指令碼 (可能為英文網頁)。而在本文中，我將探討有關 Anatoly Girko 與我所開發的搜尋重建架構。原先設計此架構是要為我們內部作業人員提供一組豐富的驗證步驟以及進度指示，好在進行內容索引重建時可加以運用。 !>!>!>!>

階段 1：重建前的統計數據蒐集!>!>

在我們的環境中，每當決定要重建 Exchange 信箱資料庫的內容索引 檔案時，操作人員的第一個動作就是計算出受影響的存放區之重建前的統計數據。接著會將這些資料寫入 CSV 加以記錄，最後會合併至我們的歷史記錄資料集中。但如之前所述，不一定要使用 -CSVFile 參數。未傳入 CSVFile 參數的情況下，對應的輸出資料將寫入命令介面主控台視窗。為了方便閱讀，建議您調整 螢幕緩衝區大小寬度 和主控台的 視窗大小寬度 ，以便正確容納所有輸出的標題與數據。這樣一來在主控台的作業期間，閱讀起來才不會太吃力。在這裡我通常都會用 -AutoSize (-a) 參數把輸出的資料傳入到 Format-Table (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：確定 Search Indexer 已偵測到需要進行完整編目!>!>

當現有的內容索引檔已從檔案系統移除，且 Microsoft Exchange Search Indexer 服務也隨即重新啟動後，MonitorAndUpdateMDBList 執行緒就會負責判讀已啟用內容索引的信箱伺服器上，所有信箱資料庫的內容索引現有狀態。待 MonitorAndUpdateMDBList 執行緒判定每個信箱資料庫的 內容索引健全狀態 之後，它便會將每個信箱資料庫的健全狀態值放入記憶體中。假如內容索引健全狀態值等於 "New"，代表 Microsoft Search Indexer 服務 已判斷需進行一次 完整編目 ，才能將內容索引檔回復到健全的狀態 (「健全」意謂該索引有透過存放區通知保持更新)。此時，Exchange Search Indexer 服務才會針對受影響的信箱資料庫開始進行 完整編目 作業。!>!>!>!>!>!>!>!>

完整編目 作業實際開始的時間，會註記在應用程式事件記錄檔中，由 事件識別碼 109 代表。!>!>

為確保系統中所有的 完整編目 作業皆已開始，執行工作的操作人員會確認每個內容索引先前在 步驟 2 中重設過的信箱資料庫，是否有出現 事件識別碼 109。 !>!>

範例!>!>

如前例所示，NA1-ERICNOR-1-DB1 和 NA1-ERICNOR-1-DB18 的內容索引檔，已利用 ResetSearchIndex 指令碼重設過。若要確認 Microsoft Exchange Search Indexer 服務已開始完整編目作業，要看看信箱伺服器上的每個信箱資料庫是否有出現一個不重複的 事件識別碼 109。在這裡看來是有的：!>!>!>!>!>!>

Event Type: Information
Event Source: MSExchange Search Indexer
Event Category: General
Event ID: 109
Date: 5/10/2012
Time: 2:22:19 PM
Computer: NA1-ERICNOR-1-A
Description: Exchange Search Indexer has created a new search index and will perform a full crawl for the Mailbox Database NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).!>!>

Event Type: Information
Event Source: MSExchange Search Indexer
Event Category: General
Event ID: 109
Date: 5/10/2012
Time: 2:22:20 PM
Computer: NA1-ERICNOR-1-A
Description: Exchange Search Indexer has created a new search index and will perform a full crawl for the Mailbox Database NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).!>!>

注意 ：除了用眼查看事件記錄檔以外，還有另一個可用的技巧，那就是使用 Get-EventLog (可能為英文網頁) Cmdlet，將 Start 事件寫入 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\Number of Databases Being Crawled
• MSExchange Search Indexer\Number of Indexed Databases Being Kept Up-to-Date by Notifications
• MSExchange Search Indices\<DB Instance Undergoing Crawl>\Full Crawl Mode Status
• MSExchange Search Indices\<DB Instance Undergoing Crawl>\Document Indexing Rate
• MSExchange Search Indices\<DB Instance Undergoing Crawl>\Number of Mailboxes Left to Crawl
• MSExchange Search Indices\<DB Instance Undergoing Crawl>\Number of Recently Moved Mailboxes Being Crawled
• MSExchange Search Indices\<DB Instance Undergoing Crawl>\Number of Outstanding Batches
• MSExchange Search Indices\<DB Instance Undergoing Crawl>\Throttling Delay Value !>!>
• !>!>
• !>!>
• !>!>
• !>!>
• !>!>
• !>!>
• !>!>

藉由查看 MSExchangeSearchIndexer 物件，操作人員可以輕易地判定伺服器上有多少內容索引已更新，又有多少目前正在進行編目。待信箱伺服器完全更新後，"Number of Databases Being Crawled" 計數器的值將永遠等於 0，且 "Number of Indexed Databases Being Kept Up-to-Date by Notifications" 計數器的值會等於伺服器上啟用進行內容索引的信箱資料庫數目。!>!>!>!>

在我的例子中，我的信箱伺服器上總共有 18 個信箱資料庫，其中有兩個正在進行 完整編目 。因此，"Number of Databases Being Crawled" 的值應等於 2，而 "Number of Indexed Databases Being Kept Up-to-Date by Notifications" 應等於 16，也就是：!>!>!>!>

待個別信箱資料庫完成 完整編目 後，系統監視器中的幾個物件計數器將會出現一些特定的變化。!>!>

在 MSExchange Search Indexer 部分： !>!>

• "Number of Databases Being Crawled" 計數器的數值會減 1
• "Number of Indexed Databases Being Kept Up-to-Date by Notification" 的數值會加 1。 !>!>
• !>!>

在 Mailbox Database Index/indices 的部分：!>!>

• 此特定資料庫上的 "Full Crawl Mode Status" 值會減為 0 (反映出由 MonitorAndUpdateMDBList 監視器執行緒所決定之 內容索引健全狀態 的新值)。
• "Number of Mailboxes Left to Crawl" 的值應會反映為值 0。
• 雖然和 完整編目 重建作業本身並沒有直接關係，但每個索引的 "Number of Recently Moved Mailboxes Being Crawled" 計數器的值也應該為 0。當 Exchange 信箱在 Exchange 信箱資料庫之間成功移動後 (假定目的地有啟用內容索引)，目的地資料庫上的搜尋通知將會暫時停用。Exchange Search Indexer 服務 這麼做是為了對最近曾移動過的信箱進行單次編目，以讓主索引能完全更新到最新內容。待此單次性編目完成之後，存放區通知即會繼續。這裡的重點是，雖然 完整編目 技術上來說已完成，若信箱移動和內容索引重建兩項活動是同時進行，仍有可能出現單次性編目作業。只要此計數器等於 0，代表所有出現在信箱資料庫上的編目活動都已百分百完成了。因此檢查時要注意看看是不是如此。 !>!>!>!>!>!>!>!>!>!>!>!>!>!>
• !>!>
• !>!>

在一個所有內容索引都已更新完成的 Exchange Server 上，您會看到：!>!>

• "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。 !>!>
• !>!>
• !>!>
• !>!>
• !>!>

在我的例子中，所有這些值都 正確 ，因此我可以合理假設索引已重建成功，且從內容索引的角度來看，伺服器完全 健全 ：!>!>

當系統監視器中所有的內容索引看來都更新完成後，負責作業的操作人員接著會繼續檢查應用程式事件記錄檔，確定有看到 事件識別碼 110，代表 Microsoft Exchange Search Indexer 已完成 完整編目 事件。和事件識別碼 109 相似，每個已完成 完整編目 的信箱資料庫，也會出現一個不重複的 110 事件項目：!>!>!>!>

Event Type: Information
Event Source: MSExchange Search Indexer
Event Category: General
Event ID: 110
Date: 5/10/2012
Time: 5:39:47 PM
Computer: NA1-ERICNOR-1-A
Description: Exchange Search Indexer completed a full crawl (indexing) of Mailbox Database NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).!>!>

Event Type: Information
Event Source: MSExchange Search Indexer
Event Category: General
Event ID: 110
Date: 5/10/2012
Time: 5:11:47 PM
Computer: NA1-ERICNOR-1-A
Description: Exchange Search Indexer completed a full crawl (indexing) of Mailbox Database NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).!>!>

注意 ：除了用眼查看事件記錄檔以外，還有另一個可用的技巧，那就是使用 Get-EventLog (可能為英文網頁) Cmdlet，將 Completion 事件寫入 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!>!>

E2K7_IndexRebuildAnalyzer 執行完成後，便可以對 CSV 檔進行檢查了。要確定 CSV 中顯示信箱伺服器上的所有 Exchange 信箱資料庫都已處理完成。有許多 Exchange 信箱資料庫都傳回了 "NoEventsFound" 字串，因為找不到成對的 Search Indexer 事件識別碼。在我們的範例中，有 16 個信箱資料庫回報了 "NoEventsFound"，而有兩個具備有效重建後數據的信箱資料庫：!>!>!>!>!>!>!>!>

還可以在 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 進行大量操作時，ResultFound 和 SearchTime 屬性只有在所有信箱皆處理完畢後，才會出現在主控台視窗 (無論結果為 True 或 False 都一樣)。在某些情況下，將所有結果存成 CSV 以便記錄也會是比較好的選擇。 !>!>!>!>!>!>

任何在 Test-ExchangeSearch 測試期間回報 False 的使用者信箱，都會視為是單次性的問題，並會依此修復。 !>!>

階段 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!>!>!>!>