Once a week or once a month

Running a SQL 7 system on a Windows 2000 server using Access 2000 on client
machines as a front end. System administrator currently reboots the server
once a month. Yesterday we had some weird thing with the database where
users were getting ODBC errors when trying to access it. Rebooted the
server, everything was fine. Suggested to the sa that he reboot the server
once a week. He said he already does it once a month, and that's sufficient.
My POV is that: a) doing it once a week might prevent situations such as the
one yesterday; b) even without situations like the one yesterday,
performance may be degrading over the course of the month, without our being
aware of it, and rebooting once a week might help performance.
Any thoughts on this?
Thanks!
Neil
Just because the reboot fixed the issue doesn't mean that a preventative
reboot will stop it from occuring.
A reboot might not have been needed to resolve the issue in the first place.
Possibly a configuration change
or bouncing a service could have resolved it. My advice is to spend some
time researching the issue and if
you cant find a way to resolve it then find a way to detect it and have it
perform the least intrusive form of corrective action.
-Mike
"Neil" <nospam@.nospam.net> wrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
> Running a SQL 7 system on a Windows 2000 server using Access 2000 on
> client machines as a front end. System administrator currently reboots the
> server once a month. Yesterday we had some weird thing with the database
> where users were getting ODBC errors when trying to access it. Rebooted
> the server, everything was fine. Suggested to the sa that he reboot the
> server once a week. He said he already does it once a month, and that's
> sufficient.
> My POV is that: a) doing it once a week might prevent situations such as
> the one yesterday; b) even without situations like the one yesterday,
> performance may be degrading over the course of the month, without our
> being aware of it, and rebooting once a week might help performance.
> Any thoughts on this?
> Thanks!
> Neil
>
|||Why does he reboot at all?
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Neil" <nospam@.nospam.net> wrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
Running a SQL 7 system on a Windows 2000 server using Access 2000 on client
machines as a front end. System administrator currently reboots the server
once a month. Yesterday we had some weird thing with the database where
users were getting ODBC errors when trying to access it. Rebooted the
server, everything was fine. Suggested to the sa that he reboot the server
once a week. He said he already does it once a month, and that's sufficient.
My POV is that: a) doing it once a week might prevent situations such as the
one yesterday; b) even without situations like the one yesterday,
performance may be degrading over the course of the month, without our being
aware of it, and rebooting once a week might help performance.
Any thoughts on this?
Thanks!
Neil
|||OK, that's fine. But my POV is that rebooting in general, and resetting the
system memory, is a good thing to do. I take it that you disagree?
"Michael Abair" <mabair@.autotask.com> wrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
> Just because the reboot fixed the issue doesn't mean that a preventative
> reboot will stop it from occuring.
> A reboot might not have been needed to resolve the issue in the first
> place. Possibly a configuration change
> or bouncing a service could have resolved it. My advice is to spend some
> time researching the issue and if
> you cant find a way to resolve it then find a way to detect it and have it
> perform the least intrusive form of corrective action.
> -Mike
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
>
|||See my response to Michael in this thread.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23LFLkcEOIHA.4196@.TK2MSFTNGP04.phx.gbl...
> Why does he reboot at all?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
> Running a SQL 7 system on a Windows 2000 server using Access 2000 on
> client
> machines as a front end. System administrator currently reboots the server
> once a month. Yesterday we had some weird thing with the database where
> users were getting ODBC errors when trying to access it. Rebooted the
> server, everything was fine. Suggested to the sa that he reboot the server
> once a week. He said he already does it once a month, and that's
> sufficient.
> My POV is that: a) doing it once a week might prevent situations such as
> the
> one yesterday; b) even without situations like the one yesterday,
> performance may be degrading over the course of the month, without our
> being
> aware of it, and rebooting once a week might help performance.
> Any thoughts on this?
> Thanks!
> Neil
>
|||Neil (nospam@.nospam.net) writes:
> OK, that's fine. But my POV is that rebooting in general, and resetting
> the system memory, is a good thing to do. I take it that you disagree?
I do. Unless there is some known issues, there is rarely any reason to
reboot SQL Server regularly. OK, so you have SQL 7, and this version is a
bit old. Nevertheless, it has the same basic architecture as subsequent
SQL Server versions. The predecessors 6.x were less stable. (In 6.0 there
was a bug that compelled you to restart the bug about every 48th day.
There was some counter somewhere that wrapped around after 49 days.)
As for rebooting helping performance, it may be the other way round.
When you reboot, the entire plan cache will be thrown away, and until
the plan has built up, the server will spend more time compiling. But
that's the only thing. Say that you have a table with date column,
into which the current date is typically inserted, and queries against
this table are typically for the recent days. If the query is a stored
procedure or is parameterised, the plan will be built using that date.
But if statistics are out of date, the estimates will be wrong, and you
may get a bad plan. Had you never restarted the server, the old good
plan would have remained in cache.
But, OK, the reverse can happen: the old plan was bad, but statistics
have been updated recently, so now you get a good plan.
As for your problem the other day, you did not include any error message,
but I would guess that it was a temporary network problem, and it would
have gone away even if you had not restarted SQL Server.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||Why does the system memory need to be reset? I've seen SQL Servers stay up
for months and not need a reboot. That's what High Availability is all
about.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Neil" <nospam@.nospam.net> wrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...
OK, that's fine. But my POV is that rebooting in general, and resetting the
system memory, is a good thing to do. I take it that you disagree?
"Michael Abair" <mabair@.autotask.com> wrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
> Just because the reboot fixed the issue doesn't mean that a preventative
> reboot will stop it from occuring.
> A reboot might not have been needed to resolve the issue in the first
> place. Possibly a configuration change
> or bouncing a service could have resolved it. My advice is to spend some
> time researching the issue and if
> you cant find a way to resolve it then find a way to detect it and have it
> perform the least intrusive form of corrective action.
> -Mike
> "Neil" <nospam@.nospam.net> wrote in message
> news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...
>
|||"Neil" <nospam@.nospam.net> wrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...
> OK, that's fine. But my POV is that rebooting in general, and resetting
> the system memory, is a good thing to do. I take it that you disagree?
>
Yes. I disagree.
I've run systems with uptimes measured in years.
I see no value in rebooting a correctly setup system.

