Share via

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

  • Article

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

 !>!>

在疑難排解 Exchange 內容索引 的可疑問題時，Exchange 管理員通常會採取的第一個動作是重建受影響之信箱資料庫的內容索引檔 (手動重建或使用 \Exchange Server\Scripts 目錄中的 ResetSearchIndex.ps1 指令碼)。多年來我也曾遇過多位 Exchange 管理員，他們選擇每年定期主動預先重建搜尋索引，或在專案過程中的各個里程碑 (比方說在移轉專案過程中) 時主動預先重建搜尋索引。!>!>!>!>

先不論重建索引的理由，若問到大多數的管理員時，都無法確切估計這項程序從開始到結束需要多久時間，而這種不確定性所造成的影響又會依公司而異。有些 IT 部門可能會顧慮工作天期間無法提供使用者伺服器端的索引而卻步，害怕造成使用者生產力下降，增加服務台需應付的問題回報量。 從營運的角度來看，無法確切估計重建時間也可能導致 Exchange 管理員在重建程序期間無法意識到潛在的危險。無論您重建的理由為何，確實估計程序所需時間都是非常重要的一環。!>!>!>!>!>!>!>!>!>!>

不可否認，目前對於要重建 Exchange 內容索引所需的時間，資訊的確非常有限。表面上看起來這是因為重建的實際時間總是不斷變動，但實際上有很多會影響重建速率以及完成時間的因素，最明顯的有：!>!>!>!>!>!>!>!>

  • 位於 Exchange 信箱資料庫的使用者信箱總數不固定
  • Exchange 信箱資料庫內含的信箱大小不固定
  • 位於 Exchange 信箱資料庫的使用者信箱，各自的項目數量不固定
  • 每個 Exchange 信箱資料庫的項目數量不固定 (進行同時重建時)
  • Exchange 信箱資料庫中的項目大小不固定
  • Exchange 信箱資料庫中的郵件附加檔數目及大小不固定
  • Exchange 信箱伺服器上啟用的 IFilter (可用來建立各種檔案格式索引) 類型和數目不固定
  • 信箱伺服器的整體系統資源運用效能低落 (阻塞)
  • 更多… !>!>
  • !>!>
  • !>!>
  • !>!>
  • !>!>
  • !>!>
  • !>!>
  • !>!>
  • !>!>

在 Microsoft (我們的企業實務以及各項 Office-365 產品中)，我們採用了一個由我和同事 Anatoly Girko 所開發的 搜尋重建架構 。原先設計此架構是要為我們內部作業人員提供一組豐富的驗證步驟以及進度指示，好在進行內容索引重建時可加以運用。在整體重建程序的各個關鍵里程碑利用這些技巧，可確保能重建成功。!>!>!>!>!>!>

隨著架構的進化，我們決定增加一些其他的功能，讓我們夠追蹤並儲存所有重建作業的產出數據歷史記錄。而隨著資料集的成長，加上後續的趨勢資料日漸明朗，我們發現我們能提供更詳細更準確的數據，來協助估計一次重建作業所需的時間。如此一來，我們的團隊便可更正確的做出排定重建時程的決定，將使用者受影響的程度降到最低。自此以後在我們支援的各種環境下，本架構在數以千計的內容索引重建作業中都派上了用場。!>!>!>!>!>!>!>!>

在一系列的文章中，我們會討論此 重建架構 ，有需要的人可依自身環境於需要時運用類似的做法。架構的每個階段都有詳細的說明，包括討論我們為協助此程序所撰寫的各種工具集。本系列最後將以一系列詳述我們觀察內容索引重建之統計數據的圖表，以及時至今日的結論作為總結。對於未曾針對此層面追蹤過統計數據的客戶，我們希望這能做為一個實用的參考來源。相信它能幫助您在自身的環境下更準確地估計 Exchange 內容索引重建的時間。不過，它也有可能毫無用處，因為每個 Exchange 環境都是獨一無二的，您的重建數值可能和我們所觀察到列於此處的速率有極大的差異。!>!>!>!>!>!>!>!>!>!>!>!>

