Slow Execution Performance

Hi all!

Several weeks ago, we successfully transferred our database from SQL Server
2000 to 2005. Below are our steps in transferring the database from 2000 to
2005:

a) Backuped our SQL Server 2000 database
b) Created an empty database in SQL Server 2005
c) Restored our SQL Server 2000 database to the empty SQL Server 2005
database

At first, after the transfer, all functions of the MS Access 2003
application went very
slow. Once I performed the update statistics, the speed of all the
functions went back to normal except for some. This is what is causing me
headaches right now - these functions that are still slow because all
functions worked fine in the SQL Server 2000. I did not change any code.

Each workstation is using the SQL Server 2005 ODBC driver.

Below is the issue that needs to be solved:
1) Some functionalities take so long to execute or finish executing.
examples:
a) "Find" function - After finding the specific customer number
or phone number
and clicking the "Done" button, which should take the user
back to the customer
form, it takes like 3 to 6 seconds wherein before it took
only 1-2 seconds.

b) "Sales Order" form - After clicking the "Done" button, which
would take the user
back to the main menu, it takes from 4 - 9 seconds to
finish. Before it took only
1-2 seconds.

Below are the things that I have tried so far, which did not work:
1) Rebuilt all the indexes
2) Took out the "Refresh" lines that were not needed in the app code
3) Set the compatibility level from 80 to 90
4) Dropped the "dtproperties" system table, which are not being used
anymore in SQL Server 2005

Any ideas would be great! Thanks!

Re: Slow Execution Performance

Ben (pillars4@sbcglobal.net) writes:
> a) Backuped our SQL Server 2000 database
> b) Created an empty database in SQL Server 2005
> c) Restored our SQL Server 2000 database to the empty SQL Server 2005
> database

Not that it's a big deal, but step b was not needed. RESTORE will
create the database if it does not exist.

> Below are the things that I have tried so far, which did not work:
> 1) Rebuilt all the indexes
> 2) Took out the "Refresh" lines that were not needed in the app code
> 3) Set the compatibility level from 80 to 90
> 4) Dropped the "dtproperties" system table, which are not being used
> anymore in SQL Server 2005
>
> Any ideas would be great! Thanks!

You will need to analyse the query plans for these slow queries to see
what is slow in them. If possible compare the query plans to what you had
in SQL 2000. Maybe you need to improve your indexing, maybe the queries
needs tweaking.

You can examine the query plan by running the query from Mgmt Studio
with Show Execution Plan enabled. You can also use Profiler and catpure
the Performance:Showplan XML event. This is particularly useful, if
it's difficult to extract the query from the application.

So why do these queries perform worse with SQL 2005? Well, an optimizer
is a guessing game. From statistics sampled about the data, the optimizer
makes an estimation what is the best query plan. Each new version of
SQL Server comes with new neat tricks in the optimizer, but there always
queries where these improvements backfire.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

Regarding the optimizer, is that an official information?

"Erland Sommarskog" wrote in message
news:Xns99D4EEC7CD33Yazorman@127.0.0.1...
> Ben (pillars4@sbcglobal.net) writes:
>> a) Backuped our SQL Server 2000 database
>> b) Created an empty database in SQL Server 2005
>> c) Restored our SQL Server 2000 database to the empty SQL Server 2005
>> database
>
> Not that it's a big deal, but step b was not needed. RESTORE will
> create the database if it does not exist.
>
>> Below are the things that I have tried so far, which did not work:
>> 1) Rebuilt all the indexes
>> 2) Took out the "Refresh" lines that were not needed in the app code
>> 3) Set the compatibility level from 80 to 90
>> 4) Dropped the "dtproperties" system table, which are not being used
>> anymore in SQL Server 2005
>>
>> Any ideas would be great! Thanks!
>
> You will need to analyse the query plans for these slow queries to see
> what is slow in them. If possible compare the query plans to what you had
> in SQL 2000. Maybe you need to improve your indexing, maybe the queries
> needs tweaking.
>
> You can examine the query plan by running the query from Mgmt Studio
> with Show Execution Plan enabled. You can also use Profiler and catpure
> the Performance:Showplan XML event. This is particularly useful, if
> it's difficult to extract the query from the application.
>
> So why do these queries perform worse with SQL 2005? Well, an optimizer
> is a guessing game. From statistics sampled about the data, the optimizer
> makes an estimation what is the best query plan. Each new version of
> SQL Server comes with new neat tricks in the optimizer, but there always
> queries where these improvements backfire.
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx
>

Re: Slow Execution Performance

Ben (pillars4@sbcglobal.net) writes:
> Regarding the optimizer, is that an official information?

I'd say it's general information that applies to about any database product
on the market. Not that I know very much about the optimizer in, say,
Oracle. But I saw a post the other day that discussed Teradata, and it was
amazingly familiar.



--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

By the way, I noticed one thing:

If I run the MS Access in the server computer itself, the slow performance
issues are not visible. But then again the hardware has two Intel Quad-Core
Xeon processors, 10GB of RAM, and 15,000RPM SATA hard drives. I just wanted
to point it out here maybe it tells something. I am still leaning towards
network connection problem or ODBC configuration.

It is still very slow.


"Erland Sommarskog" wrote in message
news:Xns99D55F472EB07Yazorman@127.0.0.1...
> Ben (pillars4@sbcglobal.net) writes:
>> Regarding the optimizer, is that an official information?
>
> I'd say it's general information that applies to about any database
> product
> on the market. Not that I know very much about the optimizer in, say,
> Oracle. But I saw a post the other day that discussed Teradata, and it was
> amazingly familiar.
>
>
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

Ben (pillars4@sbcglobal.net) writes:
> By the way, I noticed one thing:
>
> If I run the MS Access in the server computer itself, the slow
> performance issues are not visible. But then again the hardware has two
> Intel Quad-Core Xeon processors, 10GB of RAM, and 15,000RPM SATA hard
> drives. I just wanted to point it out here maybe it tells something. I
> am still leaning towards network connection problem or ODBC
> configuration.

If the operation is running decently fast if you have the client on
the server machine, then it does not seem that the problem is with the
query execution.

As for ODBC configuration, check that ODBC tracing is not enabled.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

An update on this issue, I am still experiencing this slowness problem. I
have tried from executing the maintenance processes, to checking the codes
of the MS Access 2003 application.

One new thing that we found is that if we access the MS Access application
from one of the workstations via remote desktop, the speed is very fast.
So, I do not know what is the relationship between remote desktop, the
network, and SQL Serve 2005 and the application being faster or accessing
the database faster.

Does anyone have an idea?


"Erland Sommarskog" wrote in message
news:Xns99D66F729C5F1Yazorman@127.0.0.1...
> Ben (pillars4@sbcglobal.net) writes:
>> By the way, I noticed one thing:
>>
>> If I run the MS Access in the server computer itself, the slow
>> performance issues are not visible. But then again the hardware has two
>> Intel Quad-Core Xeon processors, 10GB of RAM, and 15,000RPM SATA hard
>> drives. I just wanted to point it out here maybe it tells something. I
>> am still leaning towards network connection problem or ODBC
>> configuration.
>
> If the operation is running decently fast if you have the client on
> the server machine, then it does not seem that the problem is with the
> query execution.
>
> As for ODBC configuration, check that ODBC tracing is not enabled.
>
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

Ben (pillars4@sbcglobal.net) writes:
> An update on this issue, I am still experiencing this slowness problem. I
> have tried from executing the maintenance processes, to checking the codes
> of the MS Access 2003 application.
>
> One new thing that we found is that if we access the MS Access application
> from one of the workstations via remote desktop, the speed is very fast.
> So, I do not know what is the relationship between remote desktop, the
> network, and SQL Serve 2005 and the application being faster or accessing
> the database faster.
>
> Does anyone have an idea?

Maybe you should involve people in the Access forums as well in case this is
an Access issue?

Given the low level of information you have provided, there is not really
much more to say from the SQL Server side. But I would recommend that you
investigate he query plans, and confirm that they are identical in all
cases.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

The main problem in this issue was the packet size. The packet size setting
of SQL Server 2005 required it to be increased. So, after the update
statistics and reindexing, the packet size just had to be increased and that
solved the slowness problem.


"Erland Sommarskog" wrote in message
news:Xns99D85ED284201Yazorman@127.0.0.1...
> Ben (pillars4@sbcglobal.net) writes:
>> An update on this issue, I am still experiencing this slowness problem.
>> I
>> have tried from executing the maintenance processes, to checking the
>> codes
>> of the MS Access 2003 application.
>>
>> One new thing that we found is that if we access the MS Access
>> application
>> from one of the workstations via remote desktop, the speed is very fast.
>> So, I do not know what is the relationship between remote desktop, the
>> network, and SQL Serve 2005 and the application being faster or accessing
>> the database faster.
>>
>> Does anyone have an idea?
>
> Maybe you should involve people in the Access forums as well in case this
> is
> an Access issue?
>
> Given the low level of information you have provided, there is not really
> much more to say from the SQL Server side. But I would recommend that you
> investigate he query plans, and confirm that they are identical in all
> cases.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

Ben (pillars4@sbcglobal.net) writes:
> The main problem in this issue was the packet size. The packet size
> setting of SQL Server 2005 required it to be increased. So, after the
> update statistics and reindexing, the packet size just had to be
> increased and that solved the slowness problem.

Interesting. I have not heard of anything related to packet size before.
Thanks for the update!

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

What do you mean?

"Erland Sommarskog" wrote in message
news:Xns99DAF20685204Yazorman@127.0.0.1...
> Ben (pillars4@sbcglobal.net) writes:
>> The main problem in this issue was the packet size. The packet size
>> setting of SQL Server 2005 required it to be increased. So, after the
>> update statistics and reindexing, the packet size just had to be
>> increased and that solved the slowness problem.
>
> Interesting. I have not heard of anything related to packet size before.
> Thanks for the update!
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

Ben (pillars4@sbcglobal.net) writes:
> What do you mean?

What I meant? I expressed my thanks that you took the time to report
that your issue was resolved and how it was resolved.

I also expressed my surprise at the resolution. It was not one that I
would think of myself. Which does not mean that resolution was incorrect
or anything. I am only happy to learn from other people's experiences.




--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

I understand.

I just had to ask cause I wanted to know your input on that. I am still in
the observation state. Personally, I have always set the settings to
default unless it is really, badly necessary to change it. As I did with
SQL Server 2000. That is why I did not think of the packet size that it
needs tweaking. In SQL Server 2000 the packet size was set to zero. I am
assuming that this was the default value, which meant that the packet size
will grow or shrink as needed by SQL Server 2000. I checked the setting in
SQL Server 2005 and the default was 4 KB. Looks like they changed it
indeed.



"Erland Sommarskog" wrote in message
news:Xns99DBEC96A5A74Yazorman@127.0.0.1...
> Ben (pillars4@sbcglobal.net) writes:
>> What do you mean?
>
> What I meant? I expressed my thanks that you took the time to report
> that your issue was resolved and how it was resolved.
>
> I also expressed my surprise at the resolution. It was not one that I
> would think of myself. Which does not mean that resolution was incorrect
> or anything. I am only happy to learn from other people's experiences.
>
>
>
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx

Re: Slow Execution Performance

Ben (pillars4@sbcglobal.net) writes:
> I just had to ask cause I wanted to know your input on that. I am still
> in the observation state. Personally, I have always set the settings to
> default unless it is really, badly necessary to change it. As I did
> with SQL Server 2000. That is why I did not think of the packet size
> that it needs tweaking. In SQL Server 2000 the packet size was set to
> zero. I am assuming that this was the default value, which meant that
> the packet size will grow or shrink as needed by SQL Server 2000. I
> checked the setting in SQL Server 2005 and the default was 4 KB. Looks
> like they changed it indeed.

I looked on two SQL 2000 instances, and they have a network packet size of
4096, and as I recall this is also default. Also, according sp_configure,
the minumum packet size is 512, not 0. I have never heard of any dynamic
packet size. It is however for an application to require a different
packet size when it connects.

Maybe someone did a tweak to the packet size on your SQL 2000 a long time
ago, and no one no longer recalls that it ever happened.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downlo ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books .mspx