> "Michael Abair" <mabair@.autotask.com> wrote in message
> news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...
>
|||"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns99FEEDF6C864Yazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
> I do. Unless there is some known issues, there is rarely any reason to
> reboot SQL Server regularly. OK, so you have SQL 7, and this version is a
> bit old. Nevertheless, it has the same basic architecture as subsequent
> SQL Server versions. The predecessors 6.x were less stable. (In 6.0 there
> was a bug that compelled you to restart the bug about every 48th day.
> There was some counter somewhere that wrapped around after 49 days.)
> As for rebooting helping performance, it may be the other way round.
> When you reboot, the entire plan cache will be thrown away, and until
> the plan has built up, the server will spend more time compiling. But
> that's the only thing. Say that you have a table with date column,
> into which the current date is typically inserted, and queries against
> this table are typically for the recent days. If the query is a stored
> procedure or is parameterised, the plan will be built using that date.
> But if statistics are out of date, the estimates will be wrong, and you
> may get a bad plan. Had you never restarted the server, the old good
> plan would have remained in cache.
> But, OK, the reverse can happen: the old plan was bad, but statistics
> have been updated recently, so now you get a good plan.
> As for your problem the other day, you did not include any error message,
> but I would guess that it was a temporary network problem, and it would
> have gone away even if you had not restarted SQL Server.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Thanks, Erland. Once again, your response is thorough and informative.
|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:13lguvsc3jaql29@.corp.supernews.com...[vbcol=seagreen]
> "Neil" <nospam@.nospam.net> wrote in message
> news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...
> Yes. I disagree.
> I've run systems with uptimes measured in years.
> I see no value in rebooting a correctly setup system.
>
Thanks.