Mysterious Sql2000 process blocking

I have made several posts regarding my sql2000 cpu mysteriously staying at
100% for 10 minutes at a time. Using a performance monitor, I finally
noticed that during these times there is a sql process that is blocking the
others and causing some kind of "race" condition. The blocked processes
time out, but the blocking process seems to stay blocked often until the
service is restarted. It seems like sql should not allow this. I have not
been able to find out the cause or statements that produced the problem.
The only application using the sql server is an ASP.NET application that
uses 100% stored procedures (no dynamic sql). Does anyone have any
suggestions for finding the cause of process blocking like this? Thanks.
Dan,
You'd have to examine the code to determine this.
These may help:
http://www.sql-server-performance.co...prevention.asp
and
http://www.support.microsoft.com/?id=224453
and
http://www.support.microsoft.com/?id=271509
and
http://support.microsoft.com/?id=224587
and
http://support.microsoft.com/?id=243589
and
http://support.microsoft.com/?id=243588
HTH
Jerry
"Dan English" <dan_english2@.cox.net> wrote in message
news:eUAAmR4zFHA.2960@.tk2msftngp13.phx.gbl...
>I have made several posts regarding my sql2000 cpu mysteriously staying at
>100% for 10 minutes at a time. Using a performance monitor, I finally
>noticed that during these times there is a sql process that is blocking the
>others and causing some kind of "race" condition. The blocked processes
>time out, but the blocking process seems to stay blocked often until the
>service is restarted. It seems like sql should not allow this. I have
>not been able to find out the cause or statements that produced the
>problem. The only application using the sql server is an ASP.NET
>application that uses 100% stored procedures (no dynamic sql). Does anyone
>have any suggestions for finding the cause of process blocking like this?
>Thanks.
>

Mysterious Sql2000 process blocking

I have made several posts regarding my sql2000 cpu mysteriously staying at
100% for 10 minutes at a time. Using a performance monitor, I finally
noticed that during these times there is a sql process that is blocking the
others and causing some kind of "race" condition. The blocked processes
time out, but the blocking process seems to stay blocked often until the
service is restarted. It seems like sql should not allow this. I have not
been able to find out the cause or statements that produced the problem.
The only application using the sql server is an ASP.NET application that
uses 100% stored procedures (no dynamic sql). Does anyone have any
suggestions for finding the cause of process blocking like this? Thanks.Dan,
You'd have to examine the code to determine this.
These may help:
http://www.sql-server-performance.com/sf_block_prevention.asp
and
http://www.support.microsoft.com/?id=224453
and
http://www.support.microsoft.com/?id=271509
and
http://support.microsoft.com/?id=224587
and
http://support.microsoft.com/?id=243589
and
http://support.microsoft.com/?id=243588
HTH
Jerry
"Dan English" <dan_english2@.cox.net> wrote in message
news:eUAAmR4zFHA.2960@.tk2msftngp13.phx.gbl...
>I have made several posts regarding my sql2000 cpu mysteriously staying at
>100% for 10 minutes at a time. Using a performance monitor, I finally
>noticed that during these times there is a sql process that is blocking the
>others and causing some kind of "race" condition. The blocked processes
>time out, but the blocking process seems to stay blocked often until the
>service is restarted. It seems like sql should not allow this. I have
>not been able to find out the cause or statements that produced the
>problem. The only application using the sql server is an ASP.NET
>application that uses 100% stored procedures (no dynamic sql). Does anyone
>have any suggestions for finding the cause of process blocking like this?
>Thanks.
>

Mysterious Sql2000 process blocking

