Slow Execution Performance

#1

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!

#2

Ben (pillars4 (AT) sbcglobal (DOT) net) writes:

Quote:

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.

Quote:

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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

#3

Regarding the optimizer, is that an official information?

"Erland Sommarskog" <esquel (AT) sommarskog (DOT) se> wrote

Quote:

Ben (pillars4 (AT) sbcglobal (DOT) 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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

#4

Ben (pillars4 (AT) sbcglobal (DOT) net) writes:

Quote:

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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

#5

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" <esquel (AT) sommarskog (DOT) se> wrote

Quote:

Ben (pillars4 (AT) sbcglobal (DOT) 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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

#6

Ben (pillars4 (AT) sbcglobal (DOT) net) writes:

Quote:

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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

#7

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" <esquel (AT) sommarskog (DOT) se> wrote

Quote:

Ben (pillars4 (AT) sbcglobal (DOT) 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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

#8

Ben (pillars4 (AT) sbcglobal (DOT) net) writes:

Quote:

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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

#9

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" <esquel (AT) sommarskog (DOT) se> wrote

Quote:

Ben (pillars4 (AT) sbcglobal (DOT) 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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

#10

Ben (pillars4 (AT) sbcglobal (DOT) net) writes:

Quote:

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 (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx