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 identical. Show all posts
Showing posts with label identical. 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
Friday, March 9, 2012
MySQL compatibility
I have a Windows XP application that uses MSDE as its DB engine. If I
create an identical database in MySQL and include the correct ODBC
"driver", is it be possible to replace MSDE with MySQL?
What does it take for them to be compatible? After all both engines
process SQL commands.
Thanks for any input.
- Alex
"claw" <claw@.hotmail.com> wrote in message
news:2005032101053516807%claw@.hotmailcom...
>I have a Windows XP application that uses MSDE as its DB engine. If I
>create an identical database in MySQL and include the correct ODBC
>"driver", is it be possible to replace MSDE with MySQL?
> What does it take for them to be compatible? After all both engines
> process SQL commands.
> Thanks for any input.
> - Alex
Here's a quote from Google:
<quote>
You will need to use MyOLEDB, MyODBC or the MySQL .NET drivers. All links
given below:
MyOLEDB http://www.mysql.com/portal/siXtes/item-142.html
MyODBC http://www.mysql.com/downloadsX/api-myodbc-3.51.html
MySQL .NET drivers http://sourceforge.net/projectXs/mysqlnet/
I have found that MyODBC gives the most consistent results with .NET,
but others may have had different experiences. I haven't tried the open
source MySQL .NET driver yet, but it looks very promising (and hopefully
speedier than MySQL ODBC).
</quote>
You should also crosscheck data type compatibility.
Peter [MVP Visual Developer]
Jack of all trades, master of none.
|||On Mon, 21 Mar 2005 00:05:35 GMT, claw wrote:
>I have a Windows XP application that uses MSDE as its DB engine. If I
>create an identical database in MySQL and include the correct ODBC
>"driver", is it be possible to replace MSDE with MySQL?
>What does it take for them to be compatible? After all both engines
>process SQL commands.
Hi Alex,
In addition to Peter's reply, here are some other things to consider.
SQL is a highly standardized language. The ANSI standard is based on
SQL-92; the later standards SQL-99 and SQL-2003 (IIRC) are not (yet?)
adopted by ANSI. However, it is entirely up to the manufacturers to
decide to what extend they want to adhere to the standards.
MSDE is quite close to SQL-92 - most, but not all features of SQL-92 are
available. In addition, MSDE also offers a wagonload of proprietary
extra features. While these features can make programs easier to write
and maintain and faster to executed, they will also limit portability.
If the program you are using uses many of these prorietary features,
then it is quite unlikely that it will run without modification on any
other database.
I'm not sure about MySQL, since I have no experience with it. But I've
read lots of comments indicating that MySQL is not very close to the
standards. I've never attempted to verify these comments, though. But if
they're true, then switching from MSDE to MySQL might prove to be very
hard.
Another issue is that some parts of SQL are not very standardised yet.
Procedural code, for instance, like triggers or stored procedures. Or
the declaration of supporting indexes - the options available are often
tied closely to the architecture of the database; some options available
for indexes on MSDE make sense only in the context of the mechanics of
how tables and indexes are stored in MSDE.
If you have no access to the source of the application and you can't
change the exact queries submitted, then I don't think you'll succeed.
SQL being a standardized and portable language does not imply that you
can just plug any database into an application and expect it to run.
What it does mean, is that *IF* the application is written with
portability in mind, it can be adapted to a new database with only
minimal changes.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||It takes quite a lot. MySQL has no stored procedures, and only the last
version has foreign keys. Then there is the following:
http://sql-info.de/mysql/gotchas.html
1.13 is a special favourite of mine...
Jacco Schalkwijk
SQL Server MVP
"claw" <claw@.hotmail.com> wrote in message
news:2005032101053516807%claw@.hotmailcom...
>I have a Windows XP application that uses MSDE as its DB engine. If I
>create an identical database in MySQL and include the correct ODBC
>"driver", is it be possible to replace MSDE with MySQL?
> What does it take for them to be compatible? After all both engines
> process SQL commands.
> Thanks for any input.
> - Alex
create an identical database in MySQL and include the correct ODBC
"driver", is it be possible to replace MSDE with MySQL?
What does it take for them to be compatible? After all both engines
process SQL commands.
Thanks for any input.
- Alex
"claw" <claw@.hotmail.com> wrote in message
news:2005032101053516807%claw@.hotmailcom...
>I have a Windows XP application that uses MSDE as its DB engine. If I
>create an identical database in MySQL and include the correct ODBC
>"driver", is it be possible to replace MSDE with MySQL?
> What does it take for them to be compatible? After all both engines
> process SQL commands.
> Thanks for any input.
> - Alex
Here's a quote from Google:
<quote>
You will need to use MyOLEDB, MyODBC or the MySQL .NET drivers. All links
given below:
MyOLEDB http://www.mysql.com/portal/siXtes/item-142.html
MyODBC http://www.mysql.com/downloadsX/api-myodbc-3.51.html
MySQL .NET drivers http://sourceforge.net/projectXs/mysqlnet/
I have found that MyODBC gives the most consistent results with .NET,
but others may have had different experiences. I haven't tried the open
source MySQL .NET driver yet, but it looks very promising (and hopefully
speedier than MySQL ODBC).
</quote>
You should also crosscheck data type compatibility.
Peter [MVP Visual Developer]
Jack of all trades, master of none.
|||On Mon, 21 Mar 2005 00:05:35 GMT, claw wrote:
>I have a Windows XP application that uses MSDE as its DB engine. If I
>create an identical database in MySQL and include the correct ODBC
>"driver", is it be possible to replace MSDE with MySQL?
>What does it take for them to be compatible? After all both engines
>process SQL commands.
Hi Alex,
In addition to Peter's reply, here are some other things to consider.
SQL is a highly standardized language. The ANSI standard is based on
SQL-92; the later standards SQL-99 and SQL-2003 (IIRC) are not (yet?)
adopted by ANSI. However, it is entirely up to the manufacturers to
decide to what extend they want to adhere to the standards.
MSDE is quite close to SQL-92 - most, but not all features of SQL-92 are
available. In addition, MSDE also offers a wagonload of proprietary
extra features. While these features can make programs easier to write
and maintain and faster to executed, they will also limit portability.
If the program you are using uses many of these prorietary features,
then it is quite unlikely that it will run without modification on any
other database.
I'm not sure about MySQL, since I have no experience with it. But I've
read lots of comments indicating that MySQL is not very close to the
standards. I've never attempted to verify these comments, though. But if
they're true, then switching from MSDE to MySQL might prove to be very
hard.
Another issue is that some parts of SQL are not very standardised yet.
Procedural code, for instance, like triggers or stored procedures. Or
the declaration of supporting indexes - the options available are often
tied closely to the architecture of the database; some options available
for indexes on MSDE make sense only in the context of the mechanics of
how tables and indexes are stored in MSDE.
If you have no access to the source of the application and you can't
change the exact queries submitted, then I don't think you'll succeed.
SQL being a standardized and portable language does not imply that you
can just plug any database into an application and expect it to run.
What it does mean, is that *IF* the application is written with
portability in mind, it can be adapted to a new database with only
minimal changes.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||It takes quite a lot. MySQL has no stored procedures, and only the last
version has foreign keys. Then there is the following:
http://sql-info.de/mysql/gotchas.html
1.13 is a special favourite of mine...
Jacco Schalkwijk
SQL Server MVP
"claw" <claw@.hotmail.com> wrote in message
news:2005032101053516807%claw@.hotmailcom...
>I have a Windows XP application that uses MSDE as its DB engine. If I
>create an identical database in MySQL and include the correct ODBC
>"driver", is it be possible to replace MSDE with MySQL?
> What does it take for them to be compatible? After all both engines
> process SQL commands.
> Thanks for any input.
> - Alex
Subscribe to:
Posts (Atom)