SQLKitten

Everyone at one point or another has had this experience – you have to call technical support for assistance with your operating system or an application and get posed with the question “Have you tried restarting your computer?”

“Ummm…yeah. I did that. I also power-cycled my modem, searched the internet, hacked the registry and walked counter clockwise around my chair three times. I just thought I would call you to chat.”

Anyways…

Occasionally, the same logic is what is needed to resolve issues with SQL Server – restarting the SQL Server service. While we want to think that being on a fairly up-to-date version of SQL Server means things like this don’t happen, this is still software written by humans and every possible situation cannot be accounted for in testing. Sometimes you might find documentation that this is needed. Other times, the solution to the issue you are trying to solve is not as clear.

A couple of examples of a documented situation would be when updates to the server require a reboot or when a known issue in SQL Server is able to be immediately resolved by a restart of the service. Undocumented situations that can arise from different situations can range from changes to server settings that are not taking effect to changes in database mail. I have seen both of these situations in the past year – a server setting change was affecting replication (resolved by a restart) and database mail changes not taking effect, causing mail not to be sent and the mail queue to become backed up (another lesson learned here – after the restart of the service all those messages in the queue will be sent; if you don’t want this to happen the queue needs to be cleared out prior to restart).

Unlike rebooting a computer, restarting this service (or the server itself) is typically something that is done only where the circumstances dictate that it is required. Outside of this, restarting SQL Server is typically done as a last resort and is the last thing that the DBA might think to do. Depending on the server and the processes that communicate with the SQL Server instance, the business other resources may need to be not only notified of the restart, but also why it is needed in the first place. This is made more difficult by the fact that it may be unclear whether or not the restart will solve the problem at hand.

While it might not be documented that certain changes may require a service restart, that doesn’t mean that they don’t, and those situations can be difficult to identify. In these cases, all reasonable measures had been taken without yielding the desired results. Both cases involved changes to a SQL Server instance. Making the decision to restart in cases like this is not something that should be done flippantly, but where do you draw the line at time and effort spent before pulling the trigger? My experience with these issues will dictate how I handle similar cases going forward, but as for resolving issues that I have not had experience in dealing with yet, there very well may be more painful times…followed by sound of my head hitting the desk over and over out of frustration that the solution was something so simple.