针对搜索性能的最佳做法 (Search Server 2008)

更新时间: 2009年7月

应用到: Microsoft Search Server 2008

 

上一次修改主题： 2015-03-09

本文介绍可用于在 Microsoft Search Server 2008 中维护正常运行的高效搜索系统的一些最佳实践。

本文内容：

• 启动完全爬网的原因

• 监视 Web 服务器

• 监视数据库服务器

• 监视索引服务器

• 使用 SharePoint 诊断工具监视 Search Server

• 使用统一日志记录服务日志来诊断查询瓶颈

• 为 Search Server 2008 优化 SQL Server

• 针对搜索维护 SQL Server 数据库

• 避免爬网程序匮乏

• 避免访问控制列表引起的瓶颈

• 解决缺少“搜索框”Web 部件问题

启动完全爬网的原因

对大量信息、文档和网页进行爬网和索引需要进行大量计算机处理。爬网过程还会消耗网络和其他资源。您必须仔细配置 Search Server 2008 服务器场，以确保爬网和索引过程不会对提供给用户的服务产生负面影响。例如，通常在服务器未充分利用的非高峰时段对内容进行爬网和索引，以便能够在高峰时段始终为用户提供服务。

减少爬网影响的一种方法是计划增量爬网而不是完全爬网。增量爬网只为更改项编制索引，因此该过程需要较少的计算机资源。您可以对每个内容源计划完全爬网和增量爬网。例如，您可以考虑在工作日的午夜运行增量爬网，在星期六的午夜运行完全爬网。

为确保索引完整，您应该在以下情况下手动启动完全爬网：

• 当管理员对服务器场中的服务器应用了更新或 Service Pack 时。

• 当管理员向搜索配置中添加了新的托管属性时。

• 当管理员添加或修改了爬网规则时。

• 当您希望重新索引 Windows SharePoint Services 3.0、Microsoft Office SharePoint Server 2007 或 Search Server 2008 网站上的 ASP.NET 网页时。爬网程序无法检测到此类网页何时发生了更改。因此，只有完全爬网可以重新索引它们。

• 当连续的增量爬网失败时。如果增量爬网在库中的任何级别连续失败 100 次，则索引服务器会从索引中移除受影响的内容。

• 当管理员已修复损坏的索引时。

• 当管理员已创建服务器名称映射时。

• 当您更改了对某些内容的权限但内容本身没有发生更改，并且您没有对服务器应用 Service Pack 1 之后的修补程序包 (KB941442) 或更高版本的 Service Pack 时。如果没有此修补程序包，增量爬网将不会检查访问控制列表 (ACL)。如果未检查 ACL，则用户可以查看搜索结果中的项目，即使管理员在上次完全爬网后移除了该用户的权限。

在以下情况下，Search Server 2008 会在计划增量爬网或手动启动增量爬网后执行完全爬网：

• 当 SSP 管理员已手动停止以前的爬网时。

• 当管理员从备份中还原了内容数据库时。

  提示

  可以使用 stsadm.exe 工具中的选项来指定还原操作是否引起完全爬网。

• 当服务器场管理员分离并重新附加了内容数据库时。

• 当 Search Server 从未对内容进行过完全爬网时。

• 当更改日志不包含有关爬网中地址的任何信息时。更改日志用于确定自上次爬网后是否有项目发生了更改。如果没有更改日志信息，增量爬网将无法运行。

• 当用于访问内容的用户帐户发生了更改时。此用户帐户可以是默认内容访问帐户或爬网规则中指定的帐户。

• 当出现索引损坏情况时。

必须仔细考虑在这些情况下执行的操作，因为如果手动或按计划启动爬网，那么与进行增量爬网所需的资源相比，完全爬网可能需要更多的资源。这会影响用户获得的服务。

监视 Web 服务器

若要获得最佳 Search Server 2008 搜索性能，必须充分分析系统。应对服务器进行充分调查以创建基准线。应定期重新运行性能测试以观察所有更改并提早诊断问题。在进行优化时，可以使用基准线来描绘获得的改进。下面几节列出了性能监视器计数器以及通过与 Search Server 2008 的性能相关的其他工具获得的数据。

