One More Question On Running Parallel Queries

An Execute SQL task takes 1 min to run a statement "insert into Mytable select * from view_using_joins"

Output: 10,225 rows affected.

But a Dataflow task configured to fetch data from the same view_using_joins into MyTable takes hours to do the same.

Could you please explain why is it so ?

Thanks

Subhash Subramanyam

I am not surprised that the Execute SQL Task is quicker. When you're inserting from one table to another in the same database then SSIS isn't going to outperform the database engine.

I don't know why it is hours quicker. There isn't really enough information here to say. What destination adapter are you using? Is the package running on the same machine as the database? Are you doing transformations on the way?

-Jamie

|||

Hi Jamie,

Thanks for your reply.

1) I am running packages on a different server.

2) Using OLEDB adapters for Source and Destination . Here Database as well as the server are same for Source and Destination

3) No transformations in between

Wonder if we have to do some extra settings to here to achieve the same duration as that of execute sql task ?

Thanks

Subhash Subramanyam

|||

Have you chosen Fast Load on your destination?

Thanks.

|||

Subhash512525 wrote:

Hi Jamie,

Thanks for your reply.

1) I am running packages on a different server.

2) Using OLEDB adapters for Source and Destination . Here Database as well as the server are same for Source and Destination

3) No transformations in between

Wonder if we have to do some extra settings to here to achieve the same duration as that of execute sql task ?

Thanks

Subhash Subramanyam

You're running the package on a different server? I'd suggest that's yur problem right there. The data is going to have to go over the network - obviously this is going to take time.

Also, in your destination are you inserting with Fast Load?

I say again, in this scenario the data-flow isn't going to outperform the Execute SQL Task.

-Jamie

|||

Great Jamie, you figured out.

If you don't mind spending few minutes here, I am coming back to my actual scenario.

I surely expect specific views from experts here for each of the questions here: Phil B, Rafael S, Darren G, Jwelch, JayH, Scott B, Ashwin S, Brian, Bob, Donald F and many others I am still not aware of.

Scenario:

1) My SSIS Packages are run at US server. scheduleld during Nights.

2) Each Package runs 6-8 queries each having Joins Parallelly pulling data from Oracle Database Source (UNIX) in Europe, Total Data extracted do not exceed 5 Million rows)

3) Destination Database is at US.

4) Network Bandwidth (2 Mbps)

Problem is that It almost takes ages to execute these Packages (Ranging from 25 hours to 30 hours)

Questions are:

1) Where should I expect to run the SSIS Packages to give a better performance?

2) How can I perform only incremental load (using Dataflow task) taking into consideration performance aspects? (Any links for this can help)

3) Does the overlap of the Schedules for SSIS packages afffect the performance?

4) Are there any limits on running number of queries in parallell to pull data from oracle source

5) Will it be the best way, If I spool the query results into flat files on a local system where the source (oracle database) runs at Europe and then ftp them to a shared server at US, which I can use it for importing into Destination table

Waiting for your reply,

Many Thanks and Regards

Subhash Subramanyam

|||Thanks Bob, Please give your answers for my below questions if don't mind.|||The more work you can do to prevent keeping the data transmission "pipe" open, the better.

Perform your source query in Europe, export that to a file, compress it, and then FTP it to the US. Then uncompress it, and load it with SSIS.

The idea is to keep your transmissions across "the pond" as short as possible.|||

From your question #2, I'm assuming you are pulling all rows every night. As Phil mentioned, you want to minimize how much data you are actually moving, so I'd definately make this incremental. A common way to implement that is by checking modified dates on the source system via a WHERE clause in your source SELECT statements. Store the range of modified dates that you retreive, and when the package is run the next night, start from the end of the previous range.

If you don't have modified dates in the source system, consider adding them. Alternatives are using triggers to track changes, or using a change data capture tool - I believe Oracle has one, and SQL Server will have one with SQL Server 2008.

|||

One more question:

6) If I have 6-8 queries running in parallel, Whether having a common connection Manager (for an Oracle source) for all performs better or having Distinct Connection Manager performs better ?

Still expecting suggestions and the views of rest of the experts for six questions listed here.

Regards

Subhash Subramanyam

|||

Subhash512525 wrote:

6) If I have 6-8 queries running in parallel, Whether having a common connection Manager (for an Oracle source) for all performs better or having Distinct Connection Manager performs better ?

