使用微軟檢索服務器檢索
Krishna NareddyWindows NT 查詢小組
微軟公司
1998年1月30日
介紹：
這是用來幫助你理解和有效部署Microsoft研究方法系列文章的第三篇，這些文章用在你的Web站點和企業內部網上。第一篇文章：《研究方法剖析》，用來幫助你理解滿足站點需要的搜索方案；第二篇文章：《Microsoft檢索服務器介紹》，介紹了檢索服務器的特點和功能。本篇文章目的是使你理解，管理和優化此檢索器。它有助於把Microsoft檢索服務器的文獻方便地交叉引用。
檢索服務器目錄包括了檢索基礎結構的所有方面。因此我們從目錄開始理解它的結構。下面我們深入探究檢索過程。當檢查過程的每一步時，你將被帶入控制和標準化它所需的細節之中。於是你就得到了幫你使用檢索服務器和監控其狀態和表現的介紹。當你讀完此文章，你會較好理解檢索過程，以及如何調好狀態，診斷，解決普通問題。
此文章中的信息適合於和Microsoft Windows NT® Option Pack 4.0一起發佈的Index Server 2.0。大部分亦可用於將要和Windows NT 5.0一起發佈的Index Server 3.0 ，但差別還是有的。這些差別將在Index Sever 3.0最終發佈後的更新文章中涉及。
目錄：
一個檢索服務器目錄把所有用來使用和檢索你的文獻全集的細節，以及文獻索引都包含了進去。它包括一套有關文獻集合的目錄，一個儲存已編輯完全的文本檢索的目錄索引，一個儲存文獻資源的特性緩存器，一個用來優化檢索過程的控制特性裝置。關於目錄的所有信息以下面的關鍵字保存在註冊表中。所有的註冊參數，除非特別指明，都和此關鍵字有關。許多參數可被位於Catalogs/<catalog>下的索引目錄關鍵字的次關鍵字目錄所替代：
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/ContentIndex
Upon successful creation, Index Server 2.0 creates a default catalog named “Web”.
創建成功之後，檢索服務器2.0 生成一名爲“Web ”的默認目錄。
資源目錄：
這是一個目錄集合，它的所有內容都被包括進了文獻全集。目錄可以是本機的物理路徑或符合通用命名規範（UNC）的遠程路徑。查詢時，目錄集可用來限制查詢範圍，以及幫助完成完整路徑名（或UNC 名）的文件匹配，這樣使文件流覽器能定位它們。因爲目錄集是用來限定檢索服務器查詢範圍的，故而檢索服務器文獻中常用“範圍”這個術語來代替目錄集。
和檢索有關的目錄列在Catalogs/<catalog>/Scopes 下的索引目錄關鍵字的次關鍵字中。在次關鍵字目錄中的變量代表待查目錄，以及變量fixup,domain/user,flags。一個fixup 是路徑的前綴，當遠程客戶發送查詢時，它用來替代目錄。當檢索服務器檢索遠程目錄的文件時，變量domain/user 用來登錄入目錄。標誌域（flags）用來指明檢索是否被包括或排除，以及它是虛擬的還是真實的目錄。設置此標誌域如以下變量組合所示。舉例說明，若檢索物理目錄，標誌域置5（1和4組合）。
0= 目錄不檢索（排除）
1= 目錄檢索（包括）
2= 目錄是虛擬路徑
4= 目錄是實際路徑
資源高速緩存：
它是優化加速常用特徵檢索的本機磁盤存儲器。存入緩存的資源分爲以下幾類：
檢索服務器限定的僅供內部使用的資源。你不能直接控制這些資源。
檢索服務器限定的頻繁使用的資源，諸如路徑和文件名等。這些資源是在文件收集進程中獲取文檔的特徵。
檢索服務器限定的，在文件過濾進程中從文檔中獲取或創造的資源。比如文檔題目和文檔作者等資源(對於HTML和Microsoft Office文檔)。
從文檔中獲取的用戶限定的資源。若文檔中僅有自定義資源，對響應檢索是不夠的。那些所感興趣的自定義資源就應該添加到資源高速緩存裏，以便在獲取結果時能夠找到。那些能直接從文檔中獲取的自定義資源是和文檔有關的OLE資源。檢索服務器能不使用文檔過濾器直接獲取OLE資源。然而考慮效率時，你應考慮緩存的OLE資源及非OLE的自定義資源。詳述怎樣檢查可用資源的完整列表和更改儲存資源的設置列在監測狀態和運行情況的部分。
因爲資源高速緩存包含了每個待檢索文檔的資源，所以它是一個可以和檢索內容大小相比較的物理實體。它相當的大，通常不能全部裝載在主存之中。因此，它只能部分的在需要時按頁調入內存。每一部分是64K大小。你可以通過資源儲存映射高速緩存的登記參數來控制這些能同時載入內存的最大頁數。裝載的部分越多，執行程序時就越好。當然，你也應該爲使用更多的物理內存(RAM)而破費。
當每次文檔進行添加，刪除和修改操作時，資源高速緩存都要被更改。所有的這些修改發生在載入內存的頁面，如果這些頁面不重入磁盤，資源儲存器就發生混亂。當檢索服務器突然終止時，它將發現資源高速緩存和檢索內容不一致。假如這種情況發生，高速緩存將恢復爲最近一次已知的正常狀態。需要恢復的信息存儲在資源高速緩存的備份文件中。備份文件部分決定了資源高速緩存的重入磁盤頻率。備份文件越大，資源高速緩存重入磁盤次數越少。備份文件的大小以操作系統的頁數來度量，可由PropertyStoreBackupSize這個註冊表參數來控制。操作系統頁面大小依賴於處理機結構，可由Windows NT來限定。因爲對不同處理機而言，操作系統頁面大小會有所不同，故而相同的備份大小參數產生了不同大小的生成文件。
內容檢索
內容檢索包括了從文檔中獲取的全部純文本信息，這些文檔在查詢時被編排爲高效匹配方式。它分佈在幾個文件中，而這些文件又在一個特殊的路徑catalog.wci中。這個路徑不能被分在多個驅動器中，應該放在一個固定的(即不可移動的)的本地驅動器中。當這個目錄被定義時，這個路徑的位置應該被詳細說明，即創建完全的路徑。假如你選擇直接修改位於Catalogs/<catalog>註冊表項次關鍵字的位置參數，務必使限定的目錄在最低層包括catalog.wci目錄。在catalog.wci路徑裏不應包含任何別的路徑，因爲它們是不被檢索的。更重要的是，當通過管理工具刪除這個目錄時，在catalog.wci下創造的路徑也將被刪除。
在某些形式下，內容檢索包含了你的研究材料的完整概要。任何訪問這個路徑的人都能從檢索的文件中得到一部分信息，並且能通過Windows NT的文件訪問機構重新建立那些不能訪問的文檔。你應該保護你的catalog.wci路徑，運用適當的安全許可，防止別人濫用
控制屬性
檢索服務器支持多級目錄的創建和使用。儘管每個目錄不同，他們仍共享許多共有控制屬性。複製那些相同的部分是一種浪費，並且容易出錯。因此，所有影響檢索服務器目錄操作的控制屬性在覈心位置是可用的。目錄可以通過複製特定的屬性來選擇不同的方面。例如，假如一個目錄並不選擇存儲每個文檔的概要，它就可以在它的影響範圍內設置相關的屬性。當檢索服務器需要知道是否一個給定的目錄支持文檔概要，它首先檢查這個目錄。假如從目錄中那些屬性不能直接地使用，它就使用全局屬性變量。全局屬性變量是和ContentIndex關鍵字有關的，而特定的目錄項和ContentIndex key下的Catalogs/<catalog> subkey有關。
控制屬性能被劃分爲以下幾組。爲方便起見，只有與檢索相關的註冊表參數才被劃分。檢索服務器文檔提供了對這些註冊表參數的詳盡描述，以及默認值和應用最小/最大範圍。
與過濾相關的參數控制過濾過程的多個方面。它們是DaemonResponseTimeout, FilterContents, FilterDelayInterval, FilterDirectories, FilterFilesWithUnknownExtensions, FilterRemainingThreshold, FilterRetries, FilterRetryInterval, MaxFilesizeFiltered,和 MaxFilesizeMultiplier.
與語言相關的參數列出了相對於每種安裝語言的資源細節。InstalledLangs登記參數列出了語言安裝的設置。在InstalledLangs變量中的每個字符串以ContentIndex/Language關鍵字下的次關鍵字命名。在每個語言關鍵字下，可用的參數是SAPIDefaultErrorFile, ISAPIHTXErrorFile, ISAPIIDQErrorFile, ISAPIRestrictionErrorFile, Locale, NoiseFile, StemmerClass, and WbreakerClass。
與索引合併相關的參數控制建立主索引的過程。它們是MasterMergeCheckpointInterval, MasterMergeTime, MaxFreshCount, MaxIdealIndexes, MaxIndexes, MaxMergeInterval, MaxWordlistSize, MinDiskFreeForceMerge, MinMergeIdleTime, MinSizeMergeWordlist, and MinWordlistMemory。
與資源高速緩存相關的參數控制高速緩存可用的內存和提交給磁盤的頻率。它們是PropertyStoreBackupSize and PropertyStoreMappedCache。
CPU management parameters control the amount of CPU available to perform specific tasks. They are ThreadClassFilter, ThreadPriorityFilter, and ThreadPriorityMerge.
CPU管理參數控制可執行特殊任務CPU的數量。它們是ThreadClassFilter, ThreadPriorityFilter, and ThreadPriorityMerge。
上面沒有提到的其餘混合參數與檢索相關的。它們是EventLogFlags, GenerateCharacterization, IsapiDefaultCatalogDirectory, IsIndexingNNTPSvc, IsIndexingW3Svc, MaxCharacterization, NNTPSvcInstance, 和 W3SvcInstance.
檢索過程
一種枚舉機制決定着列在目錄下的所有可檢索文件，並把它們追加到一隊列。文檔過濾器打開每個隊列文件，並給出包含在內的文檔資源及內容。過濾器給出的文本流進入字符管理器，它可以識別文件流中的字符及數字特性。獨立於停止表（干擾詞彙列表）的特性最終被編爲一用來解決疑問的主索引。
主索引的生成是一個多步過程，從文檔中取出的單詞逐步地從暫住內存的詞彙表移往一箇中間的相關陰影索引表，並且最終到可高效解決索引問題的永久性主索引表。這種多步過程使檢索處理機可快速找到被過濾的文檔，就象是逐漸向永久性主索引表靠攏。詞彙表、陰影索引表、主索引表的集合被看成是內容檢索。通過組合幾個資源索引成一個目標索引，把中間數據結構轉變爲最終形式的催化過程稱爲合併。這是一個時間和磁盤輸入輸出都密集的過程，但它亦是必要的。因爲結果比發生它的資源要有效的多。索引服務器提供了幾種控制合併過程的方式。稍後介紹。
除了完整文本內容之外，過濾器還從文檔中獲得資源。這些資源將被存儲在被優化處理的資源高速緩存中。檢索服務器使用資源高速緩存來分解檢索，以及從資源存儲中回收匹配文檔的待索資源。
在這部分中，我們將詳細的討論怎樣控制檢索過程的每一步。
文檔收集
檢索服務器通過掃描和消息爲檢索收集文檔。掃描是一個循環的過程，它通過檢查所有包含的路徑來決定應該檢索哪個文檔。在Windows NT控制的文件被修改時，它將發送消息。在任何可能的時候，檢索服務器都依靠消息，因爲這種結構比特定的掃描更有效。
檢索服務器執行兩類掃描—完全掃描和遞增掃描。完全掃描得到所有文檔的清單，一般當路徑首先添加時執行它。其他執行完全掃描是在嚴重崩潰的恢復時。
當檢索服務器關閉時，它不能跟蹤文檔的變化。重啓時，它需要知道當它不工作時被修改的文檔情況，這樣它才能更新它的索引表。遞增掃描有能力偵測到所有需要重新過濾和檢索的文檔。在啓動時，檢索服務器在所有路徑裏執行遞增掃描。即使檢索服務器丟失了變化信息，遞增掃描仍可以執行。假如文檔的修正率很高，或緩衝區用來獲取從Microsoft Windows NT的發出的溢出信息，這種情況就可能發生。
你應該在任何檢索路徑中使用完全掃描和遞增掃描。當安裝了一個新的過濾器，刪除一個過濾器或修改一個過濾器的註冊信息之後，應該使用完全掃描。你也可以因爲任何別的原因而使用掃描，但是應注意完全掃描將導致在目錄中的所有文件被重新檢索，這將耗費大量的時間。如何初始化掃描的細節見狀態的性能監測部分。
在檢索服務器的普通操作中，假如檢索的目錄運行在Microsoft Windows NT下，目錄中所有文檔的改變都將被自動的跟蹤。注意一個目錄可指向一個網絡目錄。這些網絡驅動器可以在諸如Novell NetWare或Microsoft Windows 95文件服務器等系統下運行，這些系統並不支持變化的消息。爲了處理這種類型的目錄，檢索服務器對共享部分進行週期掃描。你可以通過註冊參數ForcedNetPathScanInterval控制掃描週期的頻率。
文檔過濾
文檔是由多種格式組成。檢索服務器不可能知道所有的文檔格式，或限制在一些衆所周知的格式。因此，檢索模型允許即插方式，也就是從許多格式中得到內容的過濾器。從一個文檔中得到文本內容的過程叫作過濾。安裝在檢索服務器上的默認過濾器能處理Microsoft Office格式的文檔(Microsoft Excel, Microsoft Word, and Microsoft PowerPoint)、HTML 3.0或更低版本、文本文檔和二進制文件。可以添加別的過濾器，或通過修改註冊表取代已存在過濾器。檢索服務器文檔詳細的說明了怎樣修改註冊表來改變過濾器的DLLs。使用附加的工具，FILTREG(不需要參數)能得到過濾器的列表和列在註冊表下的附加項。使用附加工具，FILTDUMP(使用-?)能夠知道過濾器(與文件的擴展名有關)將什麼內容報告給了檢索服務器。
當檢索服務器準備過濾一個文件時，它能通過檢查文件的擴展名知道文件的格式。註冊表包含了文件擴展名與過濾器DLLs之間的聯繫。檢索服務器使用這種聯繫來決定哪個DLL適合給定的文件。並不是所有的擴展名都在註冊表裏列出。檢索服務器怎樣處理未知擴展名的文件？你可以通過註冊參數FilterFilesWithUnknownExtensions來控制。在設置時，這個參數使檢索服務器以默認的簡單文本過濾器過濾文檔。
你的資料中可能有幾個“二進制”文件。在檢索服務器過濾的環境中，二進制文件包含了一些對於檢索無用的原文信息。你能識別這些文件，而且能使它們被一些名義上的過濾器所過濾。這樣能獲得簡單的文件屬性，如文件大小和文件名，因此，你仍然能通過尋找它的屬性來找到二進制文件。你可以在你的資料中確定出所有的二進制文件，也可在註冊表中確定擴展名。例如，擴展名是“.nul”的二進制文件類型，用二進制文件的默認字符串變量BinaryFile添加一個.nul的次關鍵字，如下所示。
HKEY_LOCAL_MACHINES/Software/Classes/.nul = REG_SZ BinaryFile
一個過濾器不能過濾的文件，可以嘗試多種方法來過濾它。註冊表參數FilterRetries控制過濾方法的最大數目。假如一個文件用已有的方法不能過濾，那麼它就是不可過濾的。文件也可以不經過濾而保留，因爲它們是損壞的。當過濾器發現一個損壞的文件，它就在事件日誌中寫下此事件。你可以打開檢索服務器的管理頁，爲不可過濾頁發出一個請求。這個請求將列入所有的非過濾文件。注意，有口令保護的文件是不能過濾的。你可以通過使用註冊表裏的EventLogFlags變量來控制產生與過濾相關的事件記錄消息。檢索服務器文檔詳細闡述了怎樣配置這個參數。
檢索服務器使用了一個子進程CiDaemon來過濾文檔。這個進程牆保護檢索服務器進程CiSvc免除能破壞相關進程的易產生錯誤或有害的過濾器DLL。檢索服務器給子進程提供一個待過濾文件表。過濾進程過濾這些文件，並給檢索服務器進程提供內容。若過濾進程因某種原因而終止，父進程CiSvc將自動終止它。
若一文檔在過濾時和其文件大小相比給出了太多數據，檢索服務器通過終止此過濾過程來免受侵害。多少數據纔算過多呢？你可通過註冊表參數MaxFilesizeMultiplier來控制。
你可通過註冊表參數ThreadClassFilter和ThreadPriorityFilter來控制過濾過程的步速。
詞法分析
從每個文檔中獲取的文本可以是任何語言的。檢索服務器2.0支持的語言有英語、漢語、法語、德語、朝鮮語、西班牙語、意大利語、荷蘭語、瑞典語和日語。對於每種支持的語言，檢索服務器提供了下面討論的所有工具。你可以只安裝你感興趣的語言，檢索服務器使用國別信息來識別文檔所用的語言，並且可以選取適合此語言的詞彙工具。文檔的默認國別是文檔所處的服務器的國別。使用MS.Locale meta tag可以使個人的HTML文件突破此默認值。
從文檔中得到的原文被一個詞法處理器操作，它可以識別文本流中的詞彙。但是，檢索服務器2.0不允許安裝自定義的處理器。不然的話，你就可以控制被處理器所識別的詞彙，短語，數字和其它特徵。
文檔通常包含了幾個經常出現的單詞，這些單詞在區分文檔是並沒有太大的作用。檢索中指定特殊詞的意義在於可把包含這些詞的文檔（它們對用戶有潛在興趣）和其餘文檔區分開。如果一個常用詞，如“this”，出現在檢索中，就有可能匹配資料中所有的文檔。因此，“this”就沒有什麼區分意義，故被稱爲干擾詞。大多數查找方法允許你從檢索中排除掉這些干擾詞。干擾詞列表也稱爲停止列表，因爲它們阻止了干擾詞進入索引中。但哪些可作可接受的干擾詞？你應能從你的用戶目的及資料主題範圍來確定。例如，在包含有C++代碼的文件中，因爲“this”在C++程序中有特定意義，所以不能把它放入停止列表。如果你不能確定一個詞是否可作爲干擾詞，你最好小心謹慎不把它放入停止表。
干擾詞的明智抉擇提高了檢索文檔集合的質量，進而提高用戶對你檢索方法的滿意度。因爲干擾詞經常出現，所以在索引中剔除它們可明顯地減小索引大小。較小的索引可提高檢索服務器的性能。值得注意的是，這個較高的性能只是停止表的可取的副作用。對檢索方法的用戶經驗纔是主要目的。
除去幹擾詞只發生在文件過濾時。如果你在已建立索引時更改停止表，則檢索服務器重起後會影響已過濾的文檔。要想從修改的停止列表受益，必須重新掃描所有的目錄。
檢索服務器Language/<language>下的註冊表參數NoiseFile標明的一個文件中得到所有的干擾詞，這個參數是ContentIndex下的次關鍵字。
詞彙表的生成
一旦文檔被詞彙處理器過濾處理，結果詞彙被放入詞彙表。詞彙列表是暫時的內存索引，爲較少的文檔作爲高速緩存數據。任何給定時間，內存中都有幾個詞彙列表。你可使用詞彙表來從事經典的內存與速度的權衡問題。MaxWordLists與MaxWordListSize這兩個參數控制着可被詞彙表所用的最大內存。MaxWordLists是在初始化把數據放入陰影檢索的陰影合併前，檢索服務器可在內存中維繫的最大詞彙表數。MaxWordListSize是內存可用來容納詞彙表的最大量。當詞彙表所用內存增加時，將導致檢索服務器基於磁盤的陰影合併次數減少。相反，減少詞彙表可用內存，使磁盤操作增多。其他兩個參數，MinWordlistMemory與MinSizeMergeWordlists幫助控制詞彙表所用內存。MinWordlistMemory是詞彙表生成所用的最小空閒內存量。MinSizeMergeWordlists是激發陰影合併的詞彙表的最小組合大小。
陰影索引的生成
當詞彙表的數目超過了MaxWordLists或所耗內存超過了MinSizeMergeWordlists，就應做陰影合併。作爲內存中的數據，詞彙表可快速編輯，同時不能被很好的壓縮。也不能倖免於檢索服務器的關閉和重起。持久數據解決了這些問題。朝這方向的第一步是陰影檢索的生成。陰影檢索是由合併詞彙表或合併陰影索引爲一個索引所生成的持久性索引。
生成陰影索引的過程稱爲陰影合併。這種快速操作始終作用於詞彙表，清除所佔內存。陰影合併所用的資源索引通常是詞彙表。但是，如果陰影索引的總數超過了MaxIndexes，其中一些也會陰影合併的資源索引。
一種特殊的陰影合併，叫做退火合併（annealing merge），是在系統空閒超過一定時間和相關索引次數超過MaxIndexes時執行。註冊表參數MinMergeIdleTime確定了時間片內（由註冊表參數MaxMergeInterval控制）必須空閒的處理機時間百分比，這樣激活退火合併。退火合併通過減少陰影索引次數來提高索引性能以及所用磁盤空間。
主索引的生成
主索引是索引服務器生成的所有詞彙表的最終目標。這是一個壓縮的相當好的持久數據結構，用來有效地解決索引問題。主索引從所有的已存在的陰影合併生成，當前進程內的主索引稱爲主合併。主合併是一個相當消耗時間和磁盤輸入輸出的操作。當合並完成時，資源被釋放，中間的陰影索引被刪除。最終，檢索速度比以往有所提高。
主合併作爲一個佔用資源密集的進程，必須有相當好的魯棒性，以使環境可控。可通過註冊表參數ThreadPriorityMerge來控制索引過程的步速。如果你對當前步速不滿意，可不顧進行的主合併就停止索引服務器，並更改這個參數。當索引服務器重起時，合併會繼續進行。主合併還可以倖免於一些不可預料的事件，如磁盤滿或突然系統中斷。重啓後，主合併從以往停留出開始。索引服務器在主合併啓動，重啓或停止時，把事件寫到事件日誌中。
你可以通過控制不同的參數來觸發主合併的啓動。主合併因下列原因而啓動。
主合併的日常維護。每日可在特定時間進行。註冊表參數MasterMergeTime，指午夜後應發生合併的分鐘數。默認是午夜進行。這個值應調整到服務器負載最小時。
從上一次主合併以來更改的文檔數稱爲FreshCount。FreshCount越大，以詞彙表形式所用的內存就越多。可通過註冊表參數MaxFreshCount來控制FreshCount的最大值。當FreshCount超過MaxFreshCount時，就執行主合併使FreshCount減爲零，這樣減少了索引服務器所用內存。調整MaxFreshCount時要基於所擁有的內存。MaxFreshCount越大，就假定了有充足的內存，索引速度亦更快。
詞彙表佔內存空間，而陰影索引佔磁盤空間。對於大型或動態的資料集，可能有很大的磁盤空間被陰影索引暫時佔用。爲避免磁盤滿問題，應通過註冊表參數MinDiskFreeForceMerge來控制陰影索引所用的磁盤空間。目錄驅動器上的磁盤空間小於MinDiskFreeForceMerge和陰影索引所佔的累積空間超過MaxShadowFreeForceMerge時，主合併就被啓動。
當陰影索引所佔的磁盤空間超過註冊表參數MaxShadowIndexSize時，亦啓動主合併。這種條件比前者有較高的優先級。
最後，你可採用管理工具來強加一主合併。在期望高檢索負載時，適合這樣做。儘管主合併資源佔用密集，但最終結果提高了索引響應時間。
監測狀態和性能
有三種方式可管理索引服務器—使用Microsoft Management Console (MMC)的索引服務器snap-in；使用索引服務器管理頁（爲索引服務器程序組提供）；使用註冊表編輯器如RegEdit來直接編輯。使用MMC snap-in也許是三者中最簡單的。它也是推薦用的工具，因爲未來的基於Windows NT的管理工具將是基於MMC的snap-ins。你可在便捷的同時有一個領先的開端。這三個工具都允許管理遠程服務器上的索引服務器。我們在此文中只討論索引服務器的MMC snap-in。
使用snap-in，你可以完成以下任務：
創建和刪除目錄
啓動和停止服務
監視所有目錄的狀態
在路徑中初始掃描的同時增加和刪除路徑
修改在高速緩存中存儲資源的設置
在安裝成功後，在位於Windows NT選項壓縮程序組下的“微軟檢索服務器”程序組中，檢索服務器創建一個標爲“檢索服務器管理者”的項目。你可使用此項目來啓動檢索服務器snap-in。也可以使用“Add/Remove Snap-in …”菜單來單獨把檢索服務器snap-in加載入MMC，此菜單項位於Console主菜單項下。點擊Add Standalone Snap-in對話框的Add…鈕，同時從列表中選取檢索服務器。
目錄管理
通過snap-in生成目錄簡單。只需提供目錄名和標出索引文件位置。稍後你可添加路徑和修改資源高速緩存。Snap-in存儲了註冊表中目錄的所有細節，並且在特定的位置生成一名爲catalob.wci的物理路徑。目錄刪除則更簡單。右擊目錄圖標，請求刪除。這使得snap-in清除掉註冊表中的所有項目，刪除catalog.wci路徑。如果目錄被刪除時檢索服務器正在運行，snap-in在物理刪除條項和文件前等待其停止。
路徑管理
一旦你創建了一個目錄，你可以定義你的資料。檢索服務器2.0支持由Web服務器，網絡新聞傳送協議(NNTP)服務器，Windows NT操作系統等管理的內容。你可使用snap-in從這些資源中任一個中獲取內容。
爲了包括由Web和NNTP服務器管理的內容，打開目錄的資源對話框，選擇Web標籤。假如你要檢索一個Web站點，就檢查跟蹤虛擬的基本段，以及選擇你要跟蹤的虛擬服務器。假如你要知道一個NNTP站點，就檢查跟蹤NTTP的基本段按鈕，以及選擇你要跟蹤的NNTP服務器。
爲了獲取被Windows NT文件系統管理的文件內容，可打開文件夾，找到下一級文件夾。通過添加路徑的對話框來添加路徑，這個對話框可在下一級文件夾下右擊打開。對話框也允許你選定遠程路徑。
屬性高速緩存管理
如果你的文檔中有要回收到結果集或在屬性變量索引中用到的標準屬性，這些應爲屬性高速緩存所知。使用檢索服務器snap-in，可以觀看所有的已知屬性和其定義，還可從高速緩存添加或刪除屬性。檢索服務器工作時應能使已知屬性可被枚舉。
所有的高速緩存屬性在Cached Size列中有一個非零值。有空列的或有零值的屬性不被放入高速緩存。打開你感興趣屬性的“Properties”對話框。爲把屬性放入緩存，檢查“Cached”框，給屬性提供大小。除了字符串屬性，大多數的數據類型有一個固定大小，所以很容易確定此項。對於超出特定大小的字符串屬性，檢索服務器會處理此溢出。這意味着你不必爲字符串屬性類型設置最大值。只需選一平均值。選一較大值浪費空間，並導致運行效率低。選擇較小值並不浪費空間，但因爲過多的溢出處理而降低效率。
關於字符串大小的討論是更爲重要的，因爲安裝在檢索服務器2.0上的HTML過濾器僅僅將HTML元標記變量作爲字符串報告。典型的Web站點的資料大多都是HTML文檔，因此包含HTML文檔的定製屬性將被作爲字符串報告。對於每個字符串來說，明智的大小選擇是使其在執行是有比較明顯的區別。
當你對緩存屬性作了所有的更改，使用Commit Changes的菜單選項提交這些變化。這個菜單選項在Task菜單下，此菜單是在右擊“Properties”子文件夾後彈出的子菜單的一部分。提交使更改有效。檢索服務器生成新的屬性高速緩存，爲每一個緩存屬性提供空間，並把已存在的緩存屬性值複製到新的緩存的每一個已被檢索過的文檔中。此過程相當費時，因此應減小提交的屬性緩存數。可採用批處理所有的修改以及以一個單獨的部分提交它們。
一個文檔過濾器在過濾中獲取屬性。因此，當你往高速緩存屬性設置中增加新的屬性時，所有以前過濾的文檔的屬性將是空值。只有以後過濾的文檔才能從過濾中獲取適當的值。這將導致不正確的結果設置，因爲用戶希望非空的屬性值實際上是空的。爲了避免這種情況，你必須在所有的路徑下進行一次完全掃描，以便它們被重新過濾。通過Task菜單選項可以進行掃描，當你在選中的目錄上單擊右鍵時，就回彈出這個菜單。假如你的提交只能使已存在的屬性從高速緩存中去掉，你就沒什麼可做的了。那些不必要的屬性已經從高速緩存中去掉了，以後也不會再放入緩存中。
監測執行
對於過濾進程和檢索進程，檢索服務器提供了執行計數器。這些計數器能在Windows NT監控程序perfmon.exe中使用。
與過濾相關的計數器被兩個進程分開了。這種追蹤文件進程的計數器在內容檢索對象下。它們是過濾文檔的#，被過濾的文件，文檔的整個#。這種計數器直接和內容檢索過濾對象下的過濾相關。它們是每毫秒的綁定時間，每小時的過濾速度，和單位爲兆字節每小時的總過濾速度。
與檢索和合並相關的計數器在內容檢索對象下。它們是以兆字節計算的檢索大小，持久檢索的數量，合併進程百分比，和在內存中詞彙列表的數目。
事件記錄日誌的消息
檢索服務器的系統錯誤將被報告到Ci過濾服務和Ci服務目錄下的Windows NT應用事件記錄日誌中。報告的包括過濾問題，超出資源使用範圍，檢索文件損壞等等。檢索服務器的文檔包括了一個所有消息的詳細列表以及合適的操作。
目錄設計
通過檢索服務器的 snap-in創建和刪除目錄是一件很容易的事。但這並不是想象的那麼簡單。除非你創建一個原樣的檢索方法或以一個小的文檔資料工作，否則你需要花一些時間設計你的目錄和一些配置，比如使用，運行，大小和維護。下面關於選擇硬件，決定單個和多個目錄，目錄增長的討論涉及檢索服務器很多具體的主題。大多數主題也許將應用於任何基於Windows NT的服務器，雖然它們很重要，但不在這裏一一討論。你可以在位於Windows Resource Kits下的MSDN庫的其餘部分找到關於這些主題的討論。
硬件配置
檢索服務器能有效的使用多個處理器和大量的RAM。它佔用的資源越多，工作的情況就越好。檢索服務器花費很多磁盤I/O。在典型的配置中，磁盤I/O比其他因素更能調節全部的檢索過程。磁盤驅動器越快，它們所在的的總線越快，則檢索的過程就越快。你也可以使用磁盤剝離以提高I/O的吞吐量。對你的資料和目錄使用Windows NT File System (NTFS)。這樣做比FAT文件系統更具有可測性，性能和安全性。
什麼是磁盤鏡象？檢索服務器產生的檢索能完全地從註冊信息和資料中得到。因此，磁盤鏡象對資料和Windows NT註冊表並不象對檢索服務器目錄一樣重要。考慮到鏡象爲獲得基於容餘的可靠性會帶來犧牲吞吐，也許此代價不值得。另一方面，鏡象並不減小丟失檢索數據的可能。在服務器停工期不能容忍的環境，這可能是一個足夠好的理由。畢竟，從鏡象磁盤挽救索引比從資料中重新獲得要快得多。
一個目錄或多個目錄？
在任何可能的時候，都應該用一個目錄來代替多個目錄。這樣做有幾個好處。有一些情況下多級目錄是一個較好的選擇，但深入觀察會驅使你選擇單獨的目錄。我們將首先討論使用一個單獨的目錄的好處。然後討論多級目錄有好處的情況。
使用單個目錄的主要優勢是管理簡單化。一個目錄的初始安裝，配置和日常的維護都不要求過多的管理。假如你不得不操作好幾次的話，一些瑣碎的事情會增加工作量。相對於多個目錄來說，處理單獨的目錄並沒有什麼不同。
使用單獨的目錄的另一個優勢是可提高性能，減少工作量。當檢索服務器啓動和運行時，每個活動的目錄被裝載到內存裏。假如分佈在多個目錄中的相同內容被統一在一個單獨的目錄裏。檢索服務器將把資源集中到單級目錄裏，這樣提高了性能。
最後，假如你要使你的資料成爲一個單獨的實體，最好的辦法是使用一個單獨的目錄。檢索服務器2.0並沒有能力從多個目錄裏合併結果的設置。你可以從不同的目錄裏合併結果的設置，並且也可以使用腳本傳送單獨的結果設置，但同時也增加了查詢往返的時間。假如你只有一個單獨的目錄，檢索服務器在內部就處理了排序和合並。這比基於腳本的排序和合並更有效率。
假如你有一份在一個服務器下難以很好運作的巨大資料，就不能使用單個目錄。在這種情況下，一個大範圍的解決辦法，比如Microsoft Site Server Search，要比使用ad hoc 腳本連接目錄要好的多。
一個典型的組織，無論大小，都應該滿足用戶設置的需要。例如，你的組織只有僅供工程部門使用的技術文檔和僅供法律部門使用的法律文檔。這兩種用戶的文檔設置是相互獨立的。很顯然，你只能用一種辦法來解決這種情況，那就是每個部門建立一個目錄。其實完全不必這樣做。檢索服務器允許使用路徑來分割你的資料。你可以使用一個單獨的目錄，以及使用兩個不同的路徑，讓每種文檔設置對應一個目錄，提供相似檢索腳本的兩種不同的設置，每一種情況對應一個合適的路徑。假如涉及到安全性，你也許在文檔中已經擁有了正確的許可。檢索服務器以Windows NT的安全性而聞名，它不允許訪問一些不能訪問的文檔。需要更多的說明嗎？相同的組織也許有第三種文檔設置，即對所有組都有興趣的新文章。當用到多種目錄時，你可以創建第三種目錄，或者在每個目錄裏檢索同一篇文章兩次。然而，使用單個目錄，你只需要一個包含兩種腳本設置的目錄。
假如因爲某種原因你需要在服務器上建立多個目錄，應記住不需要時不把目錄激活。在Catalogs/<catalog> 的子關鍵字下的CatalogInactive參數爲1，使目錄不激活。檢索服務器再次啓動時，交互的目錄將不會被裝載。
假如你的資料相對於你已有的服務器太大，在分割資料到幾個小的服務器之前考慮一更大的規模。獲得合適服務器的代價比多個服務器處理要低。
目錄增長
你的資料大小持續的增加是偶然的。因此檢索服務器產生的檢索必須跟上增長的資料。檢索服務器2.0的重要限制是檢索只能駐留在單個的驅動器裏。假如這個驅動器已滿，即使別的驅動器中剩餘的巨大空間也是不行的。在可預見的將來選擇供索引的足夠空間。那麼到底需要多大的磁盤空間呢？這依靠你的資料原文的大小和你儲存在屬性高速緩存中的的屬性。檢索服務器的默認設置，是預料索引是資料大小的百分之四十。
資料增加的另一個方面新文檔格式的可能引入。當引入一個新的文檔格式之前，一定要確定文檔過濾器對此格式是有效的。
故障排除要點
當你檢索已知存在和包含索引中所用關鍵字的文檔時，會出現大多數的故障特徵。如若沒發現文檔集，則採用如下故障排除算法。使用之前閱讀所有的步驟。稍後步驟將更適合你的環境。
查看CI生成事件的應用事件日誌。必要時標處錯誤。
文件是否有導致不被過濾的擴展名？使用過濾器枚舉工具FILTREG來查看檢索服務器在註冊表裏的內容。
文件是否有口令保護？過濾器不能訪問有口令保護的文件。
是否檢索服務器仍在掃描？偶然的情況是丟失的文件不被檢索。等待掃描完成(查看由MMC snap-in報告的目錄狀態)。
檢索服務器在響應查詢時是否返回“Index is out of date”的信息？假如返回，偶然的情況是丟失的文件不被過濾。等待過濾所有的文件。
使用管理頁對未過濾文檔進行查詢。這是一個檢索服務器不能過濾文檔的列表。文件也許有不能識別的擴展名而不能被過濾。或者因爲文件的格式不能識別或文件損壞使過濾器不能過濾。檢索服務器也可以通過掛斷和其大小相比給出了過多信息的文檔，使自己免受危害。
是否所有的文件都來自相同的路徑？假如是，有可能這條路徑不被掃描。檢查確認這條路徑是否被包含路徑的設置所覆蓋。注意如果它們被覆蓋，在catalog.wci下的路徑就不會被過濾。假如一條路徑被覆蓋，檢查它對於如Windows Explorer和Dir等程序是否是可見的。假如一切都正常，在所有影響的路徑中強加一次掃描。
如果包含丟失文件的路徑是一遠程路徑呢？那麼，因不正確的用戶名而也許不被檢索。當選定遠程路徑的登錄ID時，應使用局域/用戶格式輸入局域名和用戶名。注意到如果計數是計算機局域的話，局域名也許實際上是計算機的名字，
在文件裏使用FILTDUMP，並檢查輸出。在轉儲裏所有的關鍵字是否都出現？假如應該出現而實際上並沒有出現，就應該檢查過濾裝置。
假如這些詞彙在過濾器的輸出裏，那麼索引裏有可能不包括它們，因爲它們被認爲是干擾詞彙。檢查干擾詞彙列表，必要是應改變它。
是否不同的語言用來過濾文件和提出查詢？詞彙分析是一個依靠語言的過程。當用一種語言提出查詢，而用另一種語言過濾文檔時，查詢結果是不可預知的。有一些文件格式，比如Microsoft Word，用一種語言標識文檔，這種標識被用在過濾器裏。另外的格式，比如簡單的文本，沒有包含任何語言分類符。對於這些文件來說，大多數過濾器默認爲這些文件所處的系統。查詢的位置用CiLocale的變化來明確。假如CiLocale是不明確的，那麼瀏覽的位置被用作（如果可能）或默認爲服務器的位置。
每個文件都被正確檢索是可能的，但是並不一定能得到所期望的結果，因爲你沒有正確的許可。
也許查詢是不合適宜的，或者檢索服務器認爲過於複雜。在這兩種情況下，你應該接受這種影響而造成的錯誤。參考檢索服務器的文檔來認識什麼時候出現這類錯誤及採取什麼措施去避免它們。
致謝
我要感謝thank David Lee, Kyle Peltonen, Susan Dumais提供的寶貴資料。