在 Search Server 2008 中，Web 服务器发送对用户搜索查询的响应。因此，Web 服务器性能对搜索性能有直接影响。Web 服务器还影响索引。这是因为爬网程序通过向 Web 服务器发送请求来索引内容。

若要监视 Web 服务器的运行状况，请使用以下性能监视器计数器：

• Processor/% Processor Time/_Total

  此计数器是处理器活动的主要指示器。它测量处理器执行非空闲线程所用的时间比例。如果此计数器平均值长期高于 80%，则处理器可能成为瓶颈，应该考虑进行升级。

• Memory/Available Mbytes

  此计数器测量立即可供进程或系统使用的物理内存。如果此计数器值降到太低，系统在使用更多分页时速度会下降。应该考虑向服务器添加更多内存。

• Web Service/Current Connections

  此计数器测量与万维网服务的连接数。在 Search Server 2008 服务器上，此计数包括所有并发用户以及索引期间的爬网程序。使用此计数器可简述使用模式并确定高峰时段。此计数器没有任何限制；非常高的值可能指示卓越的性能。

  提示

  在具有多台 Web 服务器的 Search Server 服务器场中，此计数器只测量一台服务器上的连接。有关如何监视整个服务器场中用户活动的信息，请参阅使用 SharePoint 诊断工具监视 Search Server。

监视数据库服务器

Search Server 2008 使用 Microsoft SQL Server 2005 或 Microsoft SQL Server 2008 来存储内容数据库。虽然索引服务器在文件系统（而不是数据库）中存储内容索引，但它在搜索数据库中存储文档元数据和权限。因为许多搜索过程都会检查元数据并且所有搜索过程都涉及安全修整，所以数据库服务器的性能直接影响搜索性能。

若要监视数据库服务器的运行状况，请使用以下性能监视器计数器：

• Processor/% Processor Time/_Total

  此计数器是处理器活动的主要指示器，因此它在数据库服务器上与在 Web 服务器上一样重要。

• LogicalDisk/% Disk Time/ 磁盘名称

  此计数器测量磁盘为提供读取或写入请求服务所用的时间比例。应监视保存搜索数据库的磁盘的此计数器。如果此计数器平均值经常大于 90%，则此磁盘可能成为搜索瓶颈。

• System: Processor Queue Length

  此计数器平均值应小于二乘以服务器上的 CPU 内核数后所得到的值。

• Memory: Available Mbytes

  确保此计数器平均值至少为总物理 RAM 的 20%。

• Memory: Pages/sec

  此计数器平均值应低于 100。

• Logical Disk: Disk Transfers/sec

  此计数器测量分区的总吞吐量。

• Logical Disk: Disk Read Bytes/sec & Disk Write Bytes/sec

  此计数器测量特定磁盘的总带宽。

• Logical Disk: Average Disk sec/Read

  此计数器又称为读取延迟，指示磁盘检索数据所需的时间。低读取延迟对用户查询进行快速响应非常重要。

• Logical Disk: Average Disk sec/Write

  此计数器又称为写入延迟，指示磁盘写入数据所需的时间。低写入延迟可改进索引性能。

• LogicalDisk/% Disk Read Time/ 磁盘名称

  此计数器测量磁盘提供读取请求服务所用的时间比例。搜索数据库磁盘的读取请求比例大可能指示用户正在运行大量搜索。

• LogicalDisk/% Disk Write Time/ 磁盘名称

  此计数器测量磁盘提供写入请求服务所用的时间比例。在索引过程中，搜索数据库的写入请求比例预计会很高。

  提示

  将搜索数据库放在与其他数据库不同的磁盘上可优化搜索性能。如果以这种方式分隔搜索数据库，则因为该磁盘专用于搜索，这些逻辑磁盘计数器将很好地诊断搜索性能。

• SQLServer:Buffer Manager/Page life expectancy

  此计数器测量数据库页面在缓冲池中保持未被引用状态的秒数。该值应保持在 300 秒以上。值低于 300 秒很可能诊断为内存瓶颈，应考虑向服务器添加内存。

监视索引服务器

在 Search Server 2008 中，索引服务器对内容进行爬网并创建索引文件。当爬网过程完成后，索引将传播到响应用户搜索请求的查询服务器。

如果索引服务器运行状况不好，可能不会对用户产生直接影响。但爬网过程将延长，有时会导致您无法将爬网限制在非高峰时段以及将爬网与其他非高峰活动（例如备份）分隔开来。

若要监视索引服务器的运行状况，请在爬网过程中使用以下性能监视器计数器：

• Office Server Search Archival Plugin/Total Docs in first queue/Portal_Content

  此计数器测量存档插件第一个队列中的文档数。其值在爬网过程中应低于 500，在其他时段应非常低。如果此计数器高于 500，则数据库服务器上的搜索数据库驱动器可能成为瓶颈。

• Office Server Search Archival Plugin/Total Docs in second queue/Portal_Content

  此计数器测量存档插件第二个队列中的文档数。与前一个计数器一样，其值在爬网过程中应低于 500。

• Office Server Search Gatherer/Idle Threads

  此计数器测量 Gatherer 过程中等待文档的线程数。如果此计数器值为 0，则 Gatherer 缺乏资源。应考虑减少并发爬网的数量。

• Office Server Search Gatherer/Threads Accessing Network

  此计数器测量 Gatherer 过程中已向远程数据存储发送请求并正在等待或处理响应的线程数。如果此计数器值始终很高，则网络带宽可能成为瓶颈，或者索引服务器可能连接到一个或多个较慢的主机来索引内容。

• Office Server Search Gatherer/Filtering Threads

  此计数器测量已检索内容并正在筛选内容的线程数。如果此值很高，则可能指示索引服务器上的资源正在充当瓶颈。

• Office Server Search Gatherer/Threads In Plug-Ins

  此计数器测量已检索内容并正在通过插件（如 IFilter）处理内容的线程数。这是爬网过程中填充索引和搜索数据库的阶段。

• Office Server Search Gatherer Projects/Crawls in progress

  此计数器测量正在进行的爬网数。此值应与计划爬网的内容源数量相匹配，除非管理员手动启动爬网。

使用 SharePoint 诊断工具监视 Search Server

SharePoint 诊断工具 1.0 版（又称为 SPDiag）是一种高级诊断和分析工具，它提供了大量有关运行 SharePoint 产品和技术的任何服务器或服务器场的信息。您可以使用 SPDiag 来查看非常详细的服务器和服务器场配置快照。还可以合并和查看 Internet Information Services (IIS)、统一日志记录服务 (ULS) 日志和事件日志中的信息以及调查性能问题，例如慢速请求。

SPDiag 可提供服务器场中任何服务器的性能计数器图。但它还包括多个基于 IIS 日志测量服务器场范围数据的计数器。仅使用性能监视器无法进行此类服务器场范围的分析。

使用以下服务器场范围的计数器可调查 Search Server 2008 服务器场的响应速度：

• SharePointRequests/Number of unique client IP

  此计数器测量在指定时间段内发出请求的唯一客户端的数量。请注意，通过代理服务器访问服务器场的客户端显示为单个 IP 地址。

• SharePointRequests/Number of unique client agents

  此计数器测量在指定时间段内发出请求的唯一客户端代理（即浏览器）的数量。此计数器可区分通过代理服务器访问服务器场的客户端，因为它基于浏览器 HTTP 请求中指定的代理。

  提示

  以下计数器测量请求的数量。这些请求包括对内容的搜索查询和请求。

• SharePointRequests/Total requests

  此计数器测量请求总数，该值在指定时间段内不断变化。应始终监视此计数器以及以下计数器以确定快速和慢速请求的比例。

• SharePointRequests/Number of requests with time taken < 1 second

  此计数器测量 1 秒内满足的请求的数量。在运行状况良好的服务器场中，此计数器接近 Total requests 计数器。

• SharePointRequests/Number of requests with time taken 1-5 seconds

  此计数器测量 1 到 5 秒内满足的请求的数量。用户通常可接受此类性能，但这些请求的比例随时间不断增加可能导致出现瓶颈。

