Over the years I can’t count the times that I’ve seen people reboot a SQL Server instance because there was some kind of problem. I can’t emphasize this enough: “In normal circumstances there is no valid reason to reboot SQL Server to solve an issue.”
I’ve had the task to investigate performance problems, login issues and other problems in SQL Server that suddenly appeared. The only problem was that the first action people took in that case is to reboot the database server.
If you reboot the SQL Server service (or the entire server) you create the following scenario in SQL Server
- Force a cold cache for data
- Force a cold cache for execution plans
- Collected statistics from DMV’s are no longer available
- Default trace is empty
Rebooting a server can, in some cases, solve an issue temporarily because in almost all the cases, this is just solving the symptoms of the issue instead of the issue at hand.
The situations where a reboot is needed are:
- when you install an update and it needs to a reboot to take effect.
- changing a setting in SQL Server is also a situation where a reboot is acceptable.
- the server is complete frozen en nobody can get in
But this is all why you shouldn’t do a reboot, but what should you do:
- Make sure you have baselines of the server to see if the performance issues are regular
- Find any processes from the baselines that decrease performance
- Do some profiling (with profiling I mean Extended Events not profiler)
- Check you SQL Server settings like
The examples above are just some of the actions you can do before rebooting a server. You should be able to find the problem with the above examples and work towards a solution.
Next time you reboot the SQL Server instance without doing the proper investigation imagine someone behind you holding a baseball bat ready to strike.