Delay with XP

Hi all,
Desperately hoping you can help, we run pentagon2000 on an
SQL Server, which runs fine on W2K PC's, but on XP
Workstations, when the Pentagon 2000 Software data is
being added or modified from a station, and it sends the
data to the SQL Server the status states in Task manager
as "Not Responding" while sending the data and waits for
the response from the SQL Server to continue its
processes. The issue I have is that although a delay of a
few seconds is acceptable and expected, on the XP
WStations it can be 20-30 seconds, in extreme cases even
longer. this is making the system unusable. Is there
anything obvious, or even obscure anyone knows of that
might be causing this.
Thanks
Ian
Ian Broome wrote:
> Hi all,
> Desperately hoping you can help, we run pentagon2000 on an
> SQL Server, which runs fine on W2K PC's, but on XP
> Workstations, when the Pentagon 2000 Software data is
> being added or modified from a station, and it sends the
> data to the SQL Server the status states in Task manager
> as "Not Responding" while sending the data and waits for
> the response from the SQL Server to continue its
> processes. The issue I have is that although a delay of a
> few seconds is acceptable and expected, on the XP
> WStations it can be 20-30 seconds, in extreme cases even
> longer. this is making the system unusable. Is there
> anything obvious, or even obscure anyone knows of that
> might be causing this.
> Thanks
> Ian
What network library are you using to connect to SQL Server? If TCP/IP
try using the IP address instead of the server name. Or try setting up a
Connection Alias on the client for both named pipes and TCP/IP and see
if that makes a difference.
Also, make sure you have the correct MDAC installed on the WinXP
clients.
The "Not Responding" does not mean the application has necessarily
stopped responding. It could either be waiting for a response from SQL
Server as you mentioned or it could be so busy processing, it won't let
the OS know that that it is alive.
Have you tried running some queries from Query Analyzer from an XP
client to see if the response you get (Select the Show Client Statistics
option) is the same as a Win 2K client.
David G.
|||[vbcol=seagreen]
>--Original Message--
>Ian Broome wrote:
an[vbcol=seagreen]
a
>What network library are you using to connect to SQL
Server? If TCP/IP
>try using the IP address instead of the server name. Or
try setting up a
>Connection Alias on the client for both named pipes and
TCP/IP and see
>if that makes a difference.
>Also, make sure you have the correct MDAC installed on
the WinXP
>clients.
>The "Not Responding" does not mean the application has
necessarily
>stopped responding. It could either be waiting for a
response from SQL
>Server as you mentioned or it could be so busy
processing, it won't let
>the OS know that that it is alive.
>Have you tried running some queries from Query Analyzer
from an XP
>client to see if the response you get (Select the Show
Client Statistics
>option) is the same as a Win 2K client.
>
>--
>David G.
>.
>
Thanks David,
Ok first off, im afraid im not SQL friendly at all, we are
a network company brought in to resolve multiple issues
which we have but this one remains. In response to your
queries:
We are using TCP/IP, with regard to using the IP rather
than the server name, im assuming you mean within the CFG
file in BDE administrator? after that you lost me im
afriad regarding connection alias.
re: the correct MDAC installed for XP, do you know what it
should be? Ive applied SP3 for SQL and SP1 for XP.
re: Query Analyzer, ive looked this up but it seems to be
a tool I have to purchase and then run queries from,
unfortunately above my head, unless you know of an
alternative way of testing this.
Thankyou for your reply, much appreciated.
Ian
|||Ian wrote:
> Thanks David,
> Ok first off, im afraid im not SQL friendly at all, we are
> a network company brought in to resolve multiple issues
> which we have but this one remains. In response to your
> queries:
> We are using TCP/IP, with regard to using the IP rather
> than the server name, im assuming you mean within the CFG
> file in BDE administrator? after that you lost me im
> afriad regarding connection alias.
> re: the correct MDAC installed for XP, do you know what it
> should be? Ive applied SP3 for SQL and SP1 for XP.
> re: Query Analyzer, ive looked this up but it seems to be
> a tool I have to purchase and then run queries from,
> unfortunately above my head, unless you know of an
> alternative way of testing this.
> Thankyou for your reply, much appreciated.
> Ian
Query Analyzer is a client tool that comes with SQL Server. There is no
charge. If you have WinXP SP1 installed, you should be fine.
It sounds like you need a DBA to do some performance testing to see
where the problem is.
David G.

Delay in package starting when running from SQL Agent

Hi,

I wonder if anybody can shed any light on this problem. I have a SQL Agent job which has three steps, each step runs an SSIS package.

The job is scheduled to start at 11.00 pm, which is does successfully. However, it has been taking between 2 and 3 hours to run, which is way longer than it should.

When I've looked at the logging, I've found that the although the job starts at 11.00 pm, the first package (in job step 1) does not start executing until about 11.30. It finishes in about 5 minutes, there is then about an hour delay before the second package (in job step 2) starts. This finishes in about 10 minutes, then there is another hour delay before the third package (in job step 3) starts.

I've tried configuring the steps as SSIS jobs, and also as cmd jobs using dtexec, both exhibit the same behaviour.

Any ideas about what could be causing this delay? The packages are stored in msdb on the same server as the SQL Agent job, if that makes any difference.

Thanks,

Sam

That sounds very strange. Although I'd guess its a SQL Server Agent problem rather than SSIS.

Can you replace the steps with something else - some simple command-line calls for example, and see if the same thing happens?

Do the log fiels for SQL Server Agent and SSIS tie up? i.e. The package may start 30 minutes late but did the job step start 30 minutes late (there's an important distinction here)?

-Jamie

|||

hi sam, I can think over that problem is that your sql agent is very busy attending other jobs ?

|||

Jamie,

Thanks for the reply, I will try the job with a couple of simple calls.

The log fields do not tie up - each job step is starting well before it's package starts.

Sam

|||

Enric,

Thanks for the reply, but this is the only job on the server at the moment, so that shouldn't be causing a problem.

Sam

|||

sam2005 wrote:

Jamie,

Thanks for the reply, I will try the job with a couple of simple calls.

The log fields do not tie up - each job step is starting well before it's package starts.

Sam

If that is the case then I would suggest that the delay is caused by the package going through validation. Set DelayValidation=TRUE on the package to see if this removes the delay. If it doesn't, set DelayValidation=TRUE on all your containers and tasks and see if this removes the delay.

If this solves the problem then you know that it is the validation step that is causing the delay. Try doing what i suggested above and then reply here and we'll take it from there!

-Jamie

|||

this is probably a longshot...

do you see this problem when you run package in bi studio?

is it possible that the service startup is slow?

there is a kb article that talks about problem in sp1

http://support.microsoft.com/?kbid=918644

|||

The DelayValidation at the package level, as suggested by Jamie, seems to have done the trick. I also found that there was a msmsgs.exe process running which was constantly using half the processor - killing this has sped things up even more.

Would the DelayValidation setting have any other impact on the package?

Sam

sql