I have made several posts regarding my sql2000 cpu mysteriously staying at
100% for 10 minutes at a time. Using a performance monitor, I finally
noticed that during these times there is a sql process that is blocking the
others and causing some kind of "race" condition. The blocked processes
time out, but the blocking process seems to stay blocked often until the
service is restarted. It seems like sql should not allow this. I have not
been able to find out the cause or statements that produced the problem.
The only application using the sql server is an ASP.NET application that
uses 100% stored procedures (no dynamic sql). Does anyone have any
suggestions for finding the cause of process blocking like this? Thanks.Dan,
You'd have to examine the code to determine this.
These may help:
http://www.sql-server-performance.c..._prevention.asp
and
http://www.support.microsoft.com/?id=224453
and
http://www.support.microsoft.com/?id=271509
and
http://support.microsoft.com/?id=224587
and
http://support.microsoft.com/?id=243589
and
http://support.microsoft.com/?id=243588
HTH
Jerry
"Dan English" <dan_english2@.cox.net> wrote in message
news:eUAAmR4zFHA.2960@.tk2msftngp13.phx.gbl...
>I have made several posts regarding my sql2000 cpu mysteriously staying at
>100% for 10 minutes at a time. Using a performance monitor, I finally
>noticed that during these times there is a sql process that is blocking the
>others and causing some kind of "race" condition. The blocked processes
>time out, but the blocking process seems to stay blocked often until the
>service is restarted. It seems like sql should not allow this. I have
>not been able to find out the cause or statements that produced the
>problem. The only application using the sql server is an ASP.NET
>application that uses 100% stored procedures (no dynamic sql). Does anyone
>have any suggestions for finding the cause of process blocking like this?
>Thanks.
>

Mysterious Performance Degradation

Hi,
A batch job which updates a table in a SQL Server database took three hours
to run last week. Nothing changed except perhaps the database grew by 1%.
Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
log file to match the production database server - this same job runs in
about 2 hours on that server. I monitored the buffer cache hit ratio,
%Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
Time, and Processor Queue Length counters - they all fall well within
recommended thresholds. The difference between the two servers: the problem
server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
know the job on my server won'f finish as fast as the same job on the Prod
server. But why this sudden change from 3 to 30 hours?
index maintenance being done ?
Greg Jackson
PDX, Oregon
|||The database had been restored using a production database backup. The
indexes are regularly defragmented on the production database.
"pdxJaxon" wrote:

> index maintenance being done ?
>
> Greg Jackson
> PDX, Oregon
>
>
|||need to perform update statistics on the dev server.
"Simi B." wrote:
[vbcol=seagreen]
> The database had been restored using a production database backup. The
> indexes are regularly defragmented on the production database.
> "pdxJaxon" wrote:
|||Dis you check the execution plan of the job on both the servers. That might
give you insight into if some statistics are missing etc.
"Simi B." wrote:

> Hi,
> A batch job which updates a table in a SQL Server database took three hours
> to run last week. Nothing changed except perhaps the database grew by 1%.
> Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
> log file to match the production database server - this same job runs in
> about 2 hours on that server. I monitored the buffer cache hit ratio,
> %Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
> Time, and Processor Queue Length counters - they all fall well within
> recommended thresholds. The difference between the two servers: the problem
> server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
> know the job on my server won'f finish as fast as the same job on the Prod
> server. But why this sudden change from 3 to 30 hours?
|||Thanks all for your help. I was able to get it down from 41 hours to 7
hours...will see how I can tune it some more... =)
"harvinder" wrote:
[vbcol=seagreen]
> Dis you check the execution plan of the job on both the servers. That might
> give you insight into if some statistics are missing etc.
> "Simi B." wrote:
|||Simi B,
I am facing a similar unexpected performance with one of my production
database servers. What was it that reduced your execution time?
I'm similarly stuck.
Jeremiah
"Simi B." wrote:
[vbcol=seagreen]
> Thanks all for your help. I was able to get it down from 41 hours to 7
> hours...will see how I can tune it some more... =)
> "harvinder" wrote:
|||I reindexed all the tables, ran dbcc checkdb, updated statistics,
defragmented the hard drive on which the database resided.
"Jeremiah Traxler" wrote:
[vbcol=seagreen]
> Simi B,
> I am facing a similar unexpected performance with one of my production
> database servers. What was it that reduced your execution time?
> I'm similarly stuck.
> Jeremiah
> "Simi B." wrote:

Mysterious Performance Degradation

