引言
全文索引通过在指定的数据库中对每个字进行检索，从而实现强大而快速的搜索。本文包含有关用 Microsoft® Exchange 2000 Server 部署全文索引的最佳做法。
准备 Exchange 环境
准备 Exchange 环境，使其适用于全文索引。做法是正确地配置服务器并确保 Exchange 组织稳定。
服务器准备
在实现全文索引前，应配置服务器使其达到最佳性能，比如采取添加足够的内存，并将那些较大且频繁受访的文件分布在多个磁盘上等办法。
服务器配置
使用镜像独立磁盘冗余阵列 (RAID) 配置。Microsoft 建议使用 RAID-0+1 配置。该配置可在确保冗余度的情况下达到最佳性能。不建议将 RAID-5 用于全文索引。
磁盘空间要求
Microsoft Search 服务 (MSSearch) 要求包含索引的磁盘（也称为目录）在任何时候都要有 15% 的可用磁盘空间。根据要存储的文件类型，目录的大小可以在数据库大小的 10% 到 30% 之间变化。如果计划维护大量数据，则要将数据库增长率考虑在内。
内存要求
向 Exchange 2000 服务器的建议配置中额外增加 256 兆字节 (MB) 的 RAM。Microsoft 建议不要用小于 512 MB 的 RAM 运行全文索引。
文件的放置
全文索引文件有四个主要类别。通过以如下方式安排这些文件的磁盘位置，可以优化全文索引的性能：
目录 目录是主要的索引。每个 Exchange 信息存储都可以有一个类别。
将目录放在 RAID-0+1 阵列上。创建目录时可以在 System Manager 中指定目录位置。
属性存储 这是一个数据库，其中包含目录中编入索引的各项的各种属性。每台服务器只有一个属性存储。
将全文属性存储放在 RAID 阵列上。默认情况下，这些文件安装在 Exchange Server 所在的驱动器上。若要移动属性存储，请使用位于 Program Files/Common Files/System/MSSearch/Bin 目录下的 PSTOREUTL 实用程序。本文稍后部分的“启动全文索引”一节讲述了移动属性存储的过程。
临时文件 这些文件包含 Microsoft Search 服务使用的临时信息。
将全文索引临时目录放在 RAID 阵列上。默认情况下，这些文件安装在系统驱动器上，该驱动器通常没有 RAID 阵列的 I/O 吞吐量。若要移动临时目录，请使用位于 Program Files/Common Files/System/MSSearch/Bin 目录下的 Settmppath.vbs 实用程序。本文稍后部分的“启动全文索引”讲述了移动临时文件的过程。
注意 如果是在群集中，该临时目录必须位于本地驱动器上。
收集器日志 这些文件包含用于索引服务的日志信息。每个目录都有一个对应的日志集。
收集器日志可以位于默认位置，如果需要也可以移动它们。可以使用下列注册表项指定收集器日志的首选位置：HKLM/Software/Microsoft/Search/1.0/gather/ExchangeServer_<instance>/<catalog name>/StreamLogsDirectory
要确保指定的目录有效。如果指定的目录无效，全文索引就不起作用。
准备 Exchange 2000 组织
在安装全文索引前，要验证 Exchange 2000 服务器或拓扑是否已正确配置且运行正常。如果在安装全文索引后更改 Exchange 组织，就需要对索引进行完全重新填充。此外，还要验证下列事项：
简单邮件传输协议 (SMTP) 地址配置稳定且运行正常。该配置会影响 URL，因为对对象编制索引是按 URL 进行的。
服务器语言设置正确。对语言进行验证的做法是，打开“控制面板”，单击“区域设置”，检查系统的语言设置。全文索引在断字和截取词干时（对“travel”的搜索将返回“travels”、“traveled”和“traveling”的过程）引用指定的服务器语言。当查询语言与编有索引的文件的语言匹配时，全文索引工作起来最轻松。因为在客户机的语言未知时，有时将用服务器语言作为查询语言，所以最好是服务器语言与服务器上的大多数文档相匹配。
所有服务器都正常工作，并且整个组织的连接稳定。应进行充分的测试以确保所有服务器在组织内正确配置。
启动全文索引
使用 Exchange System Manager 对全文索引进行部署。部署包括下列任务：
创建全文索引
优化全文索引
进行完全填充
制定增量填充的日程
启用全文索引查询
通知用户
创建全文索引
必须先创建初始索引，然后才可以使用全文索引。在 System Manager 中，浏览到要编制索引的信息存储中，右击它，然后单击 Create Full-Text Index。会出现一个对话框提示您选择目录（即索引）的位置。在 RAID 阵列上为目录指定一个位置。
优化全文索引
使用下列步骤可以优化 Exchange 服务器上的全文索引。如前所述，通过在 RAID 阵列上分布经常受访的文件，可以增强系统性能。
移动属性存储。
在服务器上创建第一个索引时，Exchange 会在 Exchange 系统驱动器上创建新的属性存储数据库。执行下列每个步骤，以将属性存储数据库文件移到 RAID 阵列，籍此改进性能。对每台服务器，该步骤只要执行一次即可，因为一台服务器上的所有索引都使用同一个属性存储：
停止 Microsoft Search 服务并禁用它。
从命令提示符处使用 PSTOREUTL 实用程序，将该数据库移到新的驱动器中（参见下面的示例）。
重新启用并重新启动 Microsoft Search 服务。
示例:
"C:/Program Files/Common Files/System/MSSearch/Bin/pstoreutl.exe"
exchangeserver_<servername> -M
"d:/exchsrvr/ExchangeServer_<servername>/ExchangeServer_<servername>.edb" -L
"d:/exchsrvr/ExchangeServer_<servername>"
在前一个示例中，驱动器 C 是属性存储的当前位置。驱动器 D 是要将属性存储移往的目的位置。
移动临时 (/temp) 目录。
从命令提示符处，移动 Microsoft Search 临时目录（参见下面示例中的语法）。
如前所述，默认情况下，收集器和筛选器的临时文件（也称 temp 文件）位于 Exchange 系统驱动器上，该驱动器通常没有 RAID 阵列的 I/O 吞吐量。若要移动临时目录，请使用位于 Program Files/Common Files/System/MSSearch/Bin 目录下的 Settmppath.vbs 实用程序。对每台服务器，该步骤只要执行一次即可，因为一台服务器上的所有索引都使用同一个临时目录。
示例:
cscript "c:/Program Files/Common Files/System/MSSearch/Bin/settemppath.vbs" d:/temp
注意 如果是在群集中，该临时目录必须位于本地驱动器上。
进行完全填充
在创建索引后，必须运行完全填充（也称爬行）在索引中填充数据。全文索引的资源使用设置位于服务器 Properties 对话框的 Full-Text Indexing 选项卡上。默认情况下，它设为 Low。Microsoft 建议使用默认设置。更高的设置不会带来相应的收效，而且可能减慢客户机对 Exchange 服务器的访问速度。
如果使用较低的资源使用设置，填充进程会在后台运行，并可在营业时间内进行。填充期间所用的线程使用空闲的处理时间。用户活动在系统上优先。由于全文索引只使用空闲不用的周期，因此索引不会显著减慢客户机对服务器的访问速度。填充进程通常的效果是，CPU 使用率会接近 100%。
若要启动完全填充：
在 Exchange System Manager 中，浏览到要编制索引的信息存储，右键单击它，然后单击 Start Full Population。
初始完全填充可能需要花很长时间。如果使用典型的 Exchange 2000 配置，填充性能通常为每秒 10 到 20 个消息。性能会根据硬件的配置、消息的类型和大小、可用的服务器资源而有所变化。结果是，完全填充所需的总时间为几分钟（对于小型数据库）到数日（对于大型数据库）不等。另外，服务器上文档的内容语言也会影响填充所需时间。例如，如果服务器包含的多数内容是东亚语言文档，那么填充该服务器需要的时间是西方语言文档所花时间的五倍多。
可展开公用文件夹或信箱存储，并单击 Full-Text Indexing 来查看填充的状态。在初始填充期间，状态是 Crawling。可以查看该状态或查阅 Event Viewer 中的“Microsoft Search”消息，确定填充是否完成。
注意 当完全填充仍在进行时不要将它停止。如果必须停止完全填充，但以后想再重新运行它，请单击 Pause Population，而不要单击 Stop Population。
若要暂停完全填充：
在 System Manager 中，浏览到要编制索引的邮箱或公用文件夹存储，右键单击它，然后单击 Pause Population。
设置增量填充的日程
确定要以怎样的频率运行增量填充来更新索引。因为增量填充与完全填充一样在后台运行，所以经常性的更新并不会显著影响对用户的响应时间。典型的日程设置在每个小时的开始进行增量更新。这种情况下，如果更新持续时间超过一小时，下次增量爬行就会在下一小时开始时进行。
若要设置增量填充日程：
在 System Manager 中，浏览到要编制索引的邮箱或公用文件夹存储中，右键单击它，再单击 Properties，然后单击 Full-Text Indexing 选项卡。
在 Update Interval 中，选择一个间隔日程。 通常，不需要设置 Rebuild Interval。只要设置 Update Interval 就够了。
启用全文索引查询
在初始填充后，至少有一次增量填充完成时，启用索引进行查询：
在 System Manager 中，浏览到要启用的信息存储，右键单击它，然后单击 Properties。
单击 Full-Text Indexing，然后单击 This index is currently available for searching by clients。
通知用户
在邮箱服务器上安装全文索引后，请通知用户并告诉他们在运行全文索引搜索时可能预期什么。
下面是可以发送给用户的简单电子邮件示例；
尊敬的用户：
现在已对服务器上的所有邮箱启用了全文索引 (FTI)。在使用 Outlook 的“高级查找”选项时，您可能会注意到有些区别 - 最大的区别要算速度！
请注意，Outlook 只在使用“工具”菜单上的“高级查找”选项时才执行 FTI 搜索。使用“查找”选项会进行传统的、基于字符的搜索。它并不使用全文检索。
若要验证 FTI 是否已打开，对“干扰性”的字（如“the”）进行搜索。因为 FTI 将干扰性的字排除在外，应该立即获得零结果（假设所有网络连接都正常）。干扰性的字是冠词或词的片段。全文索引会筛选掉这些字。
下面的列表说明了 Outlook 2000 中 FTI 与基于字符的搜索之间的其他区别：
不仅可获得附件的匹配，还可获得消息。
可获得相关字的匹配，这要由所选语言的取词干器确定。取词干器使用语言设置确定与搜索字相关的字。例如，英语取词干器认为“tester”、“tested”和“tests”是等价的，但“testament”只与“testaments”等价。
您不会获得自完成最后一次填充（每日或每小时）以来接收消息的匹配。
不支持模式匹配。FTI 只搜索完整的字。对“test”的搜索与“testament”不匹配；对“mod”的搜索与“model”不匹配。不支持通配符。
干扰性的字会从查询中删除。这意味着对“michael p”的搜索会只对“michael”进行搜索，因为“p”是干扰性的字；对“the truth”的搜索会只对“truth”进行搜索。
其他功能不变：
若要进行 AND 查询以搜索组合字，只要以空格分隔各字即可。若要执行返回任何一个字的 OR 查询，请用逗号将查询中的字分隔开。
可以用引号将词组括起来以搜索整个词组。例如，对“asp files”文件的搜索只与连续出现的这两个字匹配。
如果没有引号，对两个字的搜索就会返回任何同时含有这两个字的项。对“asp files”（没有引号）的搜索将返回既有“asp”又有“file”的项或有相应词干的词。
谢谢！
电子邮件支持小组
使用全文检索
通过使用 Outlook 客户程序，用户可以通过“工具”菜单上的“高级查找”选项使用全文索引。使用“查找”选项只执行基于字符的搜索。
全文索引行为
习惯基于字符搜索的用户会注意到在使用全文检索时有所不同。特别是，最近接收到的邮件不出现在
基于字符的搜索与全文检索之间的区别还有：
大范围的搜索要比基于字符的搜索快一些。
对常用字的搜索要比对冷僻字的搜索要慢一些。不过，几乎在所有情况下，全文检索要比旧的“字符串查找”样式搜索要快一些，所花的服务器开销也要低得多。
搜索除返回消息外，还可返回附件。
全文检索能返回相关的字，这要由所选语言的取词干器决定。例如，取词干器认为“tester”、“tested”和“tests”是一样的，但认为“testament”只与“testaments”等同。
搜索不返回自完成最后一次填充以来接收到的消息。
不支持模式匹配；仅搜索整个字。因此，对“test”的搜索不与“testament”匹配；对“mod”的搜索不与“model”匹配。不使用通配符。
干扰性的字从查询中删除。这意味着对“michael p”的查询只会对“michael”进行搜索，因为“p”是干扰性的字；对“the truth”的查询只会对“truth”进行搜索。
使用全文索引得到的搜索结果不是动态的。这体现在两个方面。
如果有一个与查询匹配的新消息到达，搜索结果的视图不会更新。这是因为还未对新消息编制索引。在下次增量爬行或填充时将对它编制索引。
如果用户从搜索结果中显示的文件夹内删除消息，则实际消息就会被删除，但该文件夹的视图仍显示被删除的消息。重复查询会从查询结果中去除已删除的消息。
当 Outlook 遇到逗号时，会执行 OR 查询。例如，对“section, particularly”（没有引号）的搜索会找到所有含有“section”或含有“particularly”的文档。若要搜索后面为“particularly”的“section”，就要用引号将该词组括起来，即 “"section particularly"”。
管理全文索引
移动目录（索引）
若要移动目录，请使用位于Exchange 服务器上 Program Files/Common Files/System/MSSearch/Bin 目录下的 Catutil 实用程序 (catutil.exe)。在运行该实用程序以前，要先停止所有活动的全文索引，然后停止并禁用搜索服务 (MSSearch)。有关该实用程序的使用帮助，请到命令提示符中，键入 catutil movecat /?。
注意 如果使用这种方法移动目录，Exchange System Manager 中显示的 Index Location 可能不会更新。目录移动成功，并且工作正常，但 Exchange System Manager 可能不会正确显示目录的原始位置。这只是一个显示错误，并不影响全文索引的正常操作。
将用户添加到索引服务器中
在将用户添加到索引服务器时，要执行增量填充才能立即向索引中添加新邮箱。
设置增量填充的日程
确定想以怎样的频率运行增量填充来更新索引。因为增量填充与完全填充一样在后台运行，所以经常性的更新并不会显著影响对用户的响应时间。典型的日程设置在每个小时的开始进行增量更新。如果更新持续时间超过一小时，下次增量爬行就会在下一小时开始时进行。
何时需要新的完全填充？
在下列情况下，必须对索引进行完全填充。
“断字器”发生更改（断字器由全文索引用来在给定文本中识别单个字从哪开始、到哪结束）
干扰性的字发生更改
添加了新的文档格式筛选器
架构文件发生更改
存储的 SMTP 地址发生更改
要进行灾难恢复
在填充进程期间，索引仍可用于全文查询。只有在重新创建目录之前必须先删除原有目录，并进行新的完全填充时，索引才无法用于查询。只有在原有目录遭到破坏时，才有必要这样。
发现填充进程处于暂停状态
如果填充进程无法继续，Microsoft Search 服务 (MSSearch) 会将它暂停。若要验证是 MSSearch 还是管理员暂停了填充，就要检查事件日志。只要发生暂停或停止填充之类的事件，MSSearch 总会将该事件记录下来。例如，如果磁盘过满，无法再添加目录或日志文件，MSSearch 就会暂停填充。通常，您可以解决该问题（例如，释放已满驱动器上的空间）并恢复填充。在暂停期间添加的文档，直到下一次填充时才会添加到索引中。
注意 硬盘驱动器上的空间容易出问题，即使看似有大量可用空间也是如此。MSSearch 会不受限制地使用磁盘空间，暂时解压缩大部分目录，以便合并新的结果，然后再重新压缩。
监视全文索引
使用 System Monitor 以及 Performance Logs 和 Alerts 监视全文索引。
要监视的性能对象
有五个对象含有可监视的计数器，便于评估全文索引：
Microsoft Gatherer
Microsoft Gatherer Projects
Microsoft Search
Microsoft Search Catalogs
Microsoft Search Indexer Catalogs
在下一节中将讲述这些对象的有用的计数器。
与填充相关的计数器
在 Microsoft Gatherer 和 Microsoft Gatherer Projects 对象中使用下列计数器可以监视索引填充：
Microsoft Gatherer: Documents Filtered 已经筛选的文档的数目，或是已经编制索引的文档的数目。
Microsoft Gatherer: Performance Level 性能级别从 1 到 4 之间变化，由 Exchange System Manager 设置。（1 = 最低，2 =低，3 = 高，4 = 最高）
Microsoft Gatherer: System IO traffic rate 显示用于确定是否要减少爬行处理的 I/O 率。有关 I/O 诊断的详细信息，请参见物理磁盘计数器。
Microsoft Gatherer: Reason to back off 该计数器显示说明为何收集服务中止了填充的代码。
0 - 开始运行
1 - 高 IO 率
4 - 在用户活动时中止（默认情况下，在服务器安装时会禁用它）
5 - 电池电量低（如果当前是靠电池运行，而不靠 AC 电源）
6 - 内存不足（页面文件中所剩内存不足 5 MB）
Microsoft Gatherer Projects: Crawl in Progress Flag 该标志包含 0 或 1，表示是否运行爬行：0 = 运行爬行，1 = 不运行爬行。
Microsoft Gatherer Projects: Current Crawl is Incremental 该标志包含 0 或 1，表示爬行是否为增量爬行：0 = 增量爬行，1 = 完全爬行。
Microsoft Gatherer Projects: Gatherer Paused Flag 该标志包含 0 或 1，表示爬行是否为暂停爬行：0 = 非暂停爬行，1 = 暂停爬行。
Microsoft Gatherer Projects: URLs in History 该标志显示全文索引所知道的 URL（文件夹和文档）总数。
Microsoft Gatherer Projects: Waiting Documents 该标志显示等待爬行的文档总数。该数目在爬行开始时增加，因为在标识新的 URL，然后在爬行过程中减少。
Microsoft Search Indexer Catalogs: Merge Progress 该标志显示索引合并的完成百分比。
与查询相关的计数器
下面的 Microsoft Search Catalogs 计数器包含有关全文索引查询的信息。使用它们可以监视针对全文索引进行的查询。
Microsoft Search 对象包含 Microsoft Search Catalogs 对象中四个独立目录中值的总计。
Microsoft Search Catalogs: Queries 该计数器显示所执行的查询总数。
Microsoft Search Catalogs: Successful Queries 该计数器显示成功完成的查询数目。
Microsoft Search Catalogs: Results 该计数器显示所返回的经剪裁后符合查询范围的行数。
Microsoft Search Catalogs：Failed Queries 该计数器显示失败的查询数目（例如，包含干扰字的查询）。
与一般性能相关的计数器
使用下面计数器可以监视一般性能。
CPU 使用率
使用下面计数器可以监视 CPU 使用率。请记住，在完全填充期间，CPU 使用率通常会达到 100%。
Processor: % Processor Time 该计数器的范围为 0 到 100%。
Process: % Processor Time 该计数器的范围为 0 到 100 *N 个处理器 %。请从下列实例中进行选择：“store”是 Exchange Information Store 进程，“mssearch”是搜索进行，“mssdmn”是索引进程。
磁盘使用率
使用下面的计数器可以监视磁盘使用率。在运行全文索引时必须有足够的可用磁盘空间。如果磁盘空间不够，可能会导致严重问题。目录（索引）可能会损坏，并且可能发生其它系统问题。
Physical Disk: Current Disk Queue Length 这一数字在磁盘系统中不应超过每主轴 1 或 2 个。磁盘队列长度过长说明存在瓶颈。该计数通常应回零。极少回零或从不回零的磁盘队列长度也说明存在瓶颈。
Physical Disk:Avg. Disk sec./read 该计数器显示每次磁盘读取所花费的时间。这一时间值通常约为 10 毫秒。如果磁盘很忙，该值就会极高。
Physical Disk:Avg. Disk sec./write 该计数器显示每次磁盘写入所花费的时间。通常，该值大约为 10 毫秒；但带有回写缓存的 RAID 阵列大约有 1 毫秒的写时间，因为信息保留在控制器的缓存中。另外，当磁盘变忙时，这个数字也会变大。
Physical Disk: Disk Transfers/sec 该计数器显示每秒磁盘写入和读取次数总和。大多数单主轴都具有每秒 100 到 150 次传输的最大范围。
内存使用率
使用下面的计数器可以监视内存使用率：
Memory: Available Mbytes 该计数器列出计算机上的可用内存。
Process: Virtual Address Space 该计数器显示保留的内存（包括虚拟分配）。
Process: Private Bytes 该计数器显示专为该进程分配的总内存量；例如，数据库缓存。该计数器不包括句柄和共享内存。
Process: Working Set 该计数器显示 RAM 中实际分配的内存（等于 Task Manager 的 Memory Usage）。暂停全文索引爬行会导致它的工作集减少到大约 2 MB。
分页
使用下面的计数器可以监视分页：
Memory: Pages/sec 该计数器显示每秒硬分页（到磁盘）的数量。但是，可以在单个磁盘读/写中处理多个页。
Memory: Page Writes/sec 该计数器显示每秒用于分页的磁盘写入次数。
Memory: Page Reads/sec 该计数器显示每秒用于分页的磁盘读取次数。
Process: Page Faults/sec 该计数器显示每秒硬分页错误（到磁盘）和软分页错误（在内存中）。
如果 Pages/sec 计数器值较高（例如，超过 100），就要查看生成大多数分页错误的进程，因为很可能需要进行改正。如果它是信息存储，就要检查：
Database: Database Cache Size 该计数器显示数据库缓存的大小。若缓存小，会导致分页速度高，因为数据库的缓存会更频繁地交换回磁盘。
故障排除
收集器日志
收集器日志文件在填充期间生成。这些文件包含有关索引服务的日志信息。它们位于 /Exchsrvr/ExchangeServer/GatherLogs 目录下。扩展名为 .gthr。
如果无法对特定文档编制索引，无论原因如何，都会在收集器日志文件中加入一条记录。每条记录都列出文件名和错误号。若要对该错误号进行解码，请使用位于 /Program Files/Common Files/System/MSSearch/Bin 目录下的 Gthrlog.vbs 实用程序。该实用程序的语法如下：
cscript gthrlog.vbs <filename>
其中，filename 是 .gthr 文件的名称。请从命令提示符处使用 Gthrlog.vbs 实用程序。该实用程序产生的结果显示在命令提示符处。
混合语言的全文索引规则
在混合语言情况下，全文索引的规则很复杂。下列情况解释了各种语言设置如何影响索引行为。管理员使用这些指导原则确定用户报告的搜索问题产生的原因。
单个消息的语言设置
单个消息的语言设置会在下列几个方面影响索引行为：
如果消息是 MAPI 消息，它就具有区域 ID 属性，并且全文索引使用该值确定要使用哪个断字器。该属性值来自客户机上的 Office 语言设置。如果全文索引找不到与区域 ID 属性匹配的断字器，它就会使用 Neutral <0> 属性。
如果消息是用 Distributed Authoring and Versioning (DAV) 创建的，它就使用“Accept-Language”标题确定正确的区域。
如果消息未标识区域（通常是指来自 Internet 的消息），就使用服务器的“系统区域”。服务器是用来存储消息的 Exchange 2000 服务器，全文索引在其中执行。
附件的语言设置
附件的语言设置在下列几个方面影响索引行为：
如果附件是 Microsoft Office 文档，那么全文索引就使用用于生成该文档的语言设置。
运行 Microsoft Windows® 2000 的服务器的语言设置
服务器的语言设置在以下方面影响索引行为：
如果消息为非 MAPI 消息（即 Internet 消息），它的区域 ID 属性未设置，全文索引使用服务器的“系统区域”设置来确定使用哪个断字器。
客户机的语言设置
客户机的语言设置在以下方面影响索引行为：
在从 Outlook 发送查询时，也会发送客户机的区域 ID。如果消息的区域 ID 不与查询的区域 ID 匹配，搜索结果就不可预知。
注意 Exchange 服务器的语言在上一种情况下是无关的。客户机设置优先。
混合语言环境下的全文索引行为
下面的示例说明了具有各种语言设置的内容索引的查询行为。
全部美国语言设置
如果使用在美国客户机上运行的美国 Outlook，撰写消息并发送到在带有美国设置的 Windows 2000 服务器上运行的 Exchange 2000，就会发生下列情况：
全文索引使用美国断字器对消息编制索引。
如预期的那样处理来自美国客户机的查询。
希伯来文客户机、美国Office 设置、希伯来文 Windows 2000
如果使用希伯来文 Outlook，在 Office 设置为美国的希伯来文客户机上运行，撰写消息并将其发送到在“系统区域”设置为美国的服务器上运行的 Exchange 2000，就会发生下列情况：
全文索引使用美国断字器对消息编制索引。因为 Office 设置的缘故，消息的区域 ID 属性默认为美国。
来自希伯来文客户机的查询失败，原因是希伯来文文档没有应用正确的断字器。
日文客户机、日文 Office 设置、美国 Windows 2000
如果使用日文 Outlook，在 Office 设置为美国的日文客户机上运行，撰写消息并发送到在“系统区域”设置为美国的服务器上运行的 Exchange 2000，就会发生下列情况：
全文索引使用日文断字器对消息编制索引。
来自日文客户机的查询成功，原因是消息是用同样的区域 ID 编制索引和查询的。
初始化期间的查询
初始化期间，在启动具有全文索引的 Exchange 服务器的最初几分钟内，用户可以获得自己的邮件但得不到查询结果。这是因为搜索服务 MSSearch 正在加载索引，Exchange 正在加载属性存储。查询在这些过程完成后才返回结果。
缺失的性能计数器
与下列消息类似的事件消息表明由 System Monitor、Performance Logs 和 Alerts 使用的计数器缺失。如果接收到下列一条消息，就要通过重新启动 MSSearch 而恢复计数器。
Performance monitoring for the Gatherer service cannot be initialized because the counters are not loaded or the shared memory object cannot be opened. This only affects availability of the performance counters. Rebooting the system may fix the problem.
Performance monitoring cannot be initialized for the Gatherer object because the counters are not loaded or the shared memory object cannot be opened. This only affects availability of the performance counters. Rebooting the system may fix the problem.
Performance monitoring for the Indexer object cannot be initialized because the counters are not loaded or the shared memory object cannot be opened. Stop and restart the Search service. If this error continues, reinstall the application.
磁盘瓶颈
为避免磁盘瓶颈，请使用下列指导原则：
注意 有关详细信息，请参见前一节“要监视的性能对象”。
监视磁盘队列长度。
队列长度预期的平均值为 RAID 阵列中的主轴数略多。
长度应偶尔降为零。
队列应偶尔为空。如果队列总不为空，就说明有问题了。
每次磁盘写入和磁盘读取的平均时间应接近预期的等待时间。系统应花约 10 秒钟时间进行磁盘读/写。如果配置有硬盘缓存或 RAID 控制器，时间可能会更少。
内存瓶颈
高的分页速度可能表明存在内存瓶颈。请检查前面列出的性能计数器，并监视它们是否出现警告信号。特别要检查 Memory: Page writes/sec and Memory: Page reads/sec。
全文索引通过在指定的数据库中对每个字进行检索，从而实现强大而快速的搜索。本文包含有关用 Microsoft® Exchange 2000 Server 部署全文索引的最佳做法。
准备 Exchange 环境
准备 Exchange 环境，使其适用于全文索引。做法是正确地配置服务器并确保 Exchange 组织稳定。
服务器准备
在实现全文索引前，应配置服务器使其达到最佳性能，比如采取添加足够的内存，并将那些较大且频繁受访的文件分布在多个磁盘上等办法。
服务器配置
使用镜像独立磁盘冗余阵列 (RAID) 配置。Microsoft 建议使用 RAID-0+1 配置。该配置可在确保冗余度的情况下达到最佳性能。不建议将 RAID-5 用于全文索引。
磁盘空间要求
Microsoft Search 服务 (MSSearch) 要求包含索引的磁盘（也称为目录）在任何时候都要有 15% 的可用磁盘空间。根据要存储的文件类型，目录的大小可以在数据库大小的 10% 到 30% 之间变化。如果计划维护大量数据，则要将数据库增长率考虑在内。
内存要求
向 Exchange 2000 服务器的建议配置中额外增加 256 兆字节 (MB) 的 RAM。Microsoft 建议不要用小于 512 MB 的 RAM 运行全文索引。
文件的放置
全文索引文件有四个主要类别。通过以如下方式安排这些文件的磁盘位置，可以优化全文索引的性能：
目录 目录是主要的索引。每个 Exchange 信息存储都可以有一个类别。
将目录放在 RAID-0+1 阵列上。创建目录时可以在 System Manager 中指定目录位置。
属性存储 这是一个数据库，其中包含目录中编入索引的各项的各种属性。每台服务器只有一个属性存储。
将全文属性存储放在 RAID 阵列上。默认情况下，这些文件安装在 Exchange Server 所在的驱动器上。若要移动属性存储，请使用位于 Program Files/Common Files/System/MSSearch/Bin 目录下的 PSTOREUTL 实用程序。本文稍后部分的“启动全文索引”一节讲述了移动属性存储的过程。
临时文件 这些文件包含 Microsoft Search 服务使用的临时信息。
将全文索引临时目录放在 RAID 阵列上。默认情况下，这些文件安装在系统驱动器上，该驱动器通常没有 RAID 阵列的 I/O 吞吐量。若要移动临时目录，请使用位于 Program Files/Common Files/System/MSSearch/Bin 目录下的 Settmppath.vbs 实用程序。本文稍后部分的“启动全文索引”讲述了移动临时文件的过程。
注意 如果是在群集中，该临时目录必须位于本地驱动器上。
收集器日志 这些文件包含用于索引服务的日志信息。每个目录都有一个对应的日志集。
收集器日志可以位于默认位置，如果需要也可以移动它们。可以使用下列注册表项指定收集器日志的首选位置：HKLM/Software/Microsoft/Search/1.0/gather/ExchangeServer_<instance>/<catalog name>/StreamLogsDirectory
要确保指定的目录有效。如果指定的目录无效，全文索引就不起作用。
准备 Exchange 2000 组织
在安装全文索引前，要验证 Exchange 2000 服务器或拓扑是否已正确配置且运行正常。如果在安装全文索引后更改 Exchange 组织，就需要对索引进行完全重新填充。此外，还要验证下列事项：
简单邮件传输协议 (SMTP) 地址配置稳定且运行正常。该配置会影响 URL，因为对对象编制索引是按 URL 进行的。
服务器语言设置正确。对语言进行验证的做法是，打开“控制面板”，单击“区域设置”，检查系统的语言设置。全文索引在断字和截取词干时（对“travel”的搜索将返回“travels”、“traveled”和“traveling”的过程）引用指定的服务器语言。当查询语言与编有索引的文件的语言匹配时，全文索引工作起来最轻松。因为在客户机的语言未知时，有时将用服务器语言作为查询语言，所以最好是服务器语言与服务器上的大多数文档相匹配。
所有服务器都正常工作，并且整个组织的连接稳定。应进行充分的测试以确保所有服务器在组织内正确配置。
启动全文索引
使用 Exchange System Manager 对全文索引进行部署。部署包括下列任务：
创建全文索引
优化全文索引
进行完全填充
制定增量填充的日程
启用全文索引查询
通知用户
创建全文索引
必须先创建初始索引，然后才可以使用全文索引。在 System Manager 中，浏览到要编制索引的信息存储中，右击它，然后单击 Create Full-Text Index。会出现一个对话框提示您选择目录（即索引）的位置。在 RAID 阵列上为目录指定一个位置。
优化全文索引
使用下列步骤可以优化 Exchange 服务器上的全文索引。如前所述，通过在 RAID 阵列上分布经常受访的文件，可以增强系统性能。
移动属性存储。
在服务器上创建第一个索引时，Exchange 会在 Exchange 系统驱动器上创建新的属性存储数据库。执行下列每个步骤，以将属性存储数据库文件移到 RAID 阵列，籍此改进性能。对每台服务器，该步骤只要执行一次即可，因为一台服务器上的所有索引都使用同一个属性存储：
停止 Microsoft Search 服务并禁用它。
从命令提示符处使用 PSTOREUTL 实用程序，将该数据库移到新的驱动器中（参见下面的示例）。
重新启用并重新启动 Microsoft Search 服务。
示例:
"C:/Program Files/Common Files/System/MSSearch/Bin/pstoreutl.exe"
exchangeserver_<servername> -M
"d:/exchsrvr/ExchangeServer_<servername>/ExchangeServer_<servername>.edb" -L
"d:/exchsrvr/ExchangeServer_<servername>"
在前一个示例中，驱动器 C 是属性存储的当前位置。驱动器 D 是要将属性存储移往的目的位置。
移动临时 (/temp) 目录。
从命令提示符处，移动 Microsoft Search 临时目录（参见下面示例中的语法）。
如前所述，默认情况下，收集器和筛选器的临时文件（也称 temp 文件）位于 Exchange 系统驱动器上，该驱动器通常没有 RAID 阵列的 I/O 吞吐量。若要移动临时目录，请使用位于 Program Files/Common Files/System/MSSearch/Bin 目录下的 Settmppath.vbs 实用程序。对每台服务器，该步骤只要执行一次即可，因为一台服务器上的所有索引都使用同一个临时目录。
示例:
cscript "c:/Program Files/Common Files/System/MSSearch/Bin/settemppath.vbs" d:/temp
注意 如果是在群集中，该临时目录必须位于本地驱动器上。
进行完全填充
在创建索引后，必须运行完全填充（也称爬行）在索引中填充数据。全文索引的资源使用设置位于服务器 Properties 对话框的 Full-Text Indexing 选项卡上。默认情况下，它设为 Low。Microsoft 建议使用默认设置。更高的设置不会带来相应的收效，而且可能减慢客户机对 Exchange 服务器的访问速度。
如果使用较低的资源使用设置，填充进程会在后台运行，并可在营业时间内进行。填充期间所用的线程使用空闲的处理时间。用户活动在系统上优先。由于全文索引只使用空闲不用的周期，因此索引不会显著减慢客户机对服务器的访问速度。填充进程通常的效果是，CPU 使用率会接近 100%。
若要启动完全填充：
在 Exchange System Manager 中，浏览到要编制索引的信息存储，右键单击它，然后单击 Start Full Population。
初始完全填充可能需要花很长时间。如果使用典型的 Exchange 2000 配置，填充性能通常为每秒 10 到 20 个消息。性能会根据硬件的配置、消息的类型和大小、可用的服务器资源而有所变化。结果是，完全填充所需的总时间为几分钟（对于小型数据库）到数日（对于大型数据库）不等。另外，服务器上文档的内容语言也会影响填充所需时间。例如，如果服务器包含的多数内容是东亚语言文档，那么填充该服务器需要的时间是西方语言文档所花时间的五倍多。
可展开公用文件夹或信箱存储，并单击 Full-Text Indexing 来查看填充的状态。在初始填充期间，状态是 Crawling。可以查看该状态或查阅 Event Viewer 中的“Microsoft Search”消息，确定填充是否完成。
注意 当完全填充仍在进行时不要将它停止。如果必须停止完全填充，但以后想再重新运行它，请单击 Pause Population，而不要单击 Stop Population。
若要暂停完全填充：
在 System Manager 中，浏览到要编制索引的邮箱或公用文件夹存储，右键单击它，然后单击 Pause Population。
设置增量填充的日程
确定要以怎样的频率运行增量填充来更新索引。因为增量填充与完全填充一样在后台运行，所以经常性的更新并不会显著影响对用户的响应时间。典型的日程设置在每个小时的开始进行增量更新。这种情况下，如果更新持续时间超过一小时，下次增量爬行就会在下一小时开始时进行。
若要设置增量填充日程：
在 System Manager 中，浏览到要编制索引的邮箱或公用文件夹存储中，右键单击它，再单击 Properties，然后单击 Full-Text Indexing 选项卡。
在 Update Interval 中，选择一个间隔日程。 通常，不需要设置 Rebuild Interval。只要设置 Update Interval 就够了。
启用全文索引查询
在初始填充后，至少有一次增量填充完成时，启用索引进行查询：
在 System Manager 中，浏览到要启用的信息存储，右键单击它，然后单击 Properties。
单击 Full-Text Indexing，然后单击 This index is currently available for searching by clients。
通知用户
在邮箱服务器上安装全文索引后，请通知用户并告诉他们在运行全文索引搜索时可能预期什么。
下面是可以发送给用户的简单电子邮件示例；
尊敬的用户：
现在已对服务器上的所有邮箱启用了全文索引 (FTI)。在使用 Outlook 的“高级查找”选项时，您可能会注意到有些区别 - 最大的区别要算速度！
请注意，Outlook 只在使用“工具”菜单上的“高级查找”选项时才执行 FTI 搜索。使用“查找”选项会进行传统的、基于字符的搜索。它并不使用全文检索。
若要验证 FTI 是否已打开，对“干扰性”的字（如“the”）进行搜索。因为 FTI 将干扰性的字排除在外，应该立即获得零结果（假设所有网络连接都正常）。干扰性的字是冠词或词的片段。全文索引会筛选掉这些字。
下面的列表说明了 Outlook 2000 中 FTI 与基于字符的搜索之间的其他区别：
不仅可获得附件的匹配，还可获得消息。
可获得相关字的匹配，这要由所选语言的取词干器确定。取词干器使用语言设置确定与搜索字相关的字。例如，英语取词干器认为“tester”、“tested”和“tests”是等价的，但“testament”只与“testaments”等价。
您不会获得自完成最后一次填充（每日或每小时）以来接收消息的匹配。
不支持模式匹配。FTI 只搜索完整的字。对“test”的搜索与“testament”不匹配；对“mod”的搜索与“model”不匹配。不支持通配符。
干扰性的字会从查询中删除。这意味着对“michael p”的搜索会只对“michael”进行搜索，因为“p”是干扰性的字；对“the truth”的搜索会只对“truth”进行搜索。
其他功能不变：
若要进行 AND 查询以搜索组合字，只要以空格分隔各字即可。若要执行返回任何一个字的 OR 查询，请用逗号将查询中的字分隔开。
可以用引号将词组括起来以搜索整个词组。例如，对“asp files”文件的搜索只与连续出现的这两个字匹配。
如果没有引号，对两个字的搜索就会返回任何同时含有这两个字的项。对“asp files”（没有引号）的搜索将返回既有“asp”又有“file”的项或有相应词干的词。
谢谢！
电子邮件支持小组
使用全文检索
通过使用 Outlook 客户程序，用户可以通过“工具”菜单上的“高级查找”选项使用全文索引。使用“查找”选项只执行基于字符的搜索。
全文索引行为
习惯基于字符搜索的用户会注意到在使用全文检索时有所不同。特别是，最近接收到的邮件不出现在
基于字符的搜索与全文检索之间的区别还有：
大范围的搜索要比基于字符的搜索快一些。
对常用字的搜索要比对冷僻字的搜索要慢一些。不过，几乎在所有情况下，全文检索要比旧的“字符串查找”样式搜索要快一些，所花的服务器开销也要低得多。
搜索除返回消息外，还可返回附件。
全文检索能返回相关的字，这要由所选语言的取词干器决定。例如，取词干器认为“tester”、“tested”和“tests”是一样的，但认为“testament”只与“testaments”等同。
搜索不返回自完成最后一次填充以来接收到的消息。
不支持模式匹配；仅搜索整个字。因此，对“test”的搜索不与“testament”匹配；对“mod”的搜索不与“model”匹配。不使用通配符。
干扰性的字从查询中删除。这意味着对“michael p”的查询只会对“michael”进行搜索，因为“p”是干扰性的字；对“the truth”的查询只会对“truth”进行搜索。
使用全文索引得到的搜索结果不是动态的。这体现在两个方面。
如果有一个与查询匹配的新消息到达，搜索结果的视图不会更新。这是因为还未对新消息编制索引。在下次增量爬行或填充时将对它编制索引。
如果用户从搜索结果中显示的文件夹内删除消息，则实际消息就会被删除，但该文件夹的视图仍显示被删除的消息。重复查询会从查询结果中去除已删除的消息。
当 Outlook 遇到逗号时，会执行 OR 查询。例如，对“section, particularly”（没有引号）的搜索会找到所有含有“section”或含有“particularly”的文档。若要搜索后面为“particularly”的“section”，就要用引号将该词组括起来，即 “"section particularly"”。
管理全文索引
移动目录（索引）
若要移动目录，请使用位于Exchange 服务器上 Program Files/Common Files/System/MSSearch/Bin 目录下的 Catutil 实用程序 (catutil.exe)。在运行该实用程序以前，要先停止所有活动的全文索引，然后停止并禁用搜索服务 (MSSearch)。有关该实用程序的使用帮助，请到命令提示符中，键入 catutil movecat /?。
注意 如果使用这种方法移动目录，Exchange System Manager 中显示的 Index Location 可能不会更新。目录移动成功，并且工作正常，但 Exchange System Manager 可能不会正确显示目录的原始位置。这只是一个显示错误，并不影响全文索引的正常操作。
将用户添加到索引服务器中
在将用户添加到索引服务器时，要执行增量填充才能立即向索引中添加新邮箱。
设置增量填充的日程
确定想以怎样的频率运行增量填充来更新索引。因为增量填充与完全填充一样在后台运行，所以经常性的更新并不会显著影响对用户的响应时间。典型的日程设置在每个小时的开始进行增量更新。如果更新持续时间超过一小时，下次增量爬行就会在下一小时开始时进行。
何时需要新的完全填充？
在下列情况下，必须对索引进行完全填充。
“断字器”发生更改（断字器由全文索引用来在给定文本中识别单个字从哪开始、到哪结束）
干扰性的字发生更改
添加了新的文档格式筛选器
架构文件发生更改
存储的 SMTP 地址发生更改
要进行灾难恢复
在填充进程期间，索引仍可用于全文查询。只有在重新创建目录之前必须先删除原有目录，并进行新的完全填充时，索引才无法用于查询。只有在原有目录遭到破坏时，才有必要这样。
发现填充进程处于暂停状态
如果填充进程无法继续，Microsoft Search 服务 (MSSearch) 会将它暂停。若要验证是 MSSearch 还是管理员暂停了填充，就要检查事件日志。只要发生暂停或停止填充之类的事件，MSSearch 总会将该事件记录下来。例如，如果磁盘过满，无法再添加目录或日志文件，MSSearch 就会暂停填充。通常，您可以解决该问题（例如，释放已满驱动器上的空间）并恢复填充。在暂停期间添加的文档，直到下一次填充时才会添加到索引中。
注意 硬盘驱动器上的空间容易出问题，即使看似有大量可用空间也是如此。MSSearch 会不受限制地使用磁盘空间，暂时解压缩大部分目录，以便合并新的结果，然后再重新压缩。
监视全文索引
使用 System Monitor 以及 Performance Logs 和 Alerts 监视全文索引。
要监视的性能对象
有五个对象含有可监视的计数器，便于评估全文索引：
Microsoft Gatherer
Microsoft Gatherer Projects
Microsoft Search
Microsoft Search Catalogs
Microsoft Search Indexer Catalogs
在下一节中将讲述这些对象的有用的计数器。
与填充相关的计数器
在 Microsoft Gatherer 和 Microsoft Gatherer Projects 对象中使用下列计数器可以监视索引填充：
Microsoft Gatherer: Documents Filtered 已经筛选的文档的数目，或是已经编制索引的文档的数目。
Microsoft Gatherer: Performance Level 性能级别从 1 到 4 之间变化，由 Exchange System Manager 设置。（1 = 最低，2 =低，3 = 高，4 = 最高）
Microsoft Gatherer: System IO traffic rate 显示用于确定是否要减少爬行处理的 I/O 率。有关 I/O 诊断的详细信息，请参见物理磁盘计数器。
Microsoft Gatherer: Reason to back off 该计数器显示说明为何收集服务中止了填充的代码。
0 - 开始运行
1 - 高 IO 率
4 - 在用户活动时中止（默认情况下，在服务器安装时会禁用它）
5 - 电池电量低（如果当前是靠电池运行，而不靠 AC 电源）
6 - 内存不足（页面文件中所剩内存不足 5 MB）
Microsoft Gatherer Projects: Crawl in Progress Flag 该标志包含 0 或 1，表示是否运行爬行：0 = 运行爬行，1 = 不运行爬行。
Microsoft Gatherer Projects: Current Crawl is Incremental 该标志包含 0 或 1，表示爬行是否为增量爬行：0 = 增量爬行，1 = 完全爬行。
Microsoft Gatherer Projects: Gatherer Paused Flag 该标志包含 0 或 1，表示爬行是否为暂停爬行：0 = 非暂停爬行，1 = 暂停爬行。
Microsoft Gatherer Projects: URLs in History 该标志显示全文索引所知道的 URL（文件夹和文档）总数。
Microsoft Gatherer Projects: Waiting Documents 该标志显示等待爬行的文档总数。该数目在爬行开始时增加，因为在标识新的 URL，然后在爬行过程中减少。
Microsoft Search Indexer Catalogs: Merge Progress 该标志显示索引合并的完成百分比。
与查询相关的计数器
下面的 Microsoft Search Catalogs 计数器包含有关全文索引查询的信息。使用它们可以监视针对全文索引进行的查询。
Microsoft Search 对象包含 Microsoft Search Catalogs 对象中四个独立目录中值的总计。
Microsoft Search Catalogs: Queries 该计数器显示所执行的查询总数。
Microsoft Search Catalogs: Successful Queries 该计数器显示成功完成的查询数目。
Microsoft Search Catalogs: Results 该计数器显示所返回的经剪裁后符合查询范围的行数。
Microsoft Search Catalogs：Failed Queries 该计数器显示失败的查询数目（例如，包含干扰字的查询）。
与一般性能相关的计数器
使用下面计数器可以监视一般性能。
CPU 使用率
使用下面计数器可以监视 CPU 使用率。请记住，在完全填充期间，CPU 使用率通常会达到 100%。
Processor: % Processor Time 该计数器的范围为 0 到 100%。
Process: % Processor Time 该计数器的范围为 0 到 100 *N 个处理器 %。请从下列实例中进行选择：“store”是 Exchange Information Store 进程，“mssearch”是搜索进行，“mssdmn”是索引进程。
磁盘使用率
使用下面的计数器可以监视磁盘使用率。在运行全文索引时必须有足够的可用磁盘空间。如果磁盘空间不够，可能会导致严重问题。目录（索引）可能会损坏，并且可能发生其它系统问题。
Physical Disk: Current Disk Queue Length 这一数字在磁盘系统中不应超过每主轴 1 或 2 个。磁盘队列长度过长说明存在瓶颈。该计数通常应回零。极少回零或从不回零的磁盘队列长度也说明存在瓶颈。
Physical Disk:Avg. Disk sec./read 该计数器显示每次磁盘读取所花费的时间。这一时间值通常约为 10 毫秒。如果磁盘很忙，该值就会极高。
Physical Disk:Avg. Disk sec./write 该计数器显示每次磁盘写入所花费的时间。通常，该值大约为 10 毫秒；但带有回写缓存的 RAID 阵列大约有 1 毫秒的写时间，因为信息保留在控制器的缓存中。另外，当磁盘变忙时，这个数字也会变大。
Physical Disk: Disk Transfers/sec 该计数器显示每秒磁盘写入和读取次数总和。大多数单主轴都具有每秒 100 到 150 次传输的最大范围。
内存使用率
使用下面的计数器可以监视内存使用率：
Memory: Available Mbytes 该计数器列出计算机上的可用内存。
Process: Virtual Address Space 该计数器显示保留的内存（包括虚拟分配）。
Process: Private Bytes 该计数器显示专为该进程分配的总内存量；例如，数据库缓存。该计数器不包括句柄和共享内存。
Process: Working Set 该计数器显示 RAM 中实际分配的内存（等于 Task Manager 的 Memory Usage）。暂停全文索引爬行会导致它的工作集减少到大约 2 MB。
分页
使用下面的计数器可以监视分页：
Memory: Pages/sec 该计数器显示每秒硬分页（到磁盘）的数量。但是，可以在单个磁盘读/写中处理多个页。
Memory: Page Writes/sec 该计数器显示每秒用于分页的磁盘写入次数。
Memory: Page Reads/sec 该计数器显示每秒用于分页的磁盘读取次数。
Process: Page Faults/sec 该计数器显示每秒硬分页错误（到磁盘）和软分页错误（在内存中）。
如果 Pages/sec 计数器值较高（例如，超过 100），就要查看生成大多数分页错误的进程，因为很可能需要进行改正。如果它是信息存储，就要检查：
Database: Database Cache Size 该计数器显示数据库缓存的大小。若缓存小，会导致分页速度高，因为数据库的缓存会更频繁地交换回磁盘。
故障排除
收集器日志
收集器日志文件在填充期间生成。这些文件包含有关索引服务的日志信息。它们位于 /Exchsrvr/ExchangeServer/GatherLogs 目录下。扩展名为 .gthr。
如果无法对特定文档编制索引，无论原因如何，都会在收集器日志文件中加入一条记录。每条记录都列出文件名和错误号。若要对该错误号进行解码，请使用位于 /Program Files/Common Files/System/MSSearch/Bin 目录下的 Gthrlog.vbs 实用程序。该实用程序的语法如下：
cscript gthrlog.vbs <filename>
其中，filename 是 .gthr 文件的名称。请从命令提示符处使用 Gthrlog.vbs 实用程序。该实用程序产生的结果显示在命令提示符处。
混合语言的全文索引规则
在混合语言情况下，全文索引的规则很复杂。下列情况解释了各种语言设置如何影响索引行为。管理员使用这些指导原则确定用户报告的搜索问题产生的原因。
单个消息的语言设置
单个消息的语言设置会在下列几个方面影响索引行为：
如果消息是 MAPI 消息，它就具有区域 ID 属性，并且全文索引使用该值确定要使用哪个断字器。该属性值来自客户机上的 Office 语言设置。如果全文索引找不到与区域 ID 属性匹配的断字器，它就会使用 Neutral <0> 属性。
如果消息是用 Distributed Authoring and Versioning (DAV) 创建的，它就使用“Accept-Language”标题确定正确的区域。
如果消息未标识区域（通常是指来自 Internet 的消息），就使用服务器的“系统区域”。服务器是用来存储消息的 Exchange 2000 服务器，全文索引在其中执行。
附件的语言设置
附件的语言设置在下列几个方面影响索引行为：
如果附件是 Microsoft Office 文档，那么全文索引就使用用于生成该文档的语言设置。
运行 Microsoft Windows® 2000 的服务器的语言设置
服务器的语言设置在以下方面影响索引行为：
如果消息为非 MAPI 消息（即 Internet 消息），它的区域 ID 属性未设置，全文索引使用服务器的“系统区域”设置来确定使用哪个断字器。
客户机的语言设置
客户机的语言设置在以下方面影响索引行为：
在从 Outlook 发送查询时，也会发送客户机的区域 ID。如果消息的区域 ID 不与查询的区域 ID 匹配，搜索结果就不可预知。
注意 Exchange 服务器的语言在上一种情况下是无关的。客户机设置优先。
混合语言环境下的全文索引行为
下面的示例说明了具有各种语言设置的内容索引的查询行为。
全部美国语言设置
如果使用在美国客户机上运行的美国 Outlook，撰写消息并发送到在带有美国设置的 Windows 2000 服务器上运行的 Exchange 2000，就会发生下列情况：
全文索引使用美国断字器对消息编制索引。
如预期的那样处理来自美国客户机的查询。
希伯来文客户机、美国Office 设置、希伯来文 Windows 2000
如果使用希伯来文 Outlook，在 Office 设置为美国的希伯来文客户机上运行，撰写消息并将其发送到在“系统区域”设置为美国的服务器上运行的 Exchange 2000，就会发生下列情况：
全文索引使用美国断字器对消息编制索引。因为 Office 设置的缘故，消息的区域 ID 属性默认为美国。
来自希伯来文客户机的查询失败，原因是希伯来文文档没有应用正确的断字器。
日文客户机、日文 Office 设置、美国 Windows 2000
如果使用日文 Outlook，在 Office 设置为美国的日文客户机上运行，撰写消息并发送到在“系统区域”设置为美国的服务器上运行的 Exchange 2000，就会发生下列情况：
全文索引使用日文断字器对消息编制索引。
来自日文客户机的查询成功，原因是消息是用同样的区域 ID 编制索引和查询的。
初始化期间的查询
初始化期间，在启动具有全文索引的 Exchange 服务器的最初几分钟内，用户可以获得自己的邮件但得不到查询结果。这是因为搜索服务 MSSearch 正在加载索引，Exchange 正在加载属性存储。查询在这些过程完成后才返回结果。
缺失的性能计数器
与下列消息类似的事件消息表明由 System Monitor、Performance Logs 和 Alerts 使用的计数器缺失。如果接收到下列一条消息，就要通过重新启动 MSSearch 而恢复计数器。
Performance monitoring for the Gatherer service cannot be initialized because the counters are not loaded or the shared memory object cannot be opened. This only affects availability of the performance counters. Rebooting the system may fix the problem.
Performance monitoring cannot be initialized for the Gatherer object because the counters are not loaded or the shared memory object cannot be opened. This only affects availability of the performance counters. Rebooting the system may fix the problem.
Performance monitoring for the Indexer object cannot be initialized because the counters are not loaded or the shared memory object cannot be opened. Stop and restart the Search service. If this error continues, reinstall the application.
磁盘瓶颈
为避免磁盘瓶颈，请使用下列指导原则：
注意 有关详细信息，请参见前一节“要监视的性能对象”。
监视磁盘队列长度。
队列长度预期的平均值为 RAID 阵列中的主轴数略多。
长度应偶尔降为零。
队列应偶尔为空。如果队列总不为空，就说明有问题了。
每次磁盘写入和磁盘读取的平均时间应接近预期的等待时间。系统应花约 10 秒钟时间进行磁盘读/写。如果配置有硬盘缓存或 RAID 控制器，时间可能会更少。
内存瓶颈
高的分页速度可能表明存在内存瓶颈。请检查前面列出的性能计数器，并监视它们是否出现警告信号。特别要检查 Memory: Page writes/sec and Memory: Page reads/sec。
扫一扫
8275
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
