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 (AT) nospam (DOT) net> wrote

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 (AT) nospam (DOT) net> wrote

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 (AT) autotask (DOT) com> wrote

See my response to Michael in this thread.

"Tom Moreau" <tom (AT) dont (DOT) spam.me.cips.ca> wrote

Neil (nospam (AT) nospam (DOT) 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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/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 (AT) nospam (DOT) net> wrote

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 (AT) autotask (DOT) com> wrote

"Neil" <nospam (AT) nospam (DOT) net> wrote

Yes. I disagree.

I've run systems with uptimes measured in years.

I see no value in rebooting a correctly setup system.

"Erland Sommarskog" <esquel (AT) sommarskog (DOT) se> wrote

Thanks, Erland. Once again, your response is thorough and informative.

"Tom Moreau" <tom (AT) dont (DOT) spam.me.cips.ca> wrote


Just as a general practice with Windows apps, that memory gets lost or
corrupted over time. Perhaps not with SQL Server. But there are other apps
running on it. PC Anywhere is installed as a host on that machine. I don't
know how much memory degradation, if any, occurs from that app. Occasionally
the machine is used to test the front end app (though it's not the primary
machine for that purpose).