Hi,
A batch job which updates a table in a SQL Server database took three hours
to run last week. Nothing changed except perhaps the database grew by 1%.
Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
log file to match the production database server - this same job runs in
about 2 hours on that server. I monitored the buffer cache hit ratio,
%Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
Time, and Processor Queue Length counters - they all fall well within
recommended thresholds. The difference between the two servers: the problem
server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
know the job on my server won'f finish as fast as the same job on the Prod
server. But why this sudden change from 3 to 30 hours?index maintenance being done ?
Greg Jackson
PDX, Oregon|||The database had been restored using a production database backup. The
indexes are regularly defragmented on the production database.
"pdxJaxon" wrote:

> index maintenance being done ?
>
> Greg Jackson
> PDX, Oregon
>
>|||need to perform update statistics on the dev server.
"Simi B." wrote:
[vbcol=seagreen]
> The database had been restored using a production database backup. The
> indexes are regularly defragmented on the production database.
> "pdxJaxon" wrote:
>|||Dis you check the execution plan of the job on both the servers. That might
give you insight into if some statistics are missing etc.
"Simi B." wrote:

> Hi,
> A batch job which updates a table in a SQL Server database took three hour
s
> to run last week. Nothing changed except perhaps the database grew by 1%.
> Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
> log file to match the production database server - this same job runs in
> about 2 hours on that server. I monitored the buffer cache hit ratio,
> %Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
> Time, and Processor Queue Length counters - they all fall well within
> recommended thresholds. The difference between the two servers: the probl
em
> server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
> know the job on my server won'f finish as fast as the same job on the Prod
> server. But why this sudden change from 3 to 30 hours?|||Thanks all for your help. I was able to get it down from 41 hours to 7
hours...will see how I can tune it some more... =)
"harvinder" wrote:
[vbcol=seagreen]
> Dis you check the execution plan of the job on both the servers. That migh
t
> give you insight into if some statistics are missing etc.
> "Simi B." wrote:
>|||Simi B,
I am facing a similar unexpected performance with one of my production
database servers. What was it that reduced your execution time?
I'm similarly stuck.
Jeremiah
"Simi B." wrote:
[vbcol=seagreen]
> Thanks all for your help. I was able to get it down from 41 hours to 7
> hours...will see how I can tune it some more... =)
> "harvinder" wrote:
>|||I reindexed all the tables, ran dbcc checkdb, updated statistics,
defragmented the hard drive on which the database resided.
"Jeremiah Traxler" wrote:
[vbcol=seagreen]
> Simi B,
> I am facing a similar unexpected performance with one of my production
> database servers. What was it that reduced your execution time?
> I'm similarly stuck.
> Jeremiah
> "Simi B." wrote:
>

Mysterious Performance Degradation

