Has anyone sees issues where although the exec plans are the same , theres
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>
|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue's
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>
|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization[vbcol=seagreen]
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
theres[vbcol=seagreen]
at[vbcol=seagreen]
when[vbcol=seagreen]
long[vbcol=seagreen]
these[vbcol=seagreen]
then[vbcol=seagreen]
reboot[vbcol=seagreen]
Showing posts with label reboot. Show all posts
Showing posts with label reboot. Show all posts
Wednesday, March 21, 2012
n/w issues and had to reboot.
Has anyone sees issues where although the exec plans are the same , theres
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as lon
g
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain thes
e
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a rebo
ot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue'
s
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as lon
g
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain thes
e
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a rebo
ot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization[vbcol=seagreen]
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
>
theres[vbcol=seagreen]
at[vbcol=seagreen]
when[vbcol=seagreen]
long[vbcol=seagreen]
these[vbcol=seagreen]
then[vbcol=seagreen]
reboot[vbcol=seagreen]
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as lon
g
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain thes
e
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a rebo
ot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue'
s
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as lon
g
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain thes
e
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a rebo
ot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization[vbcol=seagreen]
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
>
theres[vbcol=seagreen]
at[vbcol=seagreen]
when[vbcol=seagreen]
long[vbcol=seagreen]
these[vbcol=seagreen]
then[vbcol=seagreen]
reboot[vbcol=seagreen]
n/w issues and had to reboot.
Has anyone sees issues where although the exec plans are the same , theres
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue's
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
> > Has anyone sees issues where although the exec plans are the same ,
theres
> > no blocking, and identical hardware that the query would perform slower
at
> > times to return the results to the client whereas it runs much faster
when
> > run on the same box. The query return a few million rows.. It takes as
long
> > as 1 hr when its slow and as fast as 5 mins when its normal to obtain
these
> > results on the client.
> >
> > Even stopping and starting SQL doesnt work. I just have to reboot and
then
> > its all fast again. I am thinking its being choked someplace.
> > I have seen this same behaviour on another server as well. and only a
reboot
> > would work. No messages in the log, nothing..
> >
> > A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
> >
> >
> >
> >sql
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue's
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
> > Has anyone sees issues where although the exec plans are the same ,
theres
> > no blocking, and identical hardware that the query would perform slower
at
> > times to return the results to the client whereas it runs much faster
when
> > run on the same box. The query return a few million rows.. It takes as
long
> > as 1 hr when its slow and as fast as 5 mins when its normal to obtain
these
> > results on the client.
> >
> > Even stopping and starting SQL doesnt work. I just have to reboot and
then
> > its all fast again. I am thinking its being choked someplace.
> > I have seen this same behaviour on another server as well. and only a
reboot
> > would work. No messages in the log, nothing..
> >
> > A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
> >
> >
> >
> >sql
Monday, February 20, 2012
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
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
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
Subscribe to:
Posts (Atom)