在您義無反顧地一頭栽入前，有一點必須先聲明：本系列文章並不是一份疑難排解指南。理想的情況是您依照自己的診斷而決定進行重建，無論是為了解決問題或是做為預防措施。本系列中所呈現的所有範例，皆以 Exchange 2007 為準。我決定在本文中專注於 2007 的原因是，需要重建 2007 索引的可能性和 2010 相較之下高出許多 (2010 和 2007 不同，2010 有能力從健康的備援來源重新植入內容索引，因此需要在多重複本的架構下完整重建索引的機會少上許多)。待相關用途範例收集完全後，我和 Anatoly 將在未來幾週內發佈一篇補充的貼文，提供 Exchange 2010 版本的 內容索引重建分析器 指令碼給各位參考。!>!>!>!>!>!>!>!>!>!>

索引重建分析器指令碼!>!>

在 Microsoft 內部，用來重建內容索引的主要工具集是 IndexRebuildAnalyzer 指令碼。這個指令碼由 Anatoly 和我特別針對建立內容索引重建基準而撰寫。如前所述，此指令碼共有兩個版本：Exchange 2007 版以及 Exchange 2010 版。為了能正確計算統計數據，請一律使用要重建索引的相對應 Exchange 信箱資料庫版本。視操作模式之不同，IndexRebuildAnalyzer 指令碼可以產生兩種類型的數據。我們內部習慣把這兩種模式稱為「重建前數據」與「重建後數據」 (所有屬性皆記錄在以下的＜指令碼參考＞一節中)。!>!>!>!>!>!>!>!>!>!>!>!>

雖然這個指令碼主要用來追蹤內容索引重建作業，但 Exchange 管理員 當然也可以在 重建前模式 下使用此指令碼來計算出各種信箱中心用途的 時間點 (PIT) 統計值 (如您整個組織的「信箱數目」、「資料庫中的物件數量」、「平均信件大小」等)。若能依您自身的業務需求定期運用此工具，它將能提供您更多有關使用者趨勢的觀點與能力。!>!>!>!>

如要取得 E2K7_IndexRebuildAnalyzer.ps1 script (可能為英文網頁) 參數及使用範例，可在執行指令碼前在 PowerShell 工作階段中傳入 -Help 參數。!>!>

下表是各參數的概要說明：!>!>

參數!>!> 必要性!>!> 說明!>!>
-CMS </叢集 1,叢集 2>!>!>!>!> 必要!>!> 使用 -CMS 參數時可計算 Exchange 信箱伺服器或 Exchange 叢集信箱伺服器上的所有資料庫。以逗號分隔伺服器名稱，可計算分佈於多台獨立信箱伺服器或叢集信箱伺服器的資料庫統計數據。!>!>!>!>
-Database <資料庫名稱,資料庫名稱>!>!>!>!> 必要!>!> 使用 -Database 參數可計算特定信箱資料庫的統計數據。使用此參數時，需要以下列格式傳入資料庫名稱：

"信箱伺服器名稱\儲存群組名稱\資料庫名稱"!>!>

以逗號分隔資料庫名稱，可計算多重資料庫的統計數據。!>!>

資料庫若不含任何作用中的使用者信箱則不會被處理。!>!>!>!>!>!>
-All!>!> 選用!>!> 使用 -All 參數可計算 Exchange 組織內所有 Exchange 信箱資料庫的統計數據。!>!>
-CSVFile!>!> 選用!>!> 使用 -CSVFile 參數可將所有數據輸出為 CSV 檔。!>!>
-PostRebuild!>!> 選用!>!> -PostRebuild 參數可用以區分不同的指令碼執行模式。具體而言，呼叫 -PostRebuild 時，指令碼會剖析應用程式事件記錄檔，並嘗試計算索引重建作業的各項效能指標。!>!>!>!>
-Help!>!> 選用!>!> 顯示指令碼說明。!>!>

資料庫的數據標題!>!>

重建前!>!>

如前所述，指令碼的「作業模式」取決於是否有 -PostRebuild 參數。若要取得重建前的數據，不應使用 -PostRebuild 參數。當指令碼定義為重建前模式時，將呈現下列標題及相對應的數據：!>!>!>!>!>!>

