Nick Hadlee's Blog on SharePoint and Other Occasional Rants…


When an Index Server Can’t Stop ‘Stopping’
May 27, 2009, 11:10 pm
Filed under: Administration, SharePoint, SQL, Troubleshooting

Due to some erratic behavior with a farms index server it was necessary to uninstall the indexing role and then re-provision it. The problem was during the uninstall the index service got stuck in a stopping state. A quick check in the error logs pointed to the SQL server. The SQL server logs were a little more descriptive with a 17310 event and even included the words ‘fatal’:

Event Type:    Error
Event Source:    MSSQLSERVER
Event Category:    (2)
Event ID:    17310
Date:        M/dd/yyyy
Time:        h:mm:ss yy
User:        N/A
Computer:    xxxx
Description: A user request from the session with SPID XXX generated a fatal exception. SQLServer is terminating this session. Contact Product Support Services with the dump produced in the log directory.

I have found when troubleshooting Google can either be a savior or a massive run-around, usually it depends on the reliability of the source and how good your searching skills are. In this situation what appeared to be a Chernobyl-esq problem had been encountered by a few people and ensuring that service pack 2 was installed on the SQL Server was the recommended fix. After applying the service pack the SQL logs were clear and the index service was able to be uninstalled and re-provisioned.

Unresolved Questions

The biggest question in the aftermath was why was a production SQL server not running the latest service packs? Surely someone has neglected their duties?

The infrastructure guy responsible for the SQL server has an interesting theory, especially if you like the implausible, the current blame for this issue was the installation of the SQL business intelligence studio onto the server which downgraded the SQL dll’s back to the RTM version. This will make a interesting test and would represent a massive bug if it was the case. Has anyone come across this or something similar before? It wouldn’t be the first software bug and it won’t be the last…

Advertisements

1 Comment so far
Leave a comment

Interesting article and the unresolved issue is a cracker. I suspect the problem is that SQL 2005 was installed, then SP2, then the BI software from the original RTM disks. I think the installer on the RTM disk didn’t check DLL versions greater than the version it was trying to install and so replaces the newer DLL’s from SP2 with the RTM version.

One solution is to slipstream SP2 into the installation files before installing new features.

Comment by Steve




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s



%d bloggers like this: