Troubleshoot Full-Text Indexing
Troubleshoot Full-Text Indexing Failures
While populating or maintaining a full-text index, the full-text 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. 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 full-text filter daemon host (fdhost.exe).
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).
Full-Text Index in Inconsistent State after Transaction Log Restored
When restoring the transaction log of a database, you might see a warning indicating that the full-text index is not in a consistent state. The reason for this is that the full-text index on a table was modified after the database was backed up. To bring the full-text index to a consistent state, you must run a full population (crawl) on the table. For more information, see Populate Full-Text Indexes.