標題!>!> 說明!>!>
伺服器!>!> 與處理之資料庫相關的信箱伺服器身分。!>!>
資料庫!>!> 顯示處理之 Exchange 信箱資料庫的名稱。!>!>
EDB 大小 (GB)!>!> 在磁碟上相對應之資料庫檔案的大小，以 GB 為單位。!>!>
EDB 大小 (MB)!>!> 在磁碟上相對應之資料庫檔案的大小，以 MB 為單位。!>!>
信箱數目!>!> 處理之資料庫的作用中 Exchange 信箱數目。中斷連線的信箱不會計入。!>!>!>!>
資料庫：項目總數!>!> Exchange 信箱資料庫中現有的郵件項目總數。!>!>
資料庫：項目總大小 (MB)!>!> 處理之信箱資料庫中現有的所有郵件項目總大小，以 MB 為單位。!>!>
資料庫：平均郵件大小 (MB)!>!> 處理之資料庫中現有的所有郵件項目平均郵件大小。!>!>
每位使用者：平均信箱大小 (MB)!>!> 處理之資料庫現有作用中信箱的平均信箱大小。!>!>
每位使用者：平均項目數!>!> 處理之資料庫中現有作用中信箱的平均郵件項目數。!>!>

重建後 (使用 -PostRebuild 參數)!>!>

使用 -PostRebuild 參數時，IndexRebuildAnalyzer 會嘗試計算出內容索引重建作業的產出量數據。它的做法是藉由剖析 應用程式事件記錄檔 ，算出信箱伺服器上每個信箱資料庫開始重建 (由 事件識別碼 109 表示) 和重建完成 (由 事件識別碼 110 表示) 的時間。若要順利算出重建後的數據，每個已重設相對應之內容索引的信箱資料庫之 事件檢視器 中，都必須存在完整的成對。若沒有成對的，指令碼將無法計算出統計數據。在此情況下會傳回字串 "NoEventsFound"。傳回此字串最常見的原因有：!>!>!>!>!>!>!>!>!>!>!>!>

  • 某一個或某一組資料庫的內容索引重建作業未完成。
  • 應用程式事件記錄檔 已從開頭蓋過或已清除 (最佳作法是將記錄檔大小上限設為所允許的最大值。)
  • 回報 "NoEventsFound" 的信箱資料庫，最近並未重設內容索引 (因此事件記錄檔中不存在那兩個)。您也可以使用 -CSVFile 選項和 Excel，輕鬆地從結果集中過濾掉這些字串。我會在架構的 步驟 5 中說明做法並提供範例。 !>!>!>!>!>!>
  • !>!>
  • !>!>

傳入 -PostRebuild 參數執行指令碼時，所有的「重建前」標題與數據都會一併加以計算。使用 -PostRebuild 參數時會包含下列額外的標題與數據：!>!>!>!>

標題!>!>

說明!>!>

內容索引重建開始時間!>!>

Search Indexer 服務開始 完整編目 信箱資料庫的開始時間。!>!>

內容索引重建結束時間!>!>

Search Indexer 服務完成 完整編目 信箱資料庫的完成時間。!>!>

重建總時間：時：分：秒!>!>

Search Indexer 服務完成 完整編目 信箱資料庫所需的時間，以 時：分：秒 為單位表示。!>!>

重建總時間：分鐘總計!>!>

Search Indexer 服務完成 完整編目 所需的總時間，以 分鐘 為單位表示。!>!>

重建總時間：秒總計!>!>

Search Indexer 服務完成 完整編目 所需的總時間，以 秒 為單位表示。!>!>

重建：每個信箱平均：秒!>!>

每個信箱完成 完整編目 的平均時間，以 秒 為單位表示。!>!>

重建：MB/秒!>!>

Search Indexer 完整編目 的平均產出量，以 MB/秒 表示。!>!>

重建：項目/秒!>!>

Search Indexer 完整編目 的產出量，以 郵件 項目/秒 表示。!>!>

結論!>!>

Exchange 2007 索引重建分析器指令碼可由這裡 (可能為英文網頁) 下載。!>!>

在本系列的第 2 部分中，我會深入探討搜尋重建架構；而在第 3 部分中，我們會再談談到目前為止 Microsoft 的內部觀點。!>!>

Eric Norberg
Office 365 專屬服務工程師
!>!>

這是翻譯後的部落格文章。英文原文請參閱 Establishing Exchange Content Index Rebuild Baselines – Part 1!>!>!>!>