Hi,
A batch job which updates a table in a SQL Server database took three hours
to run last week. Nothing changed except perhaps the database grew by 1%.
Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
log file to match the production database server - this same job runs in
about 2 hours on that server. I monitored the buffer cache hit ratio,
%Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
Time, and Processor Queue Length counters - they all fall well within
recommended thresholds. The difference between the two servers: the problem
server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
know the job on my server won'f finish as fast as the same job on the Prod
server. But why this sudden change from 3 to 30 hours?index maintenance being done ?
Greg Jackson
PDX, Oregon|||The database had been restored using a production database backup. The
indexes are regularly defragmented on the production database.
"pdxJaxon" wrote:
> index maintenance being done ?
>
> Greg Jackson
> PDX, Oregon
>
>|||need to perform update statistics on the dev server.
"Simi B." wrote:
> The database had been restored using a production database backup. The
> indexes are regularly defragmented on the production database.
> "pdxJaxon" wrote:
> > index maintenance being done ?
> >
> >
> > Greg Jackson
> > PDX, Oregon
> >
> >
> >|||Dis you check the execution plan of the job on both the servers. That might
give you insight into if some statistics are missing etc.
"Simi B." wrote:
> Hi,
> A batch job which updates a table in a SQL Server database took three hours
> to run last week. Nothing changed except perhaps the database grew by 1%.
> Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
> log file to match the production database server - this same job runs in
> about 2 hours on that server. I monitored the buffer cache hit ratio,
> %Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
> Time, and Processor Queue Length counters - they all fall well within
> recommended thresholds. The difference between the two servers: the problem
> server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
> know the job on my server won'f finish as fast as the same job on the Prod
> server. But why this sudden change from 3 to 30 hours?|||Thanks all for your help. I was able to get it down from 41 hours to 7
hours...will see how I can tune it some more... =)
"harvinder" wrote:
> Dis you check the execution plan of the job on both the servers. That might
> give you insight into if some statistics are missing etc.
> "Simi B." wrote:
> > Hi,
> > A batch job which updates a table in a SQL Server database took three hours
> > to run last week. Nothing changed except perhaps the database grew by 1%.
> > Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
> > log file to match the production database server - this same job runs in
> > about 2 hours on that server. I monitored the buffer cache hit ratio,
> > %Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
> > Time, and Processor Queue Length counters - they all fall well within
> > recommended thresholds. The difference between the two servers: the problem
> > server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
> > know the job on my server won'f finish as fast as the same job on the Prod
> > server. But why this sudden change from 3 to 30 hours?|||Simi B,
I am facing a similar unexpected performance with one of my production
database servers. What was it that reduced your execution time?
I'm similarly stuck.
Jeremiah
"Simi B." wrote:
> Thanks all for your help. I was able to get it down from 41 hours to 7
> hours...will see how I can tune it some more... =)
> "harvinder" wrote:
> > Dis you check the execution plan of the job on both the servers. That might
> > give you insight into if some statistics are missing etc.
> >
> > "Simi B." wrote:
> >
> > > Hi,
> > > A batch job which updates a table in a SQL Server database took three hours
> > > to run last week. Nothing changed except perhaps the database grew by 1%.
> > > Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
> > > log file to match the production database server - this same job runs in
> > > about 2 hours on that server. I monitored the buffer cache hit ratio,
> > > %Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
> > > Time, and Processor Queue Length counters - they all fall well within
> > > recommended thresholds. The difference between the two servers: the problem
> > > server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
> > > know the job on my server won'f finish as fast as the same job on the Prod
> > > server. But why this sudden change from 3 to 30 hours?|||I reindexed all the tables, ran dbcc checkdb, updated statistics,
defragmented the hard drive on which the database resided.
"Jeremiah Traxler" wrote:
> Simi B,
> I am facing a similar unexpected performance with one of my production
> database servers. What was it that reduced your execution time?
> I'm similarly stuck.
> Jeremiah
> "Simi B." wrote:
> > Thanks all for your help. I was able to get it down from 41 hours to 7
> > hours...will see how I can tune it some more... =)
> >
> > "harvinder" wrote:
> >
> > > Dis you check the execution plan of the job on both the servers. That might
> > > give you insight into if some statistics are missing etc.
> > >
> > > "Simi B." wrote:
> > >
> > > > Hi,
> > > > A batch job which updates a table in a SQL Server database took three hours
> > > > to run last week. Nothing changed except perhaps the database grew by 1%.
> > > > Suddenly this job takes 30+ hours to finish. I increased tempDB datafile,
> > > > log file to match the production database server - this same job runs in
> > > > about 2 hours on that server. I monitored the buffer cache hit ratio,
> > > > %Processor Time, Pages/Sec, Avg Disk Queue Length, Available Bytes, %Disk
> > > > Time, and Processor Queue Length counters - they all fall well within
> > > > recommended thresholds. The difference between the two servers: the problem
> > > > server has 1 GB of RAM whereas the Production server has 2 GB of RAM. I
> > > > know the job on my server won'f finish as fast as the same job on the Prod
> > > > server. But why this sudden change from 3 to 30 hours?

Mysterious and sudden performance worsening

A few days ago one of the server I use become very slow. I've a tween
server, it's pretty equal to it's brother: it's still working properly (it
runs at about 10 time faster for the same query).
I checked the hardware (raid controller, network connection and general
performances) and it seems perfect. The memory occupation and the processor
use is equal to it's tween, but the disk access has abnormally increased. To
solve the proble I've:
1 - restarted the server
2 - installed all the patches, updates and services pack I could find.
My last chance is to reistall SQL server, but I still hope to find a more
"scientific" solution.
Thanks for any suggestion.
MTA variety of things coul cause this. Just a few ideas that might be useful:
Perhaps the database has become fragmented?
Perhaps index statistics are out of date / not being updated automatically?
Have indexes been dropped?
Are there any long running transactions?
Regards,
Greg Linwood
SQL Server MVP
"MT" <cutme.mttc1685@.hotmail.com> wrote in message
news:qACnb.73796$vO5.2693264@.twister1.libero.it...
> A few days ago one of the server I use become very slow. I've a tween
> server, it's pretty equal to it's brother: it's still working properly (it
> runs at about 10 time faster for the same query).
> I checked the hardware (raid controller, network connection and general
> performances) and it seems perfect. The memory occupation and the
processor
> use is equal to it's tween, but the disk access has abnormally increased.
To
> solve the proble I've:
> 1 - restarted the server
> 2 - installed all the patches, updates and services pack I could find.
> My last chance is to reistall SQL server, but I still hope to find a more
> "scientific" solution.
> Thanks for any suggestion.
> MT
>|||To add to Greg's post:
Check out the execution plans, se if that differs. This is what I would start with. Can for example
lead to out-of-date statistics (as per Greg's post).
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"MT" <cutme.mttc1685@.hotmail.com> wrote in message
news:qACnb.73796$vO5.2693264@.twister1.libero.it...
> A few days ago one of the server I use become very slow. I've a tween
> server, it's pretty equal to it's brother: it's still working properly (it
> runs at about 10 time faster for the same query).
> I checked the hardware (raid controller, network connection and general
> performances) and it seems perfect. The memory occupation and the processor
> use is equal to it's tween, but the disk access has abnormally increased. To
> solve the proble I've:
> 1 - restarted the server
> 2 - installed all the patches, updates and services pack I could find.
> My last chance is to reistall SQL server, but I still hope to find a more
> "scientific" solution.
> Thanks for any suggestion.
> MT
>|||I have had similar proplems. Run a DBCC INDEX DEFRAG and
sp_updatestatistics. That should greatly improve the performance.
Thanks
Bryan
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:eBWsv6fnDHA.2404@.TK2MSFTNGP12.phx.gbl...
> To add to Greg's post:
> Check out the execution plans, se if that differs. This is what I would
start with. Can for example
> lead to out-of-date statistics (as per Greg's post).
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
>
> "MT" <cutme.mttc1685@.hotmail.com> wrote in message
> news:qACnb.73796$vO5.2693264@.twister1.libero.it...
> > A few days ago one of the server I use become very slow. I've a tween
> > server, it's pretty equal to it's brother: it's still working properly
(it
> > runs at about 10 time faster for the same query).
> > I checked the hardware (raid controller, network connection and general
> > performances) and it seems perfect. The memory occupation and the
processor
> > use is equal to it's tween, but the disk access has abnormally
increased. To
> > solve the proble I've:
> > 1 - restarted the server
> > 2 - installed all the patches, updates and services pack I could find.
> >
> > My last chance is to reistall SQL server, but I still hope to find a
more
> > "scientific" solution.
> > Thanks for any suggestion.
> > MT
> >
> >
>|||Problem "partially" solved: the test was made using microsoft DAO on a PC
with microsft XP with integrated security. I changed to SqlServer security
and now everything works properly. I'm afraid I will never know what caused
the sudden worsening.
If you use DAO with XP never access the database with integrated security,
as I don't believe that they will release a patch for an obsolete platform
like DAO.
"MT" <cutme.mttc1685@.hotmail.com> ha scritto nel messaggio
news:qACnb.73796$vO5.2693264@.twister1.libero.it...
> A few days ago one of the server I use become very slow. I've a tween
> server, it's pretty equal to it's brother: it's still working properly (it
> runs at about 10 time faster for the same query).
> I checked the hardware (raid controller, network connection and general
> performances) and it seems perfect. The memory occupation and the
processor
> use is equal to it's tween, but the disk access has abnormally increased.
To
> solve the proble I've:
> 1 - restarted the server
> 2 - installed all the patches, updates and services pack I could find.
> My last chance is to reistall SQL server, but I still hope to find a more
> "scientific" solution.
> Thanks for any suggestion.
> MT
>
>

my little problem become a BIG problem....

Hi,
I've just posted some memory and performance problems...
but after my last reboot I've a big problem !
If I work remotly on the server a query takes 44 seconds to be completed and
return 155008 rows.
To view the estimated plan, less then 1 second is requiered.
But If I do the same job on the server himself, after 4minutes the result is
not display, and the estimated plan takes 12 seconds!!!
All the local access to SQL Server are very slow, but all the network access
are very good.
any idea'
Jerome.
--
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09Could perhaps ODBC tracing be turned on at the server?
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Jéjé" <willgart@._A_hAotmail_A_.com> wrote in message
news:eziZJeW9DHA.1424@.TK2MSFTNGP12.phx.gbl...
> Hi,
> I've just posted some memory and performance problems...
> but after my last reboot I've a big problem !
> If I work remotly on the server a query takes 44 seconds to be completed
and
> return 155008 rows.
> To view the estimated plan, less then 1 second is requiered.
> But If I do the same job on the server himself, after 4minutes the result
is
> not display, and the estimated plan takes 12 seconds!!!
> All the local access to SQL Server are very slow, but all the network
access
> are very good.
> any idea'
> Jerome.
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09
>|||yeah...
I've just found that this option is running!
ggrrrr
loosing time for a small option...
there is no popup to inform that the performance will be degradated when
this option is checked.
thanks.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> a écrit
dans le message de news:uJfTxuW9DHA.2696@.TK2MSFTNGP10.phx.gbl...
> Could perhaps ODBC tracing be turned on at the server?
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
>
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
>
> "Jéjé" <willgart@._A_hAotmail_A_.com> wrote in message
> news:eziZJeW9DHA.1424@.TK2MSFTNGP12.phx.gbl...
> > Hi,
> >
> > I've just posted some memory and performance problems...
> >
> > but after my last reboot I've a big problem !
> > If I work remotly on the server a query takes 44 seconds to be completed
> and
> > return 155008 rows.
> > To view the estimated plan, less then 1 second is requiered.
> >
> > But If I do the same job on the server himself, after 4minutes the
result
> is
> > not display, and the estimated plan takes 12 seconds!!!
> >
> > All the local access to SQL Server are very slow, but all the network
> access
> > are very good.
> >
> > any idea'
> >
> > Jerome.
> >
> >
> >
> > --
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09
> >
> >
>
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09

my little problem become a BIG problem....

Hi,
I've just posted some memory and performance problems...
but after my last reboot I've a big problem !
If I work remotly on the server a query takes 44 seconds to be completed and
return 155008 rows.
To view the estimated plan, less then 1 second is requiered.
But If I do the same job on the server himself, after 4minutes the result is
not display, and the estimated plan takes 12 seconds!!!
All the local access to SQL Server are very slow, but all the network access
are very good.
any idea'
Jerome.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09Could perhaps ODBC tracing be turned on at the server?
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Jj" <willgart@._A_hAotmail_A_.com> wrote in message
news:eziZJeW9DHA.1424@.TK2MSFTNGP12.phx.gbl...
> Hi,
> I've just posted some memory and performance problems...
> but after my last reboot I've a big problem !
> If I work remotly on the server a query takes 44 seconds to be completed
and
> return 155008 rows.
> To view the estimated plan, less then 1 second is requiered.
> But If I do the same job on the server himself, after 4minutes the result
is
> not display, and the estimated plan takes 12 seconds!!!
> All the local access to SQL Server are very slow, but all the network
access
> are very good.
> any idea'
> Jerome.
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09
>|||yeah...
I've just found that this option is running!
ggrrrr
loosing time for a small option...
there is no popup to inform that the performance will be degradated when
this option is checked.
thanks.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> a crit
dans le message de news:uJfTxuW9DHA.2696@.TK2MSFTNGP10.phx.gbl...
> Could perhaps ODBC tracing be turned on at the server?
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
>
http://groups.google.com/groups?oi=...ublic.sqlserver
>
> "Jj" <willgart@._A_hAotmail_A_.com> wrote in message
> news:eziZJeW9DHA.1424@.TK2MSFTNGP12.phx.gbl...
> and
result
> is
> access
>
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09