搜尋效能的最佳作法 (Office SharePoint Server 2007)

本文說明一些您可以用來在 Microsoft Office SharePoint Server 2007 中維持狀況良好且有效率之搜尋系統的最佳作法。

本文內容：

• 啟動完整編目的原因

• 監視網頁伺服器

• 監視資料庫伺服器

• 監視索引伺服器

• 使用 SharePoint 診斷監視 Office SharePoint Server

• 使用統一登入服務記錄診斷查詢瓶頸

• 最佳化 SQL Server 的 Office SharePoint Server 2007 搜尋

• 維護 SQL Server 資料庫進行搜尋

• 避免編目程式耗盡

• 避免存取控制清單造成的瓶頸

• 疑難排解遺失的搜尋方塊網頁組件

啟動完整編目的原因

編目大量資訊、文件和網頁及為其編製索引，需要大量電腦處理。編目程序也會耗用網路及其他資源。您必須謹慎設定 Office SharePoint Server 2007 伺服器陣列，以確保編目和編製索引程序不會對提供給使用者的服務造成不良影響。例如，通常會在離峰時間期間 (不常使用伺服器時) 編目及編製索引，以在尖峰時間持續提供服務給使用者。

降低編目影響的其中一個方法是排程累加編目，而不是完整編目。累加編目僅會編製已變更項目的索引，因此程序需要極少的電腦資源。您可以在每個內容來源上排程完整編目和累加編目。例如，您可以考慮在工作日的午夜執行累加編目，並在星期六的午夜執行完整編目。

您應該在下列情況下手動啟動完整編目，以確保索引完整：

• 管理員已將更新或 Service Pack 套用至伺服器陣列中的伺服器時。

• 管理員已將新的 Managed 屬性新增至搜尋設定時。

• 管理員新增或修改了編目規則時。

• 當您要重新編製 Windows SharePoint Services 3.0、Microsoft Office SharePoint Server 2007 或 Search Server 2008 網站上的 ASP.NET 網頁索引時，由於編目程式無法偵測這類網頁的變更，因此只有完整編目可以重新編製索引。

• 發生連續累加編目失敗狀況時。如果累加編目在任何存放庫層級中連續失敗一百次，索引伺服器會將受影響的內容從索引中移除。

• 管理員修復了損毀的索引時。

• 管理員建立了伺服器名稱對應時。

• 當您已變更某些內容的權限，但內容本身未變更，且您並未在伺服器上套用 Service Pack 1 之後的 Hotfix 封裝 (KB941442) 或更新的 Service Pack 時。若沒有此 Hotfix 封裝，累加編目便不會檢查存取控制清單 (ACL)。如果未檢查 ACL，即使自上次完整編目之後，管理員已移除使用者的權限，該使用者仍會看到搜尋結果中的項目。

在下列情況下，Office SharePoint Server 2007 會於排程或手動啟動累加編目之後執行完整編目：

• 管理員手動停止了先前的編目時。

• 管理員從備份還原了內容資料庫時。

  注意

  如果您已安裝 Infrastructure Update for Microsoft Office Servers，即可使用 Stsadm 命令列工具的選項，指定還原作業是否會導致完整編目。

• 管理員中斷後又重新連接內容資料庫時。

• Office SharePoint Server 從未執行過內容的完整編目時。

• 變更記錄不包含編目中位址的資訊時。變更記錄可用於判斷自上次編目之後是否變更過項目。若沒有變更記錄資訊，則不會發生累加編目。

• 用於存取內容的帳戶已變更時。此帳戶可以是預設存取帳戶，或編目規則中指定的帳戶。

• 發生索引損毀時。

您必須仔細考量在這些情況下的動作。這是因為如果您手動或透過排程啟動編目，完整編目可能比累加編目需要更多資源，而影響使用者接收的服務。

監視網頁伺服器

若要提升 Office SharePoint Server 2007 搜尋效能，請完整分析系統。透過完整調查伺服器即可建立基準線。您應定期重新執行效能測試，以及早察覺任何變更並診斷問題。當您執行最佳化時，您可以使用基準線辨別改進的結果。以下小節列出效能監視器計數器，以及其他工具所提供與 Office SharePoint Server 2007 效能相關的資料。

在 Office SharePoint Server 2007 中，網頁伺服器會架設所有網站和網站集合，並取得儲存在資料庫伺服器上的內容，然後回應使用者要求。由於是由網頁伺服器傳送使用者搜尋查詢的回應，因此其效能會直接影響搜尋效能。網頁伺服器也會影響索引，因為編目程式是透過將要求傳送至網頁伺服器來編製 Office SharePoint Server 內容的索引。

若要監視網頁伺服器的狀況，請使用下列效能監視器計數器：

• Processor/% Processor Time/_Total (處理器/% 處理器時間/_Total)

  此計數器是處理器活動的主要指示器，測量處理器在執行非閒置執行緒時所花費的時間比例。如果此計數器的平均值 80% 以上會超過延長的期間，處理器可能遇到瓶頸，此時您應考慮升級。

• Memory/Available Mbytes (記憶體/可用 MB)

  此計數器測量處理序或系統立即可用的實體記憶體。如果此計數器太低，系統會因使用更多分頁而變慢。此時您應考慮為伺服器增加更多記憶體。