• SharePointRequests/Number of requests with time taken 5-10 seconds

  此计数器测量 5 到 10 秒内满足的请求的数量。用户可能会在结果返回前离开页面。

• SharePointRequests/Number of requests with time taken > 10 seconds

  此计数器测量超过 10 秒满足的请求的数量。如果这些请求在 Total requests 中占很大比例，则服务器场没有响应，您应调查瓶颈并考虑升级硬件。

使用统一日志记录服务日志来诊断查询瓶颈

您可以使用统一日志记录服务 (ULS) 来监视和优化 Search Server 2008 系统的性能。您应该使用 ULS 作为一种优化系统的方法。其他方法包括使用性能监视器、事件日志和 Web 日志。

在此节中，您将了解如何使用 ULS 日志来诊断搜索性能延迟。在 ULS 日志中，您可以诊断搜索过程的哪些阶段消耗时间最多并延迟向用户返回结果。您还应该使用 ULS 日志来评估通过对系统配置进行微小更改而做出的性能改进。

配置统一日志记录服务

首先在 Search Server 2008 管理中心网站中配置 ULS。

重要信息
必须是 Farm Administrators 组的成员才能完成以下过程。

配置统一日志记录服务以诊断搜索性能问题

1. 依次单击“开始”、“所有程序”和“Microsoft Search Server”，然后单击“SharePoint 3.0 管理中心”。

2. 单击“操作”选项卡。

3. 在“日志记录和报告”部分，单击“诊断日志记录”。

4. 在“事件限制”部分的“选择类别”列表中，单击“MS Search Query 处理器”。

5. 在“要报告给跟踪日志的关键程度最低的事件”中，单击“高”。

6. 在此页底部，单击“确定”。

使用 Log Parser 工具

与 Internet Information Services (IIS) 日志一样，Search Server 2008 ULS 日志是非常大的文本文件。若要分析此类文件的内容，请使用日志分析实用工具来关注感兴趣的跟踪内容以及设置数据格式。Microsoft Log Parser 2.2（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=148542&clcid=0x804)（该链接可能指向英文页面） 工具是免费的，并且适用于此目的。

Log Parser 工具是一个命令行程序。必须使用以下参数来指示 ULS 日志是制表符分隔的 Unicode 文本文件：

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%'

使用这些查询来诊断重试如何延迟查询结果。当重试数在查询总数中占很大比例时，应该考虑修订配置。例如，如果只有一些用户可以访问某一内容源中的文档，则这可能会增加安全修整重试数。请考虑从索引中移除此内容源。

为 Search Server 2008 优化 SQL Server

Microsoft Search Server 2008 使用 Microsoft SQL Server 来存储内容、配置信息和索引内容的属性。必须优化 SQL Server 以确保 Search Server 2008 的最优性能。

常规 SQL Server 优化

某些优化改进了 SQL Server 的性能，而不管服务器的用途是什么。应确保已为 Search Server 2008 数据库进行了这些优化。

在规划和部署数据库服务器时，请考虑以下建议：

• 如果可能，应在专用服务器或服务器场上运行 SQL Server。

• 扩展到服务器场中的多台数据库服务器。一般来说，应为每四台满负荷运行的 Web 服务器安装一台数据库服务器。

• 在具有 64 位操作系统的计算机上使用 64 位版本的 SQL Server。

• 根据硬件预算的允许值，使用尽可能多的物理磁盘心轴。

• 使用高速磁盘。

• 将数据库置于 RAID 1+0 或 RAID 1 磁盘阵列上。

• 将日志文件单独放在不存储主数据文件和辅助数据文件的物理磁盘上。

为搜索查询和索引优化 SQL Server

对于 Search Server 2008 管理员来说，爬网、索引和查询的优化具有高优先级。Search Server 内容索引存储在任何 SQL Server 数据库外部的文件系统中。但是，搜索数据库存储索引文件的元数据和 ACL。因此，SQL Server 的性能直接影响以下两种搜索操作：

• 索引。当 Search Server 存储元数据和 ACL 时。

• 查询。所有 Search Server 查询都涉及安全修整，在此期间，Search Server 会在搜索数据库中检查 ACL 并移除不允许用户查看的结果。另外，如果用户执行了属性搜索，则必须从搜索数据库中检索元数据。

您应首先遵循上文提供的常规 SQL Server 优化建议。但是，以下优化过程对索引和查询特别有用。

优化 tempdb 数据库的性能。

每个用户查询都涉及 SQL Server tempdb 数据库中的活动。因此，此数据库的配置直接影响向用户显示查询响应的速度。

可采取以下步骤来优化 tempdb：

• 将恢复模式设置为 SIMPLE。

• 允许 tempdb 文件根据需要自动增长。

• 将文件增长量设为合理值。按规则，此增量应该约为 tempdb 文件大小的 10%。

• 通过将文件大小设置为可容纳爬网和查询期间所有活动的值，为 tempdb 文件预分配空间。

• 使用多个数据文件来最大化磁盘带宽。按规则，应为运行 SQL Server 的计算机上的每个 CPU 内核使用一个数据文件。

• 使每个数据文件的大小相同。

• 将 tempdb 数据库放在与存储内容数据库、配置数据库和搜索数据库的物理磁盘不同的物理磁盘上。

使用文件组改进性能。

Search Server 2008 爬网和索引过程是 I/O 密集型过程，它向搜索数据库中写入大量数据。如果系统遇到显著的非高峰时段，应该计划在这些时段运行索引以确保索引不会与用户查询竞争资源。但是，在世界各地或 24 小时运营的某些组织中，需求并没有明显降低。如果托管搜索数据库的数据库服务器接近其 I/O 容量，则应考虑采用其他方法来将索引 I/O 操作与有关用户查询的操作分隔开。

搜索数据库可以划分为与索引相关的表以及主要与用户查询相关的表。如果您将这两组表分别放在两个物理磁盘上，则可以确保索引对查询性能的影响最小。虽然索引和查询表位于一个数据库中，但您可以使用 Microsoft SQL Server 文件组功能来实现此分隔。

为此，可创建一个用户文件组来存放辅助数据文件。此数据文件必须位于专用物理磁盘上才能实现性能改进。然后使用以下过程将索引表移动到该文件组中。此过程可能需要较长时间，时间长短取决于搜索数据库的大小。您应该在需求低时完成此过程。

将索引表分隔到专用文件组中

1. 在 SQL Server Management Studio 中，右键单击搜索数据库，然后单击“属性”。

2. 在“选择页”列表中，单击“文件组”。

3. 单击“添加”并将新文件组命名为“CrawlFileGroup”。

4. 在“选择页”列表中，单击“文件”。

5. 单击“添加”，然后命名新文件。

6. 在“文件组”单元中，选择“CrawlFileGroup”。

7. 在“路径”单元中，选择与主文件组所在物理磁盘不同的物理磁盘上的路径。

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 维护过程可以改进数据库服务器的性能：

• 定期对所有数据库运行 DBCC CHECKDB Transact-SQL 例程。但是，此例程会给运行 SQL Server 的计算机带来非常大的负荷，并可能会影响响应速度。因此，请使用 PHYSICAL_ONLY 选项并在非高峰时段计划 DBCC CHECKDB。不要在爬网期间运行此例程。

