Best Practices for Reboot Schedule | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Best Practices for Reboot Schedule

The management at my organization wants to implement a reboot policy for all servers on our network and I am trying to pull together information on recommended best practices. Has anyone come across a Microsoft document stating best practices for rebooting SQL Servers? Additionally, I would be interested in hearing others thoughts and current practices on reboot schedules for their SQL Servers. Thanks in advance.
David
I don’t think rebooting SQL Server is a great idea as long as you don’t see any memory leakage or any other performance issues. Gaurav
Check this: http://vyaskn.tripod.com/restart_sql_server_service.htm Bambola.
Funny, I posted this somewhere else and received the same response. I should have stated in my initial post that I am openly opposed to rebooting my SQL Servers unless there is a NEED. However, I am looking for more weight to my argument for management. Any help would be greatly appreciated. Thanks. David
Adding to the article that Bambola has referred, the best practice as far as SQL Server reboot us concerned would be to run thro’ the following steps- 1. Pause the SQL Server Service – This will refuse new connections to users.
2. Send message to all users of SQL Server to log off within 5 minutes using NET SEND command.
3. Wait for 5 minutes
4. Stop the service
5. Start the service.
6. And if you want to do some fancy stuff, store the host names of the users in a table before stopping the SQL Server and when the SQL Server starts, send them a mesaage that SQL Server is up and running using NET SEND. HTH. Gaurav
We never rebooted the system and only in case of major issues with memory drop on the boxes. (All our systems are 24/7 * 365’s) I agree with Gaurav’s comments and if you see any performance bottlenecks with memory on the server then rebooting server may give performance gain, provided any other applications also share memory alongwith SQL Server on the box. If its a dedicated then no need to go for reboot. Moreover if the management & business is agreed to have system outage then you can happily agree during less traffic hours. As of now did you see any performance bottleneck on that box? _________
Satya SKJ

We never reboot our servers, unless we have too because of a Service Pack. There is a myth that a lot of people believe in that Windows Servers must be rebooted often. This may have been true back in the 3.x days, but not any more. I have run servers for over a year without a reboot without any issues. Tell your management to keep up with the technology and stop living in the past. On a separate, issue, I have seen some poorly designed apps that have memory leaks that cause you to have to reboot a server, but SQL Server is not one of them. Obviously, this is on an app by app basis, and should not be done for all servers. —————————–
Brad M. McGehee, MVP
Webmaster
SQL-Server-Performance.Com
There can’t be anything else other than NEED for rebooting a SQL Server. This NEED, depending on your availability requirements, can be fueled by (and these will seem pretty obvious): (1) Application of Service Packs and/or security patches
(2) Worrying OS and SQL server performance statistics which can only be resolved by a reboot e.g. rogue applications and services affecting CPU, memory and disk utilization.
(3) Hardware changes (especially storage related)
(4) Network configuration changes e.g. Active Directory, Exchange Server settings, server name changes etc. Not all will require a reboot
(5) After repairing a suspect database NHO
Yes I agree, I also believe that a myth has developed during Windows 3.x days that u need to reboot your server often. I have said this before and I am again stressing, u don’t need to if you haven’t done any application changes as satya said. If you see any memory bottleneck and feel this can be memory leakage, I think you should go for application tuning rather than server reboot. Gaurav
This brings one question to my mind, What are the things which may grow over and need attention if I don’t reboot my SQL Server? I am having following assumptions here- 1. Transaction Log is backed up periodically.
2. Data growth rate is same as what would have been with frequent reboots. My points of attention would be- 1. SQL Server Error Log Size
2. TempDB space. Do these points need attention? I think sp_cycle_errorlog can take care of the first point and tempdb should not be a problem if my applications are not creating global tepmporary table. What are your thoughts on this? Gaurav
Agree on all counts and the "Tell your management to keep up with the technology and stop living in the past" comment brought a good laugh. I have no server problems and will not have any memory problems following some upgrades so, I am 100% with you all on all counts. NO REBOOT UNLESS NECESSARY. However, some Microsoft document or Trade Magazine article surrounding the issue will bring some weight to my argument. I do plan on sending all posts to this topic to management as part of my discussion as well so, I thank you all for the great comments. Thanks. David
Guys, I am repeating the questions that I asked so that it shows in your active topics list-
quote:Originally posted by gaurav_bindlish This brings one question to my mind, What are the things which may grow over and need attention if I don’t reboot my SQL Server? I am having following assumptions here- 1. Transaction Log is backed up periodically.
2. Data growth rate is same as what would have been with frequent reboots. My points of attention would be- 1. SQL Server Error Log Size
2. TempDB space. Do these points need attention? I think sp_cycle_errorlog can take care of the first point and tempdb should not be a problem if my applications are not creating global tepmporary table. What are your thoughts on this? Gaurav

Gaurav
As mentioned SP_CYCLE_ERRORLOG will take care size of error logs. I don’t think TEMPDB may cause an issue if you don’t reboot the box, if you are able to assess the queries and processes in hand you can set the values for growth of TEMPDB. _________
Satya SKJ

I am not aware of any good reasons to reboot SQL Server for its benefit. If you ever run into a problem with the tempdb being to big, you can shrink it, or stop and restart SQL Server. Rebooting is not needed. —————————–
Brad M. McGehee, MVP
Webmaster
SQL-Server-Performance.Com
]]>