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
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
-
I have SQL Server 2000 on a MS Windows 2000 Advanced Server active/passive cluster. I rarely reboot my servers. They normally only get rebooted when I add software that requires it. About every 2-3 months I fail the SQL Server over to the backup node and then back to the primary node to make sure the failover works. But that doesn't require a reboot.
-SQLBill
-
I should have stated in my first post that I am openly opposed to rebooting my SQL Servers. I am just looking for more weight to my arguments. Thanks.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
-
Our SQL Server 7.0 and 2000 machines, all running 2000 Advanced Server, seldom need a reboot. However, on the 3rd Sunday of the odd numbered months, we schedule our major (or sometimes minor) system mantenance. That way our user community knows it's going to happen.
-
Tough one. I worked in placed where we rebooted monthly using scheduler. Occasionally especially on the older servers we'd have a hangup but OPS just went and hit the reset buttom (flaky IBM firmware to blame)
I've also been to a site where the server had been up over 2 years, talk about panic time when we had to reboot on a new software install and had nowhere to failover to. I guess I like the security of knowing that my server can cycle whenever I need it to without going to pieces. Of course over a month anything could happen and that next reboot might've been my last but at least I have a narrow window to determine why it fail.
I'm sure many will argue, just my take on it. Sounds like management made yet another flash bang decision without consulting with the folks that maintain equipment, welcome to the world of being a DBA.
John Zacharkan
John Zacharkan -
I used to reboot quarterly, apply patches, etc at that time.
However with W2K, it's not that much of an issue. We have been getting enough reboots lately with the patches from MS, but a quick glance at uptime for my servers shows:
---------- OUTPUT.TXT
System Up Time: 64 Days, 2 Hr, 56 Min, 51 Sec
System Up Time: 27 Days, 20 Hr, 15 Min, 10 Sec
System Up Time: 5 Days, 17 Hr, 27 Min, 27 Sec
System Up Time: 25 Days, 15 Hr, 35 Min, 25 Sec
System Up Time: 4 Days, 23 Hr, 30 Min, 22 Sec
System Up Time: 69 Days, 0 Hr, 2 Min, 16 Sec
System Up Time: 69 Days, 16 Hr, 59 Min, 6 Sec
System Up Time: 74 Days, 14 Hr, 10 Min, 51 Sec
System Up Time: 18 Days, 1 Hr, 4 Min, 22 Sec
System Up Time: 25 Days, 15 Hr, 36 Min, 7 Sec
System Up Time: 22 Days, 20 Hr, 0 Min, 46 Sec
System Up Time: 74 Days, 11 Hr, 4 Min, 9 Sec
System Up Time: 67 Days, 14 Hr, 35 Min, 17 Sec
System Up Time: 67 Days, 14 Hr, 42 Min, 12 Sec
System Up Time: 74 Days, 14 Hr, 10 Min, 57 Sec
System Up Time: 45 Days, 15 Hr, 41 Min, 52 Sec
System Up Time: 74 Days, 14 Hr, 11 Min, 28 Sec
System Up Time: 74 Days, 10 Hr, 30 Min, 51 Sec
System Up Time: 42 Days, 2 Hr, 40 Min, 2 Sec
System Up Time: 15 Days, 2 Hr, 10 Min, 34 Sec
System Up Time: 74 Days, 14 Hr, 11 Min, 59 Sec
System Up Time: 71 Days, 18 Hr, 39 Min, 31 Sec
System Up Time: 74 Days, 14 Hr, 11 Min, 55 Sec
System Up Time: 12 Days, 23 Hr, 53 Min, 10 Sec
System Up Time: 74 Days, 10 Hr, 54 Min, 51 Sec
System Up Time: 74 Days, 11 Hr, 33 Min, 51 Sec
System Up Time: 74 Days, 11 Hr, 25 Min, 18 Sec
System Up Time: 11 Days, 15 Hr, 33 Min, 5 Sec
System Up Time: 26 Days, 4 Hr, 8 Min, 35 Sec
System Up Time: 24 Days, 22 Hr, 13 Min, 44 Sec
System Up Time: 57 Days, 1 Hr, 18 Min, 52 Sec
System Up Time: 42 Days, 10 Hr, 38 Min, 24 Sec
System Up Time: 53 Days, 14 Hr, 17 Min, 25 Sec
System Up Time: 74 Days, 14 Hr, 12 Min, 31 Sec
System Up Time: 74 Days, 14 Hr, 12 Min, 35 Sec
System Up Time: 41 Days, 17 Hr, 18 Min, 5 Sec
In general, we reboot when we have to. Not any other time. Usually for some patch.
Steve Jones
-
We take a different approach. I reboot weekly. Every Friday night I have a 4 hour window when users know the SQL Servers won't be available. I know I am lucky to have such a window. I like it because it gets them into the routine knowing the systems won't be available and it gives me a standard time to update patches, service packs, perform standard maintenance on SQL databases.
In the past I did this because the developers would have orphaned jobs hanging or would manage to crash the system and it was just better to be proactive and restart them. But the Purchase Orders have been delivered to create a developer environment! so I hope my production can become more stable and I will see system uptimes like Steve!
FYI: SQL2k SP3, Win2kAdv. SP3 Quad-IBMx360 with 8GB RAM
Thanks,
Michelle
Michelle -
Depnding on the system and it's performance over a periodof time should call when a system is rebooted. In my last account the majority of systems were rebooted every week. This was needed to free up memory used by non-SQL Server apps. The longest that a SQL Server went unbounced up there was one month and I found that the system was more reliable than the SQL Servers that were bounced on a weekly basis (just from a hardware point of view).
As for my new account there are some SQL Server machines that haven't been bounced since last year, and I haven;t found a problem with servr performance.
This leads me to believe that one needs to look at each system and determin what is best for that system/location/site.
One thing to consder, especially when dealing with clusters, they are made to be up for long periods of time, I think if you keep bouncing the hardware you run the risk of hardware problems. At least that how it seemed at my last account.
Work like you don't need the money.
Love like you've never been hurt.
And Dance like no one is watching.
Work like you don't need the money.
Love like you've never been hurt.
And Dance like no one is watching. -
We're just about to start rebooting one of our production databases on a weekly basis. Our server hangs about once a week, for no apparent reason -- although I suspect that we're running into a memory issue caused by some application or utility that is "leaking" memory.
Like mimorr's situation, we're lucky enough to have a certain window of opportunity where the database being temporarily unavailable won't be much of a problem. (I say that now, but I'm sure that once we do schedule the reboots, regardless of the time of day that we schedule them for, we'll get negative feedback from our users.)
Just for reference, if you do decide to implement scheduled reboots, there's a utility included with the Windows 2000 Resource Kit called "shutdown.exe" which can be used in conjunction with the Task Scheduler to automate reboots.
-- Tim
-
In the past there has been reasons to set up a schedule reboot process for Windows/SQL machines due to the large amounts of memory leaks which came from some Microsoft apps - but most of those leaks are fixed. I agree with
sqltimd in theory that unless you see the problems of memory leaks, you should not do scheduled reboots. Scheduled reboots will clear the problem and you will never solve it, just cover it up. If you having problems trap for memory leaks and fix them rather than just setting a scheduled reboot process.
-
One of our primary production boxes hasn't been rebooted since 10-27-2002 (almost 8 months). It's also a replication publisher and distributor. I haven't seen any problems that I would blame on not rebooting. SQL 2000 seems very stable overall.
-Dan
-Dan -
I would agree. Windows 2000 has really made rebooting on a scheduled basis a thing of the past. We have about 20 servers running SQL Server 2000 on Win2K and some have been up since end of Jan, before that a couple of them had not been rebooted since April of '02.
-
We have been presented with a similar scenario with our management and have settled on a 60-day reboot schedule for our most busy SQL Server,and 90-days for all of the other (less critical) servers.
The schedule makes management "feel" better because of their historical apprehensiveness with Windows Server Operating systems (i.e. based upon antiquated familiarity with Windows 3.5.1 and application stability at that level). No matter how much evidence you present, some levels of management will not be convinced that the OS and its native applications are much more stable now than they were in the past. It is also a good idea to reboot every once in a while if you have questionable internally developed applications (i.e. once that have been known to leak memory or use resources haphazardly).
-
Guess Im with the crowd - we reboot when we need to, which is usually service pack application. I ALWAYS reboot after a service pack, whether it says to or not!
Andy
-
As an aside, if you've run on SS2K/ W2K for a year, you are missing some valuable security patches. Not that you have to apply them, look at your situation, but in a large company, with VPN, etc. there are lots of accesses that can bypass firewalls, so we try to be fairly up to date on patches.
All my servers were rebooted 74 days (75 now) ago for a W2K patch. Since then a few have had other reasons for reboot, but mostly patches, sometimes crappy programs.
Steve Jones
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply