If you are getting a cannot connect to database error with SharePoint 2007 or indexing status remains in the Crawling state. The following might be the solution for you.
I was troubleshooting this issue and saw that my transaction logs were growing really fast and the server we were using didn't have much disk space allocated for the transaction logs. It was a 14 GB transaction log for a 9MB content database which is not an expected behaviour.
- After further investigation I saw that the log files were showing
CGathererQueueManager::FlushQueue failed with recoverable error 0×80040e2f CGathererFilterSink::CommitLinks : pGatherAddLink->AddLinkComplete error=0×80040e2f
and
SqlCrawl::ExecuteCommand fails Error 0×80040e2f
- We also saw that the number of handles that are opened by the MSSearch.exe process had increased which was using a good portion of the memory.
- And last but not least we saw that the number of TCP connections to the SQL Server had increased.
Now that we knew that the issue was a Search issue we looked into the search settings and found out that our Search service was hung up on Crawling full.
Tried stopping the search service using the following command from the command line but it wouldn't stop the service.
stsadm -o osearch -action stop
The Office SharePoint Server Search (osearch) service was stuck in Stopping mode but wouldn't stop.
Further looking into it we found an entry at Mike Hanley's blog that talked about how their Search service was stuck in the "Crawling Full" state. But I didn't like the fact that we had to recreate the indexes and recreate the SSP. So I looked further with the tips I found in Mike's entry and found this KB Article which explains how to fix the issue without creating indexes and a new SSP.
http://support.microsoft.com/kb/930887
After reading this article I found out that this was happening because the Database server that SharePoint 2007 was using was a SQL 2005 server which has maintenance plans that rebuilds indexes. This issue was occurring because the Rebuild index task did not restore all the options that were set on the indexes that are used by SharePoint Server 2007 after indexes are rebuilt. The Ignore duplicate values option is turned off after indexes are rebuilt.
(Taken from the KB article in my own words)
Here is the RESOLUTION
To resolve this issue, you need to disable the maintenance plan that contains the Rebuild Index task. Then, use SQL Server Management Studio to locate the indexes that are specified in the following table, as appropriate for your situation. For each index, make sure that the Ignore duplicate values check box is selected.
Go into your SQL management studio and change the following tables in your search database to have the Ignore duplicate values check box enabled
* (You may have to temporarily click The Unique check box on the General tab on the Index Properties page so that the Ignor Duplicate check box is not grayed out)
| Database |
Table name |
Index name |
| Search |
MSSAlertDocHistory |
IX_AlertDocHistory |
| Search |
MSSAnchorChangeLog |
IX_MSSAnchorChangeLog |
| Search |
MSSAnchorPendingChangeLog |
IX_MSSAnchorPendingChangeLog |
| Search |
MSSCrawlChangedSourceDocs |
IX_MSSCrawlChangedSourceDocs |
| Search |
MSSCrawlChangedTargetDocs |
IX_MSSCrawlChangedTargetDocs |
| Search |
MSSCrawledPropSamples |
IX_MSSCrawledPropSamplesByDocid |
| Search |
MSSCrawlErrorList |
IX_MSSCrawlErrorList_hrResult |
| Search |
MSSCrawlHostList |
IX_MSSCrawlHostList_Name |
| Search |
MSSCrawlQueue |
IX_MSSCrawlQueue |
| Search |
MSSDocSdids |
IX_MSSDocSdids |
Before you re-enable the maintenance plan, delete the Rebuild Index task or replace the Rebuild Index task with an Execute Transact-SQL Statement task. The Execute Transact-SQL Statement task should restore all options on indexes.
coskunc