• 避免在运行 SQL Server 的生产计算机上执行任何不受支持的操作。例如，不要更改数据库排序规则或向任何 Search Server 数据库表中添加列。有关不受支持的操作的详细信息，请参阅 Microsoft 知识库文章 841057：支持对 Office Server 产品和 Windows SharePoint Services 所使用的数据库进行更改 (https://go.microsoft.com/fwlink/?linkid=105589&clcid=0x804)。

随着时间的推移，SQL Server 索引中支持搜索数据库的碎片可能会影响索引和查询性能。Microsoft 知识库文章 KB943345 中包括一个 Transact-SQL 脚本，该脚本创建一个名为 proc_DefragmentIndices 的存储过程。您可以使用 proc_DefragmentIndices 来对 Search Server 服务器场中的搜索数据库和内容数据库进行碎片整理。但是，此存储过程需要非常多的服务器资源。因此，必须非常谨慎地使用它以避免降低查询响应速度。

另外，还提供了一个专用于 Search Server 搜索数据库的名为 proc_DefragSearchIndexes 的碎片整理存储过程。它只对那些提供最大性能优势的索引（例如 IX_MSSDocProps 和 IX_MSSDocSdids）进行碎片整理。这在最大程度上减少了对数据库服务器资源的需求。应安排在非高峰时段运行此存储过程，并谨慎监视对用户的影响。

如果诊断服务器场中数据库服务器上的磁盘或 RAID 瓶颈，以下操作可能会降低问题影响：

• 将数据文件和事务日志重定位到不同的磁盘或 RAID 阵列上。正如前文所述，使用文件组可最大化性能。

• 将磁盘添加到 RAID 阵列（如果有）中。

• 将较慢的磁盘更换为较快的磁盘。

避免爬网程序匮乏

在大型或复杂组织中，配置 Search Server 2008 索引系统时需要克服许多难题。您可能拥有许多种类的内容源，其中大量内容需要很长的爬网时间。您还应该小心规划索引条目的新鲜度目标以确保搜索结果反映最新内容。如果您要实现新鲜度目标，则必须优化索引器的性能以便它可以定期对所有内容进行爬网。

索引速度的主要障碍是爬网程序匮乏。当爬网程序无法分配另一个线程来检索队列中的下一个文档时，会处于匮乏状态。匮乏可能由以下原因导致：

• 争用承载搜索数据库的数据库服务器上的资源

• 参与爬网的主机太多

• 主机没有快速释放线程。在本文中，将这些主机称为“饥饿”主机。

• 备份与爬网并发运行

贫瘠主机锁定线程，阻止它移动到下一个文档。此锁定会在以下情况下发生：

• 当主机因缺少 CPU、内存或其他资源而变慢时。

• 当主机需要进行额外的增量爬网时。例如，如果源是 Microsoft SharePoint Portal Server 2003 服务器，则在权限更改时，爬网程序必须重新处理整个文档。

• 主机或文档富含属性。当每个文档包含许多属性时，承载搜索数据库的数据库服务器必须更加努力地工作。业务数据目录内容源和“我的网站”通常富含属性。

最高效的爬网通常发生在以下各类主机上：

• Office SharePoint Server 2007 服务器。这些服务器维护爬网程序可以使用的更改日志。

• 文件共享。爬网程序可以检查文件夹级别的更改，但不检查每个文档。

• Exchange 公用文件夹。爬网程序可以检查文件夹级别的更改，但不检查每个发布。

避免匮乏的指导原则

可以使用以下最佳实践来尽可能减少爬网程序匮乏情况：

• 最小化内容源的数量。这可提高将类似大小和类型的主机分组到单个内容源的效率。

• 首先对大型 Office SharePoint Server 2007 主机进行爬网，然后再添加其他主机类型。这些主机可以非常高效地进行爬网，且增量爬网会非常快地释放线程。

• 不要同时为多个贫瘠主机安排爬网。

• 首先，应计划四个并发爬网。对于某些索引服务器，也许可以增加此值。有关详细信息，请参阅下一节。

• 如果爬网程序变为匮乏状态，请暂停对贫瘠主机进行的爬网，以释放线程。

如何诊断匮乏

在安装新的 Search Server 2008 搜索系统时，花几天或几周的时间通过添加新内容源来构建爬网程序配置。在添加各内容源时监视系统的性能，以避免匮乏和便于进行故障排除。这样，便可以完全了解系统在爬网期间的行为。

爬网程序使用的线程数由“索引器性能”设置决定。若要更改此设置，请在管理中心中单击“操作”选项卡，单击“服务器上的服务”，然后单击“Office SharePoint Server 搜索”。下表显示“索引器性能”设置如何控制爬网线程。

“索引器性能”设置	线程总数	每个主机的最大线程数
减少	处理器数	处理器数
部分减少	处理器数的 4 倍	处理器数加 4
最大数	处理器数的 16 倍	处理器数加 4

在 Search Server 2008 中，爬网线程数从不超过 64。

匮乏的最常见原因是争用数据库服务器上的资源。可以通过监视存档插件来诊断此问题。在性能监视器中，请使用 Office Server Search Archival Plugin 对象以及 Total docs in first queue 和 Total docs in second queue 计数器。如果对于 Portal_Content 实例这些计数器的值都为 500，或对于 ProfileImport 实例这些计数器的值都为 50，则爬网程序将处于匮乏状态。请考虑按照上文的为 Search Server 2008 优化 SQL Server 中所述调整数据库服务器。

可以使用性能监视器中的 Office Server Search Gatherer 对象来诊断不是由存档插件引起的匮乏状态。关注 Idle Threads、Threads Accessing Network 和 Threads In Plug-ins 计数器，并将它们与系统的线程总数作比较。有关这些计数器的完整说明，请参阅上文的监视索引服务器。

避免访问控制列表引起的瓶颈

在 Search Server 2008 对内容源进行爬网和索引时，它会检查访问控制列表 (ACL) 并将其存储在搜索数据库中。当用户搜索索引时，会针对每个结果检查搜索数据库以确保用户有权访问结果。此过程称为安全修整。具有许多嵌套层次的大型 ACL 会对 Search Server 中的爬网过程和搜索的性能产生负面影响。该节介绍如何尽可能减少此类性能影响。

Active Directory 提供了以下种类的安全主体，可用于帮助保护 Search Server 网站和索引内容：

• 用户帐户

• 全局组

• 域本地组

• 通用组

在 Search Server 中，您还有 SharePoint 组。此系统非常灵活，可以包括多层嵌套。但是，如果不谨慎使用，安全主体会对搜索性能产生负面影响。

若要确保 Search Server 爬网程序和搜索获得最大性能，请在使用 Active Directory 安全主体和 SharePoint 组时遵循以下规则：

• 将用户帐户放入全局组中，并将全局组放入域本地组中。为域本地组分配权限。对于在 Active Directory 中使用安全主体，这是推荐的最佳实践。这将确保域控制器可以快速查找组成员身份，并确保用户可以访问整个林中的资源。

• 如果需要通用组，请使用相同系统，但将全局组放入通用组中，并将通用组放入域本地组中。

• 将域本地组放入 SharePoint 组中，为 SharePoint 网站及其他资源分配权限。

• 限制组成员身份中使用的嵌套层数。

以下特定情况会损害搜索性能，应避免发生：

• 不要将 Search Server 网站权限分配给个人用户。

  当网站的 DACL 中列出的安全主体超过 2,000 时，Search Server 网站会变慢。但是，Active Directory 组或 SharePoint 组是单个安全主体，而不管其中包含多少用户。因此，使用 SharePoint 组来分配网站权限并将用户或 Active Directory 组放入 SharePoint 组中。

• 不要使用深度嵌套的 Active Directory 安全组。

  当用户试图访问 Search Server 网站时，服务器必须评估组成员身份才能授权用户。当组深度嵌套时，将需要对域控制器进行许多查询。另外，可能需要对林中的远程域进行查询。必须完成这些查询才能授予用户访问权限。

• 不要使用包含联系人的通讯组列表或安全组。

  例如，可以将 Active Directory 中的联系人添加到组中来分发电子邮件。但是，联系人不是安全主体，不包括在授权中。如果将权限分配给包含联系人的组，性能可能会降低。

在 Search Server 中，每个网站的网站所有者可以将用户和组添加到网站 DACL 中。请务必告知网站所有者如何负责地使用组成员身份以避免出现瓶颈。

解决缺少“搜索框”Web 部件问题

在以下情况下，在搜索中心和 Search Server 2008 用户界面中的其他位置不会出现“搜索框”Web 部件：

• 开发人员修改了搜索中心内容页或网站母版页以隐藏或移除“搜索框”Web 部件。

• 拥有网站完全控制或设计权限级别的用户移除或隐藏了“搜索框”Web 部件。

• 由于服务中断或管理员使搜索服务脱机，搜索服务在 Search Server 服务器场中不可用。

另请参阅

概念

准备对内容进行爬网 (Search Server 2008)
帮助用户成功执行查询 (Search Server 2008)
保护和还原服务器场 (Search Server 2008)
用于执行普通管理操作的权限 (Search Server 2008)
规划内容爬网 (Search Server 2008)