Full-Text Indexing Failures
While populating or maintaining a full-text index, the indexer, for reasons described below, might fail to index one or more rows. These row-level errors do not prevent the population from completing. The indexer skips these rows, which means that you are not able to query for content contained in these rows.
Indexing failures can occur when:
The indexer cannot find or load a filter or word breaker component. This failure can occur if the table row contains a document format or content in a language that has not been registered with the instance of SQL Server 2005. This failure can also happen if the registered word breaker or filter component was not signed or failed signature verification when it was being loaded.
A component, such as a word breaker or filter, fails and returns an error to the indexer. This can happen if the document being indexed is corrupt and the filter is unable to extract text from the document. This can also occur when a component is unable to handle the content of a single row above a certain size, due to memory limits on the Microsoft Full-Text Engine Filter Daemon (MSFTEFD).
For each row-level failure, the crawl log contains details on the reason for the failure. The error counts are summarized at the end of a full or incremental population.
There are other failures that can impact the indexing process itself and prevent the population from completing:
The full-text index exceeds the limit for the number of rows that can be contained in a full-text catalog.
A clustered index or full-text key index on the table being indexed gets altered, dropped, or rebuilt.
A hardware failure or disk corruption results in the corruption of the full-text catalog.
A file group that contains the table being full-text indexed goes offline, or is made read-only.
You should view the crawl log at the end of any significant full-text index population operation, or when you find that a population did not complete.
By default, the full-text indexer requires the filters and word breakers that it loads to be signed. If they are not signed, which is the case sometimes when custom components are installed, you must configure the full-text indexer to ignore signature verification.
|Ignoring signature verification makes the instance of SQL Server less secure. We recommend that you sign any components that you implement or ensure that any components that you acquire are signed. For information about signing components, see sp_fulltext_service (Transact-SQL).|
2,147,483,643 is the limit for the number of rows that can be in a single full-text catalog. When you exceed this limit, you receive an error message. To resolve this problem, first calculate the number of rows in each table associated with a given full-text catalog. Determine if this number exceeds the limit by a few, or many rows.
If the limit is exceeded by a small number, consider moving one or more indexes that are associated with the given full-text catalog to another catalog. Then run ALTER FULLTEXT CATALOG with the REORGANIZE option.
If the limit is exceeded by a large number, consider running ALTER FULLTEXT CATALOG with the REORGANIZE option first. Keep in mind that this is an expensive operation.
You might also consider deleting some items from the associated table.