old sql2k5 folder: system

Showing posts with label system. Show all posts

Friday, March 30, 2012

One minute SQL Server 7 date time synchronization

Hello,
How to force SQL Server 7 synchronize its date&time from the system ?
It looks like it is polling once a minute.
Thanks,
Ivan
That's the way that SQL Server work. In SQL2K, SQL Server doesn't keep it's own counter anymore (AFAIK).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405040706.30ff025b@.posting.google.c om...
> Hello,
> How to force SQL Server 7 synchronize its date&time from the system ?
> It looks like it is polling once a minute.
> Thanks,
> Ivan
|||There is no way for triggering a synchronization event in the SQL
Server 7?
In our system, after receiving date & time data from the host and
setting it on the NT box through SetLocalTime Win32API, some stored
procedures are triggered for calculating expiration dates upon the
current (SQL Server) date & time.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message news:<OZKZpqfMEHA.3012@.tk2msftngp13.phx.gbl>...[vbcol=seagreen]
> That's the way that SQL Server work. In SQL2K, SQL Server doesn't keep it's own counter anymore (AFAIK).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405040706.30ff025b@.posting.google.c om...
|||> There is no way for triggering a synchronization event in the SQL
> Server 7?
Not AFAIK...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405041325.2cea1da3@.posting.google.c om...
> There is no way for triggering a synchronization event in the SQL
> Server 7?
> In our system, after receiving date & time data from the host and
> setting it on the NT box through SetLocalTime Win32API, some stored
> procedures are triggered for calculating expiration dates upon the
> current (SQL Server) date & time.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
news:<OZKZpqfMEHA.3012@.tk2msftngp13.phx.gbl>...[vbcol=seagreen]

One minute SQL Server 7 date time synchronization

Hello,
How to force SQL Server 7 synchronize its date&time from the system ?
It looks like it is polling once a minute.
Thanks,
IvanThat's the way that SQL Server work. In SQL2K, SQL Server doesn't keep it's
own counter anymore (AFAIK).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405040706.30ff025b@.posting
.google.com...
> Hello,
> How to force SQL Server 7 synchronize its date&time from the system ?
> It looks like it is polling once a minute.
> Thanks,
> Ivan|||There is no way for triggering a synchronization event in the SQL
Server 7?
In our system, after receiving date & time data from the host and
setting it on the NT box through SetLocalTime Win32API, some stored
procedures are triggered for calculating expiration dates upon the
current (SQL Server) date & time.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message news:<OZ
KZpqfMEHA.3012@.tk2msftngp13.phx.gbl>...[vbcol=seagreen]
> That's the way that SQL Server work. In SQL2K, SQL Server doesn't keep it'
s own counter anymore (AFAIK).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.040504070
6.30ff025b@.posting.google.com...|||> There is no way for triggering a synchronization event in the SQL
> Server 7?
Not AFAIK...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405041325.2cea1da3@.posting
.google.com...
> There is no way for triggering a synchronization event in the SQL
> Server 7?
> In our system, after receiving date & time data from the host and
> setting it on the NT box through SetLocalTime Win32API, some stored
> procedures are triggered for calculating expiration dates upon the
> current (SQL Server) date & time.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in messag
e
news:<OZKZpqfMEHA.3012@.tk2msftngp13.phx.gbl>...[vbcol=seagreen]sql

One minute SQL Server 7 date time synchronization

Hello,
How to force SQL Server 7 synchronize its date&time from the system ?
It looks like it is polling once a minute.
Thanks,
IvanThat's the way that SQL Server work. In SQL2K, SQL Server doesn't keep it's own counter anymore (AFAIK).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405040706.30ff025b@.posting.google.com...
> Hello,
> How to force SQL Server 7 synchronize its date&time from the system ?
> It looks like it is polling once a minute.
> Thanks,
> Ivan|||There is no way for triggering a synchronization event in the SQL
Server 7?
In our system, after receiving date & time data from the host and
setting it on the NT box through SetLocalTime Win32API, some stored
procedures are triggered for calculating expiration dates upon the
current (SQL Server) date & time.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message news:<OZKZpqfMEHA.3012@.tk2msftngp13.phx.gbl>...
> That's the way that SQL Server work. In SQL2K, SQL Server doesn't keep it's own counter anymore (AFAIK).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405040706.30ff025b@.posting.google.com...
> > Hello,
> >
> > How to force SQL Server 7 synchronize its date&time from the system ?
> > It looks like it is polling once a minute.
> >
> > Thanks,
> > Ivan|||> There is no way for triggering a synchronization event in the SQL
> Server 7?
Not AFAIK...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405041325.2cea1da3@.posting.google.com...
> There is no way for triggering a synchronization event in the SQL
> Server 7?
> In our system, after receiving date & time data from the host and
> setting it on the NT box through SetLocalTime Win32API, some stored
> procedures are triggered for calculating expiration dates upon the
> current (SQL Server) date & time.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
news:<OZKZpqfMEHA.3012@.tk2msftngp13.phx.gbl>...
> > That's the way that SQL Server work. In SQL2K, SQL Server doesn't keep it's own counter anymore (AFAIK).
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> >
> >
> > "Ivan Rubin" <ivan.rubin@.gmx.net> wrote in message news:1bc4e8d1.0405040706.30ff025b@.posting.google.com...
> > > Hello,
> > >
> > > How to force SQL Server 7 synchronize its date&time from the system ?
> > > It looks like it is polling once a minute.
> > >
> > > Thanks,
> > > Ivan

Wednesday, March 28, 2012

One Database vs. Multiple Databases

I need to design a system which represents multiple "projects" in SQL
Server. Each project has the same data model, but is independent of all
others. My inclination is to use one database to store all projects.
Looking at the numbers involved, however, I wonder if I would get
better performance by storing each project in its own database.

Suppose I have 50 projects, each with two users and 10,000 rows; it
seems to me I'd rather have 50 x 2 users working in a table with 10,000
rows than 1 x 100 users working in a table with 500,000 rows.

On the other hand, the single database approach seems more elegant from
a design perspective. I wouldn't be creating multiple copies of an
identical data model, and I wouldn't be creating new databases as a
business procedure, every time a new project is required.

Here are my questions:
1. For the scenario described above, am I correct to assume I will get
better performance by using multiple databases, or does SQL Server have
some clever way of achieving the same performance in a single database?
2. Is the multiple database approach common? If anyone has tried it,
please tell me about how it works in practice.

-TCTC wrote:
> I need to design a system which represents multiple "projects" in SQL
> Server. Each project has the same data model, but is independent of all
> others. My inclination is to use one database to store all projects.
> Looking at the numbers involved, however, I wonder if I would get
> better performance by storing each project in its own database.
> Suppose I have 50 projects, each with two users and 10,000 rows; it
> seems to me I'd rather have 50 x 2 users working in a table with 10,000
> rows than 1 x 100 users working in a table with 500,000 rows.
> On the other hand, the single database approach seems more elegant from
> a design perspective. I wouldn't be creating multiple copies of an
> identical data model, and I wouldn't be creating new databases as a
> business procedure, every time a new project is required.
> Here are my questions:
> 1. For the scenario described above, am I correct to assume I will get
> better performance by using multiple databases, or does SQL Server have
> some clever way of achieving the same performance in a single database?
> 2. Is the multiple database approach common? If anyone has tried it,
> please tell me about how it works in practice.
>
> -TC

1. Not unless your implementation is very bad indeed. 100 users and
500,000 rows is a small database by most standards.

2. Sometimes. Partitioning a database can make sense for administrative
and support reasons or as part of a solution where data is distributed
over multiple servers. But without other changes, partitioning a
database isn't likely to achieve much if anything in terms of
performance. Given the potential complexity of supporting that kind of
solution there are certainly much easier and more effective ways to
optimise performance.

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/...US,SQL.90).aspx
--|||TC wrote:
> I need to design a system which represents multiple "projects" in SQL
> Server. Each project has the same data model, but is independent of all
> others. My inclination is to use one database to store all projects.
> Looking at the numbers involved, however, I wonder if I would get
> better performance by storing each project in its own database.
> Suppose I have 50 projects, each with two users and 10,000 rows; it
> seems to me I'd rather have 50 x 2 users working in a table with 10,000
> rows than 1 x 100 users working in a table with 500,000 rows.
> On the other hand, the single database approach seems more elegant from
> a design perspective. I wouldn't be creating multiple copies of an
> identical data model, and I wouldn't be creating new databases as a
> business procedure, every time a new project is required.
> Here are my questions:
> 1. For the scenario described above, am I correct to assume I will get
> better performance by using multiple databases, or does SQL Server have
> some clever way of achieving the same performance in a single database?
> 2. Is the multiple database approach common? If anyone has tried it,
> please tell me about how it works in practice.
>
> -TC

I would go with 1 database per projet (so multiple databases):
- if your data model change, you will be able to migrate only projets
that you want, when you want.
- easier to separate projet, restart a projet, etc if you need.
- backup/restaure projet independantly
- Give acces to a particular projet to a user is easier.|||I would go the other way - one database for all. It will more scalable
and flexible. The amount of data is not too much, the speed is not an
issue as long as it is properly indexed.

I actually did a data conversion merging several hundreds of databases
(Also called project) into one.|||TC (golemdanube@.yahoo.com) writes:
> I need to design a system which represents multiple "projects" in SQL
> Server. Each project has the same data model, but is independent of all
> others. My inclination is to use one database to store all projects.
> Looking at the numbers involved, however, I wonder if I would get
> better performance by storing each project in its own database.
> Suppose I have 50 projects, each with two users and 10,000 rows; it
> seems to me I'd rather have 50 x 2 users working in a table with 10,000
> rows than 1 x 100 users working in a table with 500,000 rows.
> On the other hand, the single database approach seems more elegant from
> a design perspective. I wouldn't be creating multiple copies of an
> identical data model, and I wouldn't be creating new databases as a
> business procedure, every time a new project is required.
> Here are my questions:
> 1. For the scenario described above, am I correct to assume I will get
> better performance by using multiple databases, or does SQL Server have
> some clever way of achieving the same performance in a single database?
> 2. Is the multiple database approach common? If anyone has tried it,
> please tell me about how it works in practice.

Whether to use one or many databases has nothing to do with performance
whatsoever. If performance is the only motive for you to consider
separate databases, just forget about it given the volumes you indicated.

There may be other reasons for using separate databases. One project
says "oops, we deleted our data". With a separate database, a restore
is a quick thing. Or some projects may start to call for diverging
requirements, so that they no longer fit into the same model. There
can also be security considerations.

But all of that business requirements that are unknown to me. Since
maintaining 50 databases with the same model requires more overhead,
a single database with a good data model is a good way to start.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||"TC" <golemdanube@.yahoo.com> wrote in message
news:1150833955.445569.42840@.h76g2000cwa.googlegro ups.com...
> I need to design a system which represents multiple "projects" in SQL
> Server. Each project has the same data model, but is independent of all
> others. My inclination is to use one database to store all projects.
> Looking at the numbers involved, however, I wonder if I would get
> better performance by storing each project in its own database.
> Suppose I have 50 projects, each with two users and 10,000 rows; it
> seems to me I'd rather have 50 x 2 users working in a table with 10,000
> rows than 1 x 100 users working in a table with 500,000 rows.

This is a small database by today's standards.

In general a single database will probably give you better performance since
only one copy of query plans will be cached, as opposed to 50 (assuming you
use stored procs, etc.).

disk I/O will probably be less as SQL can do a better job of reading in
batches of rows.

So performance-wise, single probably wins out.

In terms of maintenance, etc, a single one is generally better. Assume you
develop an updated version of a stored proc, or need to change a table.
Would you rather do it once or 50 times?

> On the other hand, the single database approach seems more elegant from
> a design perspective. I wouldn't be creating multiple copies of an
> identical data model, and I wouldn't be creating new databases as a
> business procedure, every time a new project is required.
> Here are my questions:
> 1. For the scenario described above, am I correct to assume I will get
> better performance by using multiple databases, or does SQL Server have
> some clever way of achieving the same performance in a single database?
> 2. Is the multiple database approach common? If anyone has tried it,
> please tell me about how it works in practice.
>
> -TC|||TC wrote:
> I need to design a system which represents multiple "projects" in SQL
> Server. Each project has the same data model, but is independent of all
> others.

Others have addressed, both pro and con using a single or multiple
databases and my response would be that the consideration is one
of maintenance and security: Two issues you have not discussed.

But what I would like to add to this discussion is based on your
first two sentences.

From what you've written I can't see how you can justify, except
for security purposes, more than one set of tables with the same
data model. I think Date and Codd said something about it so you
might want to read what they wrote. But based solely on the above
sentences ... the correct solution is to add a column to your
tables named PROJECT_ID.
--
Daniel A. Morgan
University of Washington
damorgan@.x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org|||As everybody has mentioned, 500k records and 100 users is small by any
definition. But regardless, performance should not be a consideration
until it forces itself to become so.

Think about your idea from a maintenance perspective. At some point
you'll need to add a column to one of those tables, or even make a
simple stored procedure change. Imagine the pain this will cause you
down the road, trying to synchronize changes in all those databases.
Multiply every small hassle you'll ever come across in the future by
the number of "Projects" in your universe. Yikes!

Stick to one database per Application and you'll live a long and
healthy life.

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

--
Get your own Travel Blog, with itinerary maps and photos!
http://www.blogabond.com/|||I recently recommended a multiple database solution, since my
assessment of the client's needs and data were that they needed the
flexibility of separate databases per data set. Also, my deadline for
completion was very short, and this product was not considered to be
used for longer than the near future.

Each external client's (about 20 clients) data set is different - even
the same client data set could vary - and the process was to massage
each set of data via stored procedures. I Initially opted for one
database per client, to allow for reuse of lookup data (holidays,
fiscal periods, accounts, etc.), but later realized that what I was
designing, an Excel workbook to analyze accounting data, would be
easier to modify if I kept everything the same and simply modified the
connection string.

Ultimately, the choice of multiple servers keeps the stored procs for
the XLW, and the XLW itself, the same, while the only modification
occurs in the stored procedures for building the data, since the data
requirements could vary wildly. The multiple database approach also
allows for multiple data sets to be massaged at the same time -
building the final data set could take several days, so some problems
in concurrency could develop - and with varying procedures for such the
independence was a benefit, albeit creating a lot of redundancy.

Given enough time to design a solution that preserved security - no
client specific information, nor information useful for hacking the
server data could be local, other than the connection string - and ran
as a single database, I could certainly design a solution for them.

James Igoe

james.igoe@.gmail.com || http://code.comparative-advantage.com

Jason Kester wrote:
> As everybody has mentioned, 500k records and 100 users is small by any
> definition. But regardless, performance should not be a consideration
> until it forces itself to become so.
> Think about your idea from a maintenance perspective. At some point
> you'll need to add a column to one of those tables, or even make a
> simple stored procedure change. Imagine the pain this will cause you
> down the road, trying to synchronize changes in all those databases.
> Multiply every small hassle you'll ever come across in the future by
> the number of "Projects" in your universe. Yikes!
> Stick to one database per Application and you'll live a long and
> healthy life.
> Jason Kester
> Expat Software Consulting Services
> http://www.expatsoftware.com/
> --
> Get your own Travel Blog, with itinerary maps and photos!
> http://www.blogabond.com/|||I want to thank everyone for their thoughtful responses. You've helped
me get perspective on this issue.

-TC

Monday, March 26, 2012

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.

Once a week or once a month

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!

NeilJust 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.netwrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

|||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.netwrote 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.

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.comwrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

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.netwrote in message
news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

>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
>>

>
>

|||See my response to Michael in this thread.

"Tom Moreau" <tom@.dont.spam.me.cips.cawrote in message
news:%23LFLkcEOIHA.4196@.TK2MSFTNGP04.phx.gbl...

Quote:

Originally Posted by

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.netwrote 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:

Quote:

Originally Posted by

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/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/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

"Michael Abair" <mabair@.autotask.comwrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

Quote:

Originally Posted by

>
>

|||"Neil" <nospam@.nospam.netwrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...

Quote:

Originally Posted by

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.

Quote:

Originally Posted by

"Michael Abair" <mabair@.autotask.comwrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

>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.netwrote in message
>news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

>>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
>>>

>>
>>

>
>

|||"Erland Sommarskog" <esquel@.sommarskog.sewrote in message
news:Xns99FEEDF6C864Yazorman@.127.0.0.1...

Quote:

Originally Posted by

Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

>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/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Thanks, Erland. Once again, your response is thorough and informative.|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13lguvsc3jaql29@.corp.supernews.com...

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.ne t...

Quote:

Originally Posted by

>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.
>
>

Quote:

Originally Posted by

>"Michael Abair" <mabair@.autotask.comwrote in message
>news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

>>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.netwrote 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
>>
>>>
>>>

Thanks.|||

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote 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.comwrote in message
news:eTxBHcEOIHA.2064@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

>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.netwrote in message
>news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

"Tom Moreau" <tom@.dont.spam.me.cips.cawrote in message
news:uuaNHcFOIHA.4948@.TK2MSFTNGP02.phx.gbl...

Quote:

Originally Posted by

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
>
>

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).|||If memory is truly getting lost or corrupted, then I'd troubleshoot the
specific problem.

--
Tom

Quote:

Originally Posted by

Quote:

Originally Posted by

>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.netwrote in message
>news:5CY5j.76025$YL5.36846@.newssvr29.news.prodigy. net...

Quote:

Originally Posted by

"Tom Moreau" <tom@.dont.spam.me.cips.cawrote in message
news:uuaNHcFOIHA.4948@.TK2MSFTNGP02.phx.gbl...

Quote:

Originally Posted by

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).|||"Neil" <nospam@.nospam.netwrote in message
news:s2f6j.23284$4V6.14684@.newssvr14.news.prodigy. net...

Quote:

Originally Posted by

>
>
>
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.

Unless there's a specific need for PCAnywhere, I'd get rid of it and
administer the machine via remote desktop.

Works much better.

Quote:

Originally Posted by

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).

Well in that csae you've got other issues with the machine.

Which if it's a purely dev machine or one where shutdowns don't impact the
business, you may be ok.

The prod environments I work in tend to be 24/7 so shutdowns are very
infrequent.

Also if you're doing a soft-reboot, that's a bit "nicer" to the hardware
than a hard-reboot which can shorten the lifespan of components.

Quote:

Originally Posted by

>
>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13lj8p2grq8eab@.corp.supernews.com...

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:s2f6j.23284$4V6.14684@.newssvr14.news.prodigy. net...

Quote:

Originally Posted by

>>
>>
>>
>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.

>
Unless there's a specific need for PCAnywhere, I'd get rid of it and
administer the machine via remote desktop.
>
Works much better.
>
>

Quote:

Originally Posted by

>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).

>
Well in that csae you've got other issues with the machine.
>
Which if it's a purely dev machine or one where shutdowns don't impact the
business, you may be ok.
>
The prod environments I work in tend to be 24/7 so shutdowns are very
infrequent.
>
Also if you're doing a soft-reboot, that's a bit "nicer" to the hardware
than a hard-reboot which can shorten the lifespan of components.
>
>

Quote:

Originally Posted by

>>
>>

>
>
>
--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com
http://www.greenms.com/sqlserver.html
>
>

One problem with remote desktop is that you can't transfer files or transfer
the clipboard contents (or can you?). I use those two functions all the
time.|||Neil wrote:

Quote:

Originally Posted by

One problem with remote desktop is that you can't transfer files or transfer
the clipboard contents (or can you?). I use those two functions all the
time.

The clipboard contents are auto-copied whenever they change on either
side. I don't think you can transfer files, but you can work around
that with an FTP server.|||Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

One problem with remote desktop is that you can't transfer files or
transfer the clipboard contents (or can you?). I use those two functions
all the time.

You can. You can configure this under Local Resources. I think clipboard
is shared by default, so if you put something on the clipboard on the
remote machine, it makes it to the local machine automatically.

The way to transfer files, is a little funny, though. You make the local
drives available to the remote machine, so that they appear as shared
there. Since this is a security issue, it's not recommendable to always
expose your disks.

We don't use PC Anywhere in our shop, but we use PC Duo which is a
similar product. About all customers has PC Duo clients on their
servers, and that's how we connect to them. The major advantage is
that with Remote Desktop, is that if someone else connect, you may lose
your session. With PC-Duo you can see that someone else is there.
And moving files is easier with PC-Duo than Remote Desktop.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||"Erland Sommarskog" <esquel@.sommarskog.sewrote in message
news:Xns99FFEF5871026Yazorman@.127.0.0.1...

Quote:

Originally Posted by

Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

>One problem with remote desktop is that you can't transfer files or
>transfer the clipboard contents (or can you?). I use those two functions
>all the time.

>
You can. You can configure this under Local Resources. I think clipboard
is shared by default, so if you put something on the clipboard on the
remote machine, it makes it to the local machine automatically.
>
The way to transfer files, is a little funny, though. You make the local
drives available to the remote machine, so that they appear as shared
there. Since this is a security issue, it's not recommendable to always
expose your disks.
>
We don't use PC Anywhere in our shop, but we use PC Duo which is a
similar product. About all customers has PC Duo clients on their
servers, and that's how we connect to them. The major advantage is
that with Remote Desktop, is that if someone else connect, you may lose
your session. With PC-Duo you can see that someone else is there.
And moving files is easier with PC-Duo than Remote Desktop.
>
>

So you'd recommend PC Duo over Remote Desktop? Is the performance as good?|||"Neil" <nospam@.nospam.netwrote in message
news:q5i6j.4985$fl7.132@.newssvr22.news.prodigy.net ...

Quote:

Originally Posted by

Quote:

Originally Posted by

>
>
One problem with remote desktop is that you can't transfer files or
transfer the clipboard contents (or can you?). I use those two functions
all the time.

You can transfer the clipboard settings in Win2K.

(Though I think you need Server 2003 for the file transfer function (it maps
the drives from your client to the server. I use that a lot.)

Quote:

Originally Posted by

>
>
>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Neil (nospam@.nospam.net) writes:

Quote:

Originally Posted by

So you'd recommend PC Duo over Remote Desktop? Is the performance as good?

It depends on the purpose. When I want to connect to machine at work,
I definitely prefer Remote Desktop over PC-Duo. At least in the past I
have had issue with PC-Duo redrawing the screen like crazy, or it has
stopped redrawing. A crazy one I remember was that if I connect to my
machine with PC-Duo, and I had Query Analyzer up with a query grid, it
would halt somewhere. I was able to get it to resume if I minimiezed QA.
Now, since PC-Duo had not drawn the entire screen, I had to find the
minimize button as if I was blind-folded. Even more fun, if other windows
were on top of QA. But I should stress that this was quite a few years
and versions of PC-Duo ago.

So for performance and access to a workstation I prefer Remote Desktop.

But if several people need to access the same server console, I think
PC Duo is better. It's also better if you need to move files in any
direction.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13lla9gfb13pp76@.corp.supernews.com...

Quote:

Originally Posted by

>
"Neil" <nospam@.nospam.netwrote in message
news:q5i6j.4985$fl7.132@.newssvr22.news.prodigy.net ...

Quote:

Originally Posted by

Quote:

Originally Posted by

>>>

>>
>>
>One problem with remote desktop is that you can't transfer files or
>transfer the clipboard contents (or can you?). I use those two functions
>all the time.

>
You can transfer the clipboard settings in Win2K.
>

"Can" transfer, or they're transferred automatically?|||"Neil" <nospam@.nospam.netwrote in message
news:RPP6j.5129$fl7.785@.newssvr22.news.prodigy.net ...

Quote:

Originally Posted by

>
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in
message news:13lla9gfb13pp76@.corp.supernews.com...

Quote:

Originally Posted by

>>
>"Neil" <nospam@.nospam.netwrote in message
>news:q5i6j.4985$fl7.132@.newssvr22.news.prodigy.net ...

Quote:

Originally Posted by

>>>
>>
>>>
>>>
>>One problem with remote desktop is that you can't transfer files or
>>transfer the clipboard contents (or can you?). I use those two functions
>>all the time.

>>
>You can transfer the clipboard settings in Win2K.
>>

>
"Can" transfer, or they're transferred automatically?
>

Transferred automatically.

Quote:

Originally Posted by

>
>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||On Dec 6, 2:05 pm, "Neil" <nos...@.nospam.netwrote:

Quote:

Originally Posted by

Neil, along with the great suggestions I would explore upgrading your
box and software. Even look at client configurations, how do they
login, are they booting up daily or are the client machines left on
over night or several days thus causing the problem in itself. Does
your SA have that power to dictate what is sufficient? What does it
harm? Granted rebooting and shutting down a server box is not good for
the long term.

HTH...|||OK, here's another one: no way to sent Ctrl+Alt+Del. With PCAnywhere, I can
send a Ctrl+Alt+Del and bring up Task Manager. How would one do that in
remote desktop?

"Ed Murphy" <emurphy42@.socal.rr.comwrote in message
news:4759bb35$0$2384$4c368faf@.roadrunner.com...

Quote:

Originally Posted by

Neil wrote:
>

Quote:

Originally Posted by

>One problem with remote desktop is that you can't transfer files or
>transfer the clipboard contents (or can you?). I use those two functions
>all the time.

>
The clipboard contents are auto-copied whenever they change on either
side. I don't think you can transfer files, but you can work around
that with an FTP server.

|||"Neil" <nospam@.nospam.netwrote in message
news:PyCaj.568$se5.316@.nlpi069.nbdc.sbc.com...

Quote:

Originally Posted by

OK, here's another one: no way to sent Ctrl+Alt+Del. With PCAnywhere, I
can send a Ctrl+Alt+Del and bring up Task Manager. How would one do that
in remote desktop?

http://support.microsoft.com/kb/186624
CTRL-ALT-END

Quote:

Originally Posted by

>
>
>
"Ed Murphy" <emurphy42@.socal.rr.comwrote in message
news:4759bb35$0$2384$4c368faf@.roadrunner.com...

Quote:

Originally Posted by

>Neil wrote:
>>

Quote:

Originally Posted by

>>One problem with remote desktop is that you can't transfer files or
>>transfer the clipboard contents (or can you?). I use those two functions
>>all the time.

>>
>The clipboard contents are auto-copied whenever they change on either
>side. I don't think you can transfer files, but you can work around
>that with an FTP server.

>
>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hey, thanks, that's great.

I was also wondering about toggling between full screen and windowed mode
(Alt+Enter in PCAnywhere). I see that's CTRL+ALT+BREAK in TS. But, while
I'm glad that TS has a shortcut for that, that's a bit unwieldy, especially
since Break on my laptop is Fn+Break!! Guess I'll just have to use the mouse
to toggle.

Neil

"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13mm5akkg0q5l4b@.corp.supernews.com...

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:PyCaj.568$se5.316@.nlpi069.nbdc.sbc.com...

Quote:

Originally Posted by

>OK, here's another one: no way to sent Ctrl+Alt+Del. With PCAnywhere, I
>can send a Ctrl+Alt+Del and bring up Task Manager. How would one do that
>in remote desktop?

>
http://support.microsoft.com/kb/186624
>
CTRL-ALT-END
>
>

Quote:

Originally Posted by

>>
>>
>>
>"Ed Murphy" <emurphy42@.socal.rr.comwrote in message
>news:4759bb35$0$2384$4c368faf@.roadrunner.com...

Quote:

Originally Posted by

>>Neil wrote:
>>>
>>>One problem with remote desktop is that you can't transfer files or
>>>transfer the clipboard contents (or can you?). I use those two
>>>functions all the time.
>>>
>>The clipboard contents are auto-copied whenever they change on either
>>side. I don't think you can transfer files, but you can work around
>>that with an FTP server.

>>
>>

>
>
>
--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com
http://www.greenms.com/sqlserver.html
>
>

|||"Neil" <nospam@.nospam.netwrote in message
news:YXHaj.33923$Pv2.8297@.newssvr23.news.prodigy.n et...

Quote:

Originally Posted by

Hey, thanks, that's great.
>
I was also wondering about toggling between full screen and windowed mode
(Alt+Enter in PCAnywhere). I see that's CTRL+ALT+BREAK in TS. But, while
I'm glad that TS has a shortcut for that, that's a bit unwieldy,
especially since Break on my laptop is Fn+Break!! Guess I'll just have to
use the mouse to toggle.
>

Yeah there were a few there that I didn't even know about.

Very useful.

Quote:

Originally Posted by

Neil

Quote:

Originally Posted by

>>
>>
>--
>Greg Moore
>SQL Server DBA Consulting Remote and Onsite available!
>Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
>>
>>

>
>

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:YXHaj.33923$Pv2.8297@.newssvr23.news.prodigy.n et...

Quote:

Originally Posted by

>Hey, thanks, that's great.
>>
>I was also wondering about toggling between full screen and windowed mode
>(Alt+Enter in PCAnywhere). I see that's CTRL+ALT+BREAK in TS. But, while
>I'm glad that TS has a shortcut for that, that's a bit unwieldy,
>especially since Break on my laptop is Fn+Break!! Guess I'll just have to
>use the mouse to toggle.
>>

>
Yeah there were a few there that I didn't even know about.
>
Very useful.
>

You'd think (just a thought) that MS would give use a dropdown with some of
the functions. Or maybe just a list of shortcuts so we could have them
handy. I guess that's too much to ask for...:-(|||"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.comwrote in message
news:13mnm3t85tebm62@.corp.supernews.com...

Quote:

Originally Posted by

"Neil" <nospam@.nospam.netwrote in message
news:YXHaj.33923$Pv2.8297@.newssvr23.news.prodigy.n et...

Quote:

Originally Posted by

>
Yeah there were a few there that I didn't even know about.
>
Very useful.
>
>

Hey, you know, I just found out that there's an option when you connect
through RDC to apply Windows key combinations to the remote computer!
Doesn't seem to work for Ctrl-Alt-Del. But seems to work for Alt-Tab.
Haven't tried it with others yet. But that's a great thing.

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!
NeilJust 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/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/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.net...
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.net...
> 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...
>|||"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.net...
> Yes. I disagree.
> I've run systems with uptimes measured in years.
> I see no value in rebooting a correctly setup system.
>
Thanks.|||
> "Neil" <nospam@.nospam.net> wrote in message
> news:NQZ5j.69213$RX.4340@.newssvr11.news.prodigy.net...
> 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...
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:uuaNHcFOIHA.4948@.TK2MSFTNGP02.phx.gbl...[vbcol=seagreen]
> 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
>
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).

Friday, March 30, 2012

One minute SQL Server 7 date time synchronization

One minute SQL Server 7 date time synchronization

One minute SQL Server 7 date time synchronization

Wednesday, March 28, 2012

One Database vs. Multiple Databases

Monday, March 26, 2012

Once a week or once a month

Once a week or once a month

Once a week or once a month

old sql2k5 folder

Blog Archive

About Me