It depends Using a single one should result in the same performance as having several, assuming you are not using RetainSameConnection on them. Having a single connection manager doesn't mean that SSIS won't open multiple connections to the database. A Connection Manager manages multiple connections to the database, unless you force it to use only a single connection with RetainSameConnection.

A related note - in your scenario, have you tested whether performance is better if you run all queries sequentially or in parallel (by using precedence constraints on the data flow tasks)?

|||

jwelch wrote:

A related note - in your scenario, have you tested whether performance is better if you run all queries sequentially or in parallel (by using precedence constraints on the data flow tasks)?

Jwelch, This seem more practical. I'll test this and let you know..

Thanks

Subhash

One failed subscription prevents running all others

Hello,
I was trying to invertigate why a certain report does not run properly in
some cases. I scheduled it to run daily. So far so good, i got logfiles to
study. However, since this try RS no longer executes ANY scheduled
subscription. i made no changes to the system, just scheduled a defective
report. (which BTW was in Excel and the row-count exceded 65536). Does
anybode know how to edit the (hypothetical) queue used by RS to clear the way
for my other subscriptions.
extra info: RSExecutionlog DB has no entries of executed subscriptions. The
SQL job manager says all jobs have executed succesfully as planned.(including
the subscriptions)Are there any rows in either the event table or notifications table?
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ard Goossens" <ArdGoossens@.discussions.microsoft.com> wrote in message
news:175AE411-3994-4C8E-993F-8D4D258219B8@.microsoft.com...
> Hello,
> I was trying to invertigate why a certain report does not run properly in
> some cases. I scheduled it to run daily. So far so good, i got logfiles
> to
> study. However, since this try RS no longer executes ANY scheduled
> subscription. i made no changes to the system, just scheduled a defective
> report. (which BTW was in Excel and the row-count exceded 65536). Does
> anybode know how to edit the (hypothetical) queue used by RS to clear the
> way
> for my other subscriptions.
> extra info: RSExecutionlog DB has no entries of executed subscriptions.
> The
> SQL job manager says all jobs have executed succesfully as
> planned.(including
> the subscriptions)
>

One DB machine for Two WebSites

When there is 1 DB machine for 2 web sites, is it better to have

One DataBase-instance running with 2 DataBase-Initial-Catalogs ?

or

Two DataBase-instances running, each with 1 DataBase-Initial-Catalog ?

using SQLExpress or SQLServer

please only look at those possible, simple conditions.

forget about read/write same tables, security issues..

Interms of Memory/CPU/ Performance, which setting seems better ?

Please give some thoughts on Performance / DataLoad / Consumption,,,etc...

thanks.

For pure performance and simplicity, one instance of SQL Server with two databases will work better. With multiple instances of SQL Server, your available memory is split between the instances.|||

Thanks.

But if another instance is running and loads in memory,

would it be faster for getting results in database ?

Assume I have lots of memory.

thanks.

|||One instance will be faster than two instances, since the single instance will have access to all of the machine's resources (RAM, CPU, I/O).

One CPU out of 32 pegged to 85%

Hey All,

We are running sql 2000 on 32 processor box. It is so weird that
around 4:30 PM every day one CPU spikes upto 85-90%. It continues to
go like that until rest of the day. We checked for jobs that will
start around that time but no luck. Only thing that we doubt now is a
job that starts around 2:30 pm. The job GZIPs the trace file from the
server and copies it to another server. Still, whats confusing is the
job starts around 2:30 PM but cpu spike starts around 4 PM. Can
someone tell me how can I find out what is running on that particular
processor.

Thanks for your help in advance.

SenthilYou might try using Performance Monitor. Select Process / % Processor
Time / All instances. This will help identify the EXE consuming the
processor.

--
Hope this helps.

Dan Guzman
SQL Server MVP

--------
SQL FAQ links (courtesy Neil Pike):

http://www.ntfaq.com/Articles/Index...epartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--------

"Senthil" <senthil_tamil@.yahoo.com> wrote in message
news:46b4744a.0307111624.594a0159@.posting.google.c om...
> Hey All,
> We are running sql 2000 on 32 processor box. It is so weird that
> around 4:30 PM every day one CPU spikes upto 85-90%. It continues to
> go like that until rest of the day. We checked for jobs that will
> start around that time but no luck. Only thing that we doubt now is a
> job that starts around 2:30 pm. The job GZIPs the trace file from the
> server and copies it to another server. Still, whats confusing is the
> job starts around 2:30 PM but cpu spike starts around 4 PM. Can
> someone tell me how can I find out what is running on that particular
> processor.
> Thanks for your help in advance.
> Senthil

one conflict > all other replication hangs

hi all

let's say i have three publications running on a network of one central server and four shops.

- a merge replication that keeps the price-table up to date between all shops and the central server

- a transactional replication of the arrived_orders-table from the central server to the shop in case

- a transactional replication of the sold_products-table fromt he shops to the central server.

the whole replication network runs on a distribution database that is located on the central server.

now, i've noticed already a few times, when a conflict occurs in one of the replications, also all other replications stop working. (for example when the transactional replication can not insert a line in the sold_products table because of a violation against a UNIQUE constraint in the central server).

Is it normal that also the merge replication and the other transactional replication don't do their inserts, updates etc any more?

Thanks

Different replications uses different instances of replication agent (logreader, distribution and merge). Other replication agents should continue when one agent fails. Does other agents run at all, or they are having failures also?

Peng

|||@.peng song
they don't use the same distribution agent, isn't it?
i configured only once my distribution database on my central server.... only once (!).... and you say that they use other distribution agent?

can someone explain this?
|||

although you may use one distribution database, there are different distribution/merge agent processes running for each of the replication. So you need to take a look at the error message for the other agent jobs and do the troubleshooting from there.

Peng

|||@.peng song: and about a log reader agent?
if several publications exist of one and the same table of a database, then it uses the same log reader agent or does it uses for each publication another instance?

this comes into my mind because in the scripts i have to install, i have one script that has to be installed in advance:

use [DBX]
exec sp_replicationdboption @.dbname = N'dbx', @.optname = N'publish', @.value = N'true'
GO
use [DBX]
exec [dbx].sys.sp_addlogreader_agent @.job_login = N'pcn\login', @.job_password = pwx, @.publisher_security_mode = 0, @.publisher_login = N'login', @.publisher_password = N'pwx', @.job_name = null
GO

this is the only place in my scripts that i have to install, where i see the sp_addlogreader_agent.... this is slightly in contradiction to what you say above, that for each replication another instance is created.

am i right or am i wrong?
(it's also possible that the scripts that i received are wrong of course)
|||i found maybe the problem.
it was the log reader agent that failed at all transactional replications.

there is still a question:
is there one log reader agent per publication, or one log reader agent per table (on which replication is installed) ?

(so if i have multiple transactional publications of one table, is there one log reader agent or multiple?)
|||

There is one logreader agent for each published database. So if there are multiple publications on a single database, there is only one log reader.

Your origional post indicates that your two transactional publications are on different server. So I assume they are using different agents.

What error message do you see.

Peng

|||

the problem was only in the second point of my original post.

(i found after investigation that the merge replication and the third replication of my original post still continued to do their job fine).

the problem was only in the publications of the deliveredOrders-table on the central server.

for specific reasons i created a transactional publication of the deliveredorders-table on the central server towards each shop (so a filtered publication for each shop).

the error i got was this: "The process could not execute 'sp_replcmds" for all publications of that type.

All publications failed.

my solution was: i recreated all publications, and now it works fine again since ten days ago.

the problem was probably that i exported one script to install one publication of that type, and for all other publications i copy-pasted the file and just updated manually the parameters. probably something was badly changed while manually changing the installation scripts.

sql

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

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

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

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

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

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

>>

"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

----------------
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:s2f6j.23284$4V6.14684@.newssvr14.news.prodigy. net...

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

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

>>

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

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

>
>

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

>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

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

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

OMWWIZE and Copy Database Wizard

Please help.
I am trying to move one of our production databases (MSSQL7) to a larger,
more powerful box running MSSQL2000. Each time I run the copy database
wizard, I get a failure with the error message reading "Failed to create the
share OMWWIZE."
What is this share? Why do I need it? Why would this step fail? Where should
it be? How do I fix this?
I say again, please help.
--
Kerry CarrollHave a look here
http://support.microsoft.com/default.aspx?scid=kb;en-us;q274463
--
Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
"Good Try" <test@.not.com> wrote in message
news:eL59ym$vDHA.1576@.TK2MSFTNGP11.phx.gbl...
> Please help.
> I am trying to move one of our production databases (MSSQL7) to a larger,
> more powerful box running MSSQL2000. Each time I run the copy database
> wizard, I get a failure with the error message reading "Failed to create
the
> share OMWWIZE."
> What is this share? Why do I need it? Why would this step fail? Where
should
> it be? How do I fix this?
> I say again, please help.
> --
> Kerry Carroll
>