• Web Service/Current Connections (Web 服務/Current Connections)

  此計數器測量全球資訊網服務的連線數目。在 Office SharePoint Server 2007 網頁伺服器上，此計數包含所有同時連線的使用者，並在索引期間包含編目程式。使用此計數器可分析使用模式並判斷尖峰時間。此計數器沒有限制。非常高的值可能表示絕佳的效能。

  注意

  在具有多部網頁伺服器的 Office SharePoint Server 伺服器陣列中，此計數器僅會測量一部伺服器的連線。如需如何監視整個伺服器陣列之使用者活動的資訊，請參閱＜使用 SharePoint 診斷監視 Office SharePoint Server＞。

監視資料庫伺服器

Office SharePoint Server 2007 使用 Microsoft SQL Server 2005 或 Microsoft SQL Server 2008 儲存內容資料庫。雖然索引伺服器在檔案系統 (而非資料庫) 上儲存內容索引，但是會在搜尋資料庫中儲存文件中繼資料與權限。由於許多搜尋檢查中繼資料且所有搜尋都涉及安全性調整，因此資料庫伺服器的效能會直接影響搜尋的效能。

若要監視資料庫伺服器的狀況，請使用下列效能監視器計數器：

• Processor/% Processor Time/_Total (處理器/% 處理器時間/_Total)

  此計數器是處理器活動的主要指示器，因此在資料庫伺服器與網頁伺服器上同等重要。

• **LogicalDisk/% Disk Time/ (LogicalDisk/% 磁碟時間/)**磁碟名稱

  此計數器測量磁碟在服務讀取或寫入要求時的經過時間比例。例如若是搜尋，請針對搜尋資料庫所在的磁碟監視此計數器。如果此計數器的平均值經常大於 90%，磁碟在搜尋時可能遇到瓶頸。

• 系統：Processor Queue Length (處理器佇列長度)

  此計數器的平均值應小於二乘以伺服器上的 CPU 核心數。

• 記憶體：Available Mbytes (可用 MB)

  確定此計數器的平均值至少為實體 RAM 總計的 20%。

• 記憶體：Pages/sec (頁數/秒)

  此計數器的平均值應小於 100。

• 邏輯磁碟：Disk Transfers/sec (磁碟轉移/秒)

  此計數器測量磁碟分割的整體輸送量。

• 邏輯磁碟：Disk Read Bytes/sec & Disk Write Bytes/sec (磁碟讀取位元組/秒及磁碟寫入位元組/秒)

  此計數器測量特定磁碟的總頻寬。

• 邏輯磁碟：Average Disk sec/Read (讀取磁碟的平均秒數)

  此計數器又稱為讀取延遲，表示磁碟擷取資料所需的時間。讀取延遲低對適當回應使用者查詢很重要。

• 邏輯磁碟：Average Disk sec/Write (寫入磁碟的平均秒數)

  此計數器又稱為寫入延遲，表示磁碟寫入資料所需的時間。寫入延遲低可改善索引的效能。

• **LogicalDisk/% Disk Write Time/ (LogicalDisk/% 磁碟寫入時間/)**磁碟名稱

  此計數器測量磁碟在服務讀取要求時的經過時間比例。搜尋資料庫磁碟的讀取要求比例若很高，可能表示使用者執行大量搜尋。

• **LogicalDisk/% Disk Write Time/ (LogicalDisk/% 磁碟寫入時間/)**磁碟名稱

  此計數器測量磁碟在服務寫入要求時的經過時間比例。搜尋資料庫在索引程序期間，預期寫入要求比例會很高。

  注意

  如有可能，請將搜尋資料庫置於其他資料庫的獨立磁碟上，以最佳化搜尋效能。如果以此方式分隔搜尋資料庫，由於磁碟專用於搜尋，因此這些 Logical Disk 計數器可高度診斷搜尋效能。

• SQLServer:Buffer Manager/Page life expectancy

  此計數器測量資料庫分頁在未參照的情況下保留在緩衝區集區的秒數。應保留 300 秒以上。該值若低於 300 秒則高度診斷為記憶體瓶頸，此時您應考慮為伺服器增加記憶體。

監視索引伺服器

在 Office SharePoint Server 2007 中，索引伺服器會編目內容並建立索引檔案。當編目程序完成時，會將索引傳播至查詢伺服器，以回應使用者的搜尋要求。

如果索引伺服器執行效率差，可能不會對使用者造成直接影響。然而，編目程序延長有時會到您無法將編目限制在離峰時間的程度，而必須分隔編目與備份等其他離峰活動。

若要監視索引伺服器的狀況，請在編目期間使用下列效能監視器計數器：

• Office Server Search Archival Plugin/Total Docs in first queue/Portal_Content (Office Server Search 封存外掛程式/第一個佇列中的文件總數/Portal_Content)

  此計數器測量封存外掛程式第一個佇列的文件數目。編目期間應低於 500，其他時候則非常低。如果計數器高於 500，資料庫伺服器上的搜尋資料庫磁碟機可能遇到瓶頸。

• Office Server Search Archival Plugin/Total Docs in second queue/Portal_Content (Office Server Search 封存外掛程式/第二個佇列中的文件總數/Portal_Content)

  此計數器測量封存外掛程式第二個佇列的文件數目。如同前一個計數器，編目期間應低於 500。

• Office Server Search Gatherer/Idle Threads (Office Server Search 收集程式/Idle Threads)

  此計數器測量收集程式處理序等候文件的執行緒數目。如果此計數器為 0，收集程式的資源已耗盡。請考慮減少並行編目的數目。

• Office Server Search Gatherer/Threads Accessing Network (Office Server Search 收集程式/Threads Accessing Network)

  此計數器測量收集程式處理序中，已傳送要求至遠端資料儲存區，並等候回應或正在處理回應的執行緒數目。如果此計數器持續很高，網路頻寬可能遇到瓶頸，或索引伺服器可能連線至一或多個很慢的主機以編製內容索引。

• Office Server Search Gatherer/Filtering Threads (Office Server Search 收集程式/Filtering Threads)

  此計數器測量已擷取內容且正在進行篩選的執行緒數目。如果此數字很高，可能表示索引伺服器上的資源遇到瓶頸。

• Office Server Search Gatherer/Threads In Plug-Ins (Office Server Search 收集程式/Threads In Plug-Ins)

  此計數器測量已擷取內容且正透過 IFilters 等外掛程式進行處理的執行緒數目。這是編目程序中填入索引與搜尋資料庫之後的階段。

• Office Server Search Gatherer Projects/Crawls in progress (Office Server Search 收集程式專案/Crawls in progress)

  此計數器測量進行中的編目數目。除非管理員手動啟動編目，否則此值應符合排程編目的內容來源數目。

使用 SharePoint 診斷監視 Office SharePoint Server

SharePoint 診斷工具 v1.0 (又稱為 SPDiag) 是進階診斷與分析工具，可呈現有關執行 SharePoint 產品及技術之任何伺服器或伺服器陣列的廣泛資訊。您可以使用 SPDiag 檢視非常詳細的伺服器與伺服器陣列設定快照，也可也合併及檢視網際網路資訊服務 (IIS)、統一登入服務 (ULS) 記錄及事件記錄的資訊，以及調查慢速要求等效能問題。

SPDiag 以圖表呈現伺服器陣列上任何伺服器的效能計數器。不過，它也包括數個計數器，以根據 IIS 記錄測量全伺服器陣列資料。這類全伺服器陣列分析必須搭配效能監視器一起使用。

使用下列全伺服器陣列計數器可調查 Office SharePoint Server 2007 伺服器陣列的回應：

• SharePointRequests/Number of unique client IP (SharePointRequests/個別用戶端 IP 數)

  此計數器測量在指定期間內提出要求的個別用戶端數目。請注意，這些透過 Proxy 伺服器存取伺服器陣列的用戶端會顯示為單一 IP 位址。

• SharePointRequests/Number of unique client agents (SharePointRequests/個別用戶端代理程式數)

  此計數器測量在指定期間內提出要求的個別用戶端代理程式 (瀏覽器) 數目。此計數器是依據在瀏覽器的 HTTP 要求中所指定的代理程式，因此可區分透過 Proxy 伺服器存取伺服器陣列的不同用戶端。

  注意

  下列計數器測量要求數目。這些要求包括搜尋查詢與內容要求。

• SharePointRequests/Total requests

  此計數器測量要求總數，該數目會隨指定時間期間而異。請一律搭配下列計數器監視此計數器，以判斷快速與慢速要求的比例。

• SharePointRequests/Number of requests with time taken < 1 second (SharePointRequests/耗時不到 1 秒的要求數)

  此計數器測量不到 1 秒便滿足的要求數目。在執行良好的伺服器陣列中，此計數器會接近 [Total requests] 計數器。

• SharePointRequests/Number of requests with time taken 1-5 seconds (SharePointRequests/耗時 1-5 秒的要求數)

  此計數器測量 1 到 5 秒內滿足的要求數目。這類效能對使用者而言通常是可接受的，但是如果這些要求會隨時間佔愈來愈多比例，則可能表示逐漸遇到瓶頸。

• SharePointRequests/Number of requests with time taken 5-10 seconds (SharePointRequests/耗時 5-10 秒的要求數)

  此計數器測量 5 到 10 秒內滿足的要求數目。使用者可能會在傳回結果前離開瀏覽頁面。

• SharePointRequests/Number of requests with time taken > 10 seconds (SharePointRequests/耗時 10 秒以上的要求數)

  此計數器測量超過 10 秒才滿足的要求數目。如果這些要求佔 [Total requests] 很大的比例，伺服器陣列等於無回應，此時您應調查瓶頸並考慮升級硬體。

使用統一登入服務記錄診斷查詢瓶頸

您可以使用統一登入服務 (ULS) 監視及最佳化 Office SharePoint Server 2007 系統的效能。ULS 應作為最佳化系統的其中一個方法。其他方法還包括使用效能監視器、事件記錄及網頁記錄。

在本節中，您會看到如何使用 ULS 記錄診斷搜尋效能中的延遲。您可以使用 ULS 記錄，診斷搜尋程序的哪些階段耗用最多時間並延遲傳回結果給使用者。您也應使用 ULS 記錄，評估系統設定的輕微變更所造成的效能改進程度。

設定統一登入服務

首先在 Office SharePoint Server 2007 管理中心網站中設定 ULS。

設定統一記錄服務診斷搜尋效能問題

1. 依序按一下 [開始]、[所有程式]、[Microsoft Office Server]，然後按一下 [SharePoint 3.0 管理中心]。

2. 按一下 [作業] 索引標籤。

3. 在 [記錄與報告]**** 區段中，按一下 [診斷記錄]。

4. 在 [事件節流]**** 區段的 [選取類別] 清單中，按一下 [MS Search 查詢處理器]****。

5. 在 [回報至追蹤記錄的最低緊急事件] 中，按一下 [高]****。

6. 按一下頁面底部的 [確定]。

使用 Log Parser 工具

Office SharePoint Server 2007 ULS 記錄與網際網路資訊服務 (IIS) 記錄一樣，都是非常大的文字檔。若要分析這類檔案的內容，請使用記錄剖析公用程式集中在感興趣的追蹤上，以及格式化資料。Microsoft Log Parser 2.2 (英文) (https://go.microsoft.com/fwlink/?linkid=148542&clcid=0x404) 即為適合此用途的免費工具。

Log Parser 工具是命令列程式。您必須使用下列參數指出 ULS 記錄是以 Unicode 撰寫並以 Tab 分隔的文字檔：

logparser -i:TSV -iCodepage:-1 -fixedSep:ON

除了這些參數，您還必須提供 Transact-SQL 式查詢，以告知 Log Parser 如何剖析記錄檔。例如，若要集中在查詢處理器計時器訊息，請使用下列 WHERE 子句：

WHERE Category = 'MS Search Query Processor' AND Message LIKE '%Completed query execution with timings:%'

搜尋 ULS 記錄中的訊息

如上所述設定 ULS 之後，下列訊息隨即在使用者執行查詢時，出現在記錄檔中：

• Completed query execution with timings (完成的查詢執行及時間)

  此訊息表示查詢已完成，並包含以毫秒為單位說明查詢的六種時間。這六種時間如下：

  • v1。處理查詢所花費的總時間。

  • v2。偵測重複結果後測量到的查詢延遲。

  • v3。調整安全性後測量到的查詢延遲。

  • v4。連接索引結果與搜尋資料庫結果後測量到的查詢延遲。

  • v5。等候索引伺服器結果所花費的時間。

  • v6。呼叫資料庫所花費的時間，不包括從搜尋資料庫擷取內容的時間。

  透過這六種時間，您可以計算出下列資訊：

  • v1 – v2。擷取內容及醒目提示所花費的時間。

  • v2 – v3。偵測重複結果所花費的時間。

  • v3 – v4。安全性調整所花費的時間。

  • v4 – v5。連接索引結果與搜尋資料庫結果所花費的時間。

• Join retry (重試連接)

  此訊息表示，由於搜尋資料庫傳回的結果不符合全文檢索索引傳回的結果，而無法連接，因此發生重試。

• Security Trimming retry (重試安全性調整)

  此訊息表示使用者執行查詢所傳回的結果，是使用者無權讀取的結果。將重試這類查詢，並要求更多結果，直到傳回足夠的結果。

• Near duplicate removal retry (重試移除近似重複的結果)

  此訊息表示已從結果移除許多幾乎完全相同的文件，而使得查詢處理器沒有足夠的結果可以顯示。將重試這類查詢，並要求更多結果，直到傳回足夠的結果。

分析查詢時間

在本節稍早所述的所有訊息中，[Completed query execution with timings (完成的查詢執行及時間)] 訊息是診斷查詢處理延遲時最常使用的訊息。例如，如果安全性調整很慢，v3 – v4 計算結果會佔總處理時間 v1 很大的比例。

若要分析這些時間，請將下列 SQL 查詢傳送至 Log Parser 工具。該工具會建立以逗號分隔的檔案，內含 v1 至 v6 時間及其時差。

Select  Timestamp,
TO_INT(Extract_token(Message,7, ' ')) as TotalQPTime,
      TO_INT(Extract_token(Message,8, ' ')) as v2,
      TO_INT(Extract_token(Message,9, ' ')) as v3,
      TO_INT(Extract_token(Message,10, ' ')) as v4,
      TO_INT(Extract_token(Message,11, ' ')) as TimeSpentInIndex,
      TO_INT(Extract_token(Message,12, ' ')) as v6,
      SUB(v4, TimeSpentInIndex) as JoinTime,
      SUB(v3, v4) as SecurityTrimmingTime,
      CASE v2
           WHEN 0 THEN 0 
           ELSE SUB(v2, v3) 
      End as DuplicateDetectionTime,
      SUB(TotalQPTime, v2) as FetchTime
INTO QTiming
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Completed query execution with timings:%'

您可以將產生的 CSV 檔案匯入 Microsoft Office Excel 或其他分析工具，以建立圖表與報表。請考慮在忙碌的系統中執行多次查詢，以利用許多結果產生有意義的分析。

分析重試

[Completed query execution with timings (完成的查詢執行及時間)] 訊息中的時間資料不包含與重試相關的任何資訊，例如安全性調整所導致的重試。若要分析查詢處理器在重試上所花費的時間，必須比較查詢總數與不同類型的重試次數。

下列查詢會計算已執行的查詢總數：

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Completed query execution%'

下列查詢會計算安全性調整所導致的重試次數總計：

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Security trimming retry%'

下列查詢會計算移除重複結果所導致的重試次數總計：

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Near duplicate removal retry%'

使用上述查詢診斷重試延遲查詢結果的程度。如果重試次數佔查詢總數很大的比例，則應考慮修訂設定。例如，如有幾位使用者可以存取其中一個內容來源的文件，可能會增加安全性調整的重試次數。此時請考慮從索引移除此來源。

最佳化 SQL Server 的 Office SharePoint Server 2007 搜尋

Microsoft Office SharePoint Server 2007 使用 Microsoft SQL Server 儲存內容、設定資訊及索引內容的屬性。您必須最佳化 SQL Server 以確保 Office SharePoint Server 有最佳效能。

一般 SQL Server 最佳化

有些最佳化會改善 SQL Server 的效能，而不論伺服器的用途為何。您應確保 Office SharePoint Server 資料庫可使用這些最佳化。

當您規劃及部署資料庫伺服器時，請考慮下列建議：

• 如有可能，請在專用伺服器或伺服器陣列上執行 SQL Server。

• 在伺服器陣列中向外延展為多部資料庫伺服器。一般而言，每四部以最大容量執行的網頁伺服器應安裝一部資料庫伺服器。

• 在電腦上使用 64 位元版本的 SQL Server 與 64 位元的作業系統。

• 儘可能使用硬體預算所允許的最多實體磁碟磁針。

• 使用高速磁碟。

• 在 RAID 1+0 或 RAID 1 磁碟陣列上放置資料庫。

• 將記錄檔分隔到與儲存主要及次要資料檔案不同的實體磁碟上。

最佳化 SQL Server 搜尋查詢及編製索引

許多 Office SharePoint Server 2007 管理員的高優先順序是最佳化編目、索引及查詢。Office SharePoint Server 內容索引儲存在任何 SQL Server 資料庫以外的檔案系統。但是，搜尋資料庫儲存索引檔案的中繼資料與 ACL。因此，SQL Server 的效能會直接影響下列兩個搜尋作業：

• 索引，Office SharePoint Server 儲存中繼資料與 ACL 時。

• 查詢。所有 Office SharePoint Server 查詢都需要安全性調整，在這段期間，Office SharePoint Server 會檢查搜尋資料庫中的 ACL，並移除不允許使用者檢視的結果。此外，如果使用者已執行屬性搜尋，則必須從搜尋資料庫擷取中繼資料。

您一開始應遵循本文稍早提供的一般 SQL Server 最佳化建議。此外，以下小節所列的最佳化則是特別有利於索引與查詢。

最佳化 tempdb 資料庫效能。

每個使用者查詢都可視為 SQL Server tempdb 資料庫上的活動。因此，此資料庫的組態會直接影響使用者可多快看到查詢回應。

請採取下列步驟最佳化 tempdb：

• 將復原模式設為 SIMPLE。

• 允許 tempdb 檔案視需要自動成長。

• 將檔案成長遞增值設為合理的值。規則是此遞增值應為約 10% 的 tempdb 檔案大小。

• 預先配置 tempdb 檔案的空間，方法是將檔案大小設為可在編目與查詢期間容納所有活動的值。

• 使用多個資料檔案以提高磁碟頻寬。規則是執行 SQL Server 之電腦上的每個 CPU 核心各使用一個資料檔案。

• 固定每個資料檔案的大小。

• 將 tempdb 資料庫放在與儲存內容資料庫、設定資料庫及搜尋資料庫不同的實體磁碟上。

使用檔案群組改善效能。

Office SharePoint Server 2007 編目與索引程序需要大量 I/O，並會將大量資料寫入搜尋資料庫。如果確定系統何時離線，應將索引排程在此時間執行，以確保索引不會與使用者查詢競用資源。但是，在某些具有全球或 24 小時活動的組織中，並不會有任何時間點的需求量明顯降低。如果主控搜尋資料庫的資料庫伺服器很接近其 I/O 容量，則應考慮其他方式，以分隔索引 I/O 作業與那些使用者查詢相關作業。

搜尋資料庫可分為與索引相關的資料表，以及主要與使用者查詢相關的資料表。如果您將這兩組資料表分隔到兩個實體磁碟，則可確保索引對查詢效能的影響最低。雖然索引與查詢資料表在一個資料庫中，但是您可以使用 Microsoft SQL Server 檔案群組功能達成此分隔。

若要執行這項操作，請建立內含次要資料檔案的使用者檔案群組。此資料檔案必須位在專用的實體磁碟上，才可改善效能。然後使用下列程序，將與索引相關的資料表移至該檔案群組。根據搜尋資料庫的大小，此程序可能需要很長的一段時間。因此，請在需求量低的時候執行此程序。

分隔索引資料表到專用的檔案群組

1. 在 SQL Server Management Studio 中，於搜尋資料庫上按一下滑鼠右鍵，然後按一下 [內容]。

2. 在 [選取頁面]**** 清單中，按一下 [檔案群組]。

3. 按一下 [新增]****，然後將新的檔案群組命名為 “CrawlFileGroup”。

4. 在 [選取頁面] 清單中，按一下 [檔案]****。

5. 按一下 [新增]，然後命名新檔案。

6. 在 [檔案群組] 儲存格中，選取 [CrawlFileGroup]****。

7. 在 [路徑] 儲存格中，從 PRIMARY 檔案群組選取獨立實體磁碟上的路徑。

8. 按一下 [確定]。

9. 在 SQL Server Management Studio 中，按一下 [新增查詢]****。

10. 將下列查詢複製到查詢視窗，然後按一下 [執行]。此 Transact-SQL 程式碼會建立新的預存程序，並將資料表移至新的檔案群組。

    IF EXISTS (SELECT * FROM sysobjects WHERE type = 'P' AND name = 'proc_MoveTableToFileGroup')
       BEGIN
          DROP  Procedure  dbo.proc_MoveTableToFileGroup
       END
    GO
    CREATE PROCEDURE [dbo].[proc_MoveTableToFileGroup]
    (
       @fileGroup sysname,
       @tableName sysname
    )
    as
    begin
       declare @data_space_id int
       declare @object_id int
       declare @index_id int
       declare @index_name sysname
       declare @object_name sysname
       declare @fileGroupName sysname
       declare @index_cols nvarchar(4000)
       declare @sql nvarchar(4000)
       declare @key_ordinal int
       set @index_id = 0
       set @key_ordinal = 0
       select @data_space_id = data_space_id, @fileGroupName = name from sys.filegroups where name = @fileGroup
       if @data_space_id is null
       begin
          raiserror ('The specified filegroup does not exist.', 16, 1)
          return
       end
       while 1=1
       begin
          select top 1
                @object_id = i.object_id, 
                @index_id = i.index_id,
                @index_name = i.name,
                @object_name = o.name
             from 
                sys.indexes AS i
             inner join 
                sys.objects AS o
             ON
                i.object_id = o.object_id
             where 
                i.index_id > 0 and
                o.type = 'U' and
                o.name = @tableName and
                i.index_id > @index_id and
                i.data_space_id <> @data_space_id
             order by i.index_id
          if @@rowcount = 0 
          begin
             if @index_id = 0
                print 'There are no indexes to move to filegroup ' + @fileGroupName + ' for table ' + @tableName
             break
          end
          set @index_cols = null
          set @key_ordinal = 0
          while 1=1
          begin
             select top 1 
                @index_cols = case when @index_cols is null then '[' + c.name + ']' else @index_cols + ', [' + c.name + ']' end + 
                case when i.is_descending_key = 0 then ' asc' else 'desc' end, 
                @key_ordinal = i.key_ordinal
             from 
                sys.index_columns i 
             inner join 
                sys.columns as c
             on 
                i.object_id = c.object_id and
                i.column_id = c.column_id
             where 
                i.object_id = @object_id and 
                i.index_id = @index_id and 
                i.key_ordinal > @key_ordinal
             order by i.key_ordinal
             if @@rowcount = 0 
                break
          end
          select @sql = 
             case when i.is_primary_key = 1 then 
                N'begin try ' + 
                N'begin tran ' + 
                N'alter table [' + @object_name + '] drop constraint [' + i.name + '] ' + 
                N'alter table [' + @object_name + '] add constraint [' + i.name + '] ' + 
                'primary key ' +
                case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
                ' (' + @index_cols + ') ' + 
                'with (' +
                'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
                ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
                case when  i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + 
                ') ' + 
                'ON [' + @fileGroupName + ']' + 
                N' commit ' + 
                N'end try ' + 
                N'begin catch ' + 
                N'rollback ' + 
                N'end catch ' 
             else 
                N'create ' + 
                case when  i.is_unique = 1 then 'unique ' else '' end +
                case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
                'index [' + i.name + '] on [' + @object_name + '] (' + @index_cols + ') ' + 
                'with (' +
                'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
                ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
                case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ', DROP_EXISTING = ON ) ' + 
                'ON [' + @fileGroupName + ']'
             end
    from 
             sys.indexes AS i
          where 
             i.object_id = @object_id and
             i.index_id = @index_id
          print 'Moving index ' + @index_name + ' to filegroup ' + @fileGroupName 
          print @sql
          print ''
          exec sp_executesql @sql
       end
    end
    

11. 在 SQL Server Management Studio 中，按一下 [新增查詢]****。

12. 將下列查詢複製到查詢視窗，然後按一下 [執行]。此 Transact-SQL 程式碼會針對每個索引資料表，執行新的預存程序。

    declare @fileGroup sysname
    set @fileGroup = 'CrawlFileGroup'
    if not exists (select 1 from sys.filegroups where name = @fileGroup)
    begin
       raiserror ('The specified filegroup does not exist.', 16, 1)
       return
    end
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorChangeLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorPendingChangeLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorText'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorTransactions'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedSourceDocs'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedTargetDocs'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlContent'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedErrorList'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedURL'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlErrorList'
    begin try
       begin tran
       IF  EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_MSSCrawlContent_MSSCrawlHistory]') AND parent_object_id = OBJECT_ID(N'[dbo].[MSSCrawlContent]'))
       ALTER TABLE [dbo].[MSSCrawlContent] DROP CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory]
       exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHistory'
       ALTER TABLE [dbo].[MSSCrawlContent]  WITH CHECK ADD  CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] FOREIGN KEY([CrawlID])
       REFERENCES [dbo].[MSSCrawlHistory] ([CrawlID])
       commit
    end try
    begin catch 
       rollback
    end catch
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHostList'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlQueue'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURL'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURLLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSTranTempTable0'
    

維護 SQL Server 資料庫進行搜尋

SQL Server 資料庫與任何複雜的系統一樣，都需要定期維護才能維持最高效能。本節說明維持最高效能的一些建議作法。

下列磁碟維護程序可提高資料庫伺服器的效能：

• 至少保留 25% 的可用磁碟空間以供資料庫擴增之用。定期監視磁碟大小與可用空間可避免低於此百分比。如果管理員新增內容來源，搜尋資料庫的大小就可能會快速地大幅增加。

• 如果磁碟控制卡使用 [磁碟寫入快取]，請確定具有備份電池，以在電源失敗時不致中斷服務。

下列 SQL Server 維護程序可改善資料庫伺服器的效能：

• 定期在所有 Office SharePoint Server 資料庫上執行 DBCC CHECKDB Transact-SQL 常式。不過，此常式會對 SQL Server 電腦造成很大的負荷，並可能影響回應。因此，請使用 PHYSICAL_ONLY 選項並排程 DBCC CHECKDB 在離峰時間執行。請勿在 Office SharePoint Server 編目期間執行此常式。

• 避免在執行 SQL Server 的實際執行電腦上，執行任何不支援的作業。例如，請勿變更資料庫定序，或新增欄至任何 Office SharePoint Server 資料庫資料表。如需不支援作業的詳細資訊，請參閱 Microsoft 知識庫文章 841057：對變更 Office Server 產品與 Windows SharePoint Services 所使用之資料庫的支援 (https://go.microsoft.com/fwlink/?linkid=105589&clcid=0x4044) (機器翻譯)。

SQL Server 索引中支援搜尋資料庫的片段，過了一段時間便會影響索引與查詢效能。Microsoft 知識庫文章 KB943345 中的 Transact-SQL 指令碼，可建立稱為 proc_DefragmentIndices 的預存程序。您可以使用 proc_DefragmentIndices 重組 Office SharePoint Server 伺服器陣列中的搜尋與內容資料庫。不過，此預存程序會耗用相當多的伺服器資源。因此，您必須格外謹慎使用，以免降低查詢回應。

此外，可使用專為 Office SharePoint Server 搜尋資料庫設計的磁碟重組預存程序 proc_DefragSearchIndexes。該預存程序只會重組提供最大效能利益的索引，例如 IX_MSSDocProps 與 IX_MSSDocSdids。如此可降低對資料庫伺服器資源的需求。您應該排程此預存程序在離峰時間執行，並謹慎監視對使用者的影響。

如果您診斷到伺服器陣列中的某部資料庫伺服器上，發生磁碟或 RAID 瓶頸，下列動作可降低問題的影響：

• 將資料檔案與交易記錄檔重新放置到其他磁碟或 RAID 陣列。使用本文稍早所述的檔案群組可提高效能。

• 在 RAID 陣列中新增磁碟。

• 以較快的磁碟取代較慢的磁碟。

避免編目程式耗盡

在大型或複雜的組織中，您必須在設定 Office SharePoint Server 2007 索引系統時，克服幾個重大挑戰。您可能有許多類型的內容來源及很大的內容主體，需要很長的編目時間。您也應該謹慎規劃索引中項目的即時性目標，以確保搜尋結果反映最新內容。若要達成即時性目標，必須最佳化索引器的效能，才可定期編目所有內容。

索引速度的最大障礙是編目程式的「耗盡」**。當編目程式無法配置另一個執行緒擷取佇列中的下一個文件時，便進入耗盡狀態。造成耗盡的原因如下：

• 主控搜尋資料庫之資料庫伺服器上的資源爭用

• 參與編目的主機過多

• 主機未快速放棄執行緒 (在本文中，這些主機稱為「等待內容」主機)。

• 備份與編目同時執行

等待內容主機鎖定執行緒，以免移至下一個文件。下列情況會發生此鎖定：

• 主機由於缺少 CPU、記憶體或其他資源而很慢時。

• 主機需要額外工作以進行累加編目時。例如，如果來源為 Microsoft SharePoint Portal Server 2003 伺服器，編目程式必須在權限變更之後重新處理一整份文件。

• 主機或文件含有大量屬性。若每份文件的屬性很多，主控搜尋資料庫的資料庫伺服器必須加倍運作。商務資料目錄內容來源與「我的網站」一般都含有大量屬性。

使用下列類型的主機進行編目通常會最有效率：

• Office SharePoint Server 2007 伺服器。這些伺服器維護編目程式可以使用的變更記錄。

• 檔案共用。編目程式可以在資料夾層級檢查是否有變更，而不用檢查每份文件。

• Exchange 公用資料夾。編目程式可以在資料夾層級檢查是否有變更，而不用檢查每個張貼文章。

避免耗盡的方針

您可以遵循下列最佳作法，以避免編目程式耗盡：

• 最小化內容來源的數目。藉由將大小與類型相似的主機群組為單一內容來源，以增加效率。

• 先編目大型 Office SharePoint Server 2007 主機，再新增其他主機類型。這些主機的編目效率很高，而累加編目可很快釋放執行緒。

• 請勿對多個等待內容主機排程同時編目。

• 一開始先排程四個並行編目。某些索引伺服器可增加此數目。如需詳細資訊，請參閱本文的下一節。

• 如果編目程式愈來愈耗盡，請暫停等待內容主機的編目，以釋放執行緒。

如何診斷耗盡

當您安裝新的 Office SharePoint Server 2007 搜尋系統時，請新增過去幾天或幾週內的新內容來源，以建立編目程式設定。在新增每個內容來源時監視系統效能，可避免耗盡並方便進行疑難排解。如此一來，您即可完整了解系統在編目期間的行為。

編目程式使用的執行緒數目是由 [索引器效能] 設定所決定。若要變更此設定，請在管理中心內，依序按一下 [作業]**** 索引標籤、[伺服器上的服務] 及 [Office SharePoint Server 搜尋]****。下表顯示 [索引器效能] 設定如何控制編目執行緒。

索引器效能設定	執行緒總數	每個主機的最大執行緒數
降低	處理器數目	處理器數目
部分降低	處理器數目的 4 倍	處理器數目加 4
最大值	處理器數目的 16 倍	處理器數目加 4

在 Office SharePoint Server 2007 中，編目執行緒的數目絕不超過 64。

耗盡的最常見原因是資料庫伺服器上的資源爭用。您可以透過監視封存外掛程式來診斷此問題。在效能監視器中，使用 [Office Server Search 封存外掛程式] 物件以及 [第一個佇列中的文件總數]**** 與 [第二個佇列中的文件總數] 計數器。如果這些計數器的 [Portal_Content]**** 執行個體為 500 或 [ProfileImport] 執行個體為 50，編目程式已耗盡。請考慮如本文稍早的＜最佳化 SQL Server 的 Office SharePoint Server 2007 搜尋＞中所述，調整資料庫伺服器。

耗盡狀態的原因若不是封存外掛程式，則可透過效能監視器中的 [Office Server Search 收集程式]**** 診斷。請注意 [Idle Threads]、[Threads Accessing Network]**** 與 [Threads In Plug-ins] 計數器，並將其與系統的執行緒總數做比較。如需這些計數器的完整說明，請參閱本文稍早的＜監視索引伺服器＞。

避免存取控制清單造成的瓶頸

當 Office SharePoint Server 2007 編目內容來源及為其編製索引時，會檢查存取控制清單 (ACL) 並將其儲存在搜尋資料庫中。當使用者搜尋索引時，即會針對每個結果檢查搜尋資料庫，以確保使用者獲得授權可以存取該結果。這個程序稱為安全性調整。因此，具有許多巢狀層級的大型 ACL 可能對 Office SharePoint Server 內之編目程序與搜尋的效能造成不良影響。本節說明如何減輕這類效能降低。

Active Directory 提供下列安全性原則類型，可用於保護 Office SharePoint Server 網站與索引內容：

• 使用者帳戶

• 全域群組

• 網域本機群組

• 萬用群組

在 Office SharePoint Server 2007 中，您還有 SharePoint 群組。此系統非常彈性，且可包含多層巢狀結構。但是，安全性原則可能對 Office SharePoint Server 搜尋效能造成不良影響。

若要確保 Office SharePoint Server 2007 編目程式與搜尋的效能最高，請在使用 Active Directory 安全性原則與 SharePoint 群組時，觀察下列規則：

• 將使用者帳戶放入全域群組，並將全域群組放入網域本機群組。指定權限給網域本機群組。這是在 Active Directory 中使用安全性原則的建議最佳作法，可確保網域控制站快速檢閱群組成員資格，且使用者可存取整個樹系的資源。

• 如果需要萬用群組，請使用相同的系統，但將全域群組放入萬用群組，並將萬用群組放入網域本機群組。

• 將網域本機群組放入 SharePoint 群組，以指定權限給 SharePoint 網站與其他資源。

• 限制群組成員資格中所使用的巢狀層級數目。

下列特定情況會危害 Office SharePoint Server 2007 搜尋的效能，應予以避免：

• 請勿指定 Office SharePoint Server 網站權限給個別使用者。

  當 Office SharePoint Server 網站的 DACL 中列出 2,000 個以上的安全性原則時，網站會變慢。不過，Active Directory 或 SharePoint 群組是單一安全性原則，而不論其包含的使用者人數為何。因此，請使用 SharePoint 群組指定網站權限，並將使用者或 Active Directory 群組放入 SharePoint 群組。

• 請勿使用巢狀太深的 Active Directory 安全性群組。

  當使用者嘗試存取 Office SharePoint Server 網站時，伺服器必須評估群組成員資格以授權使用者。當群組的巢狀太深時，必須對網域控制站執行許多查詢。此外，可能必須對樹系中的遠端網域執行查詢。這些查詢必須完成，才可授與使用者存取權。

• 請勿使用包含連絡人的通訊群組清單或安全性群組。

  Active Directory 中的連絡人可新增至群組以執行電子郵件發送等作業，但是連絡人不是安全性原則，因此與授權無關。如果您指定權限給包含連絡人的群組，效能可能會降低。

在 Office SharePoint Server 2007 中，每個網站的網站擁有者可以將使用者與群組新增至網站 DACL。您必須訓練網站擁有者如何使用群組成員資格權責，以避免導入瓶頸。

疑難排解遺失的搜尋方塊網頁組件

在下列情況下，搜尋方塊網頁組件不會顯示在搜尋中心及 Office SharePoint Server 2007 使用者介面的其他位置：

• 開發人員已修改搜尋中心內容頁面或網站主版頁面，以隱藏或移除搜尋方塊網頁組件。

• 具有網站之「完全控制」或「設計」權限等級的使用者已移除或隱藏搜尋方塊網頁組件。

• Office SharePoint Server 伺服器陣列無法使用搜尋服務，可能是因為服務中斷，或管理員已將服務離線。

另請參閱

概念

Office SharePoint Server 2007 疑難排解
Office SharePoint Server 中搜尋的最佳作法