Does running a SQL Server 2005 database in compatibility level 80 have a negative impact on performance?

Question

Our software must be able to run on SQL Server 2000 and 2005. To simplify development, we're running our SQL Server 2005 databases in compatibility level 80. However, database performance seems slower on SQL 2005 than on SQL 2000 in some cases (we have not confirmed this using benchmarks yet). Would upgrading the compatibility level to 90 improve performance on the SQL 2005 servers?

Answer 1

after you moved the DBs over to 2005 did you

update the stats with full scan? rebuilt the indexes?

first try that and then check performance again

Answer 2

Also a FYI, if you run compatibility level 90 then some things are not supported anymore like old style outer joins (*= and =*)

Answer 3

Are you using subselects in your queries?

From my experience, a SELECT statement with subselects that runs fine on SQL Server 2000 can crawl on SQL Server 2005 (it can be like 10x slower!).

Make an experiment - re-write one query to eliminate the subselects and see how its performance changes.

Answer 4

I think i read somewhere, that the SQL Server 2005 database engine should be about 30% faster than the SQL Server 2000 engine. It might be, that you have to run your database in compatibility mode 90 to get these benefits.

But i stumbled on two scenarios, where performance can drop dramatically when using mssql 2005 compared to mssql 2000:

1. Parameter Sniffing: When using a stored procedure, sql server will calculate exactly one execution plan at the time, you first call the procedure. The execution plan depends on the parameter values given for that call. In our case, procedures which normally took about 10 seconds are running for hours under mssql 2005. Take a look here and here.

2. When using distributed queries, mssql 2005 behaves different concerning assumptions about the sort order on the remote server. Default behavior is, that the server copies the whole remote tables involved in a query to the local tempdb and then execute the joins locally. Workaround is to use OPENQUERY, where you can control exactly which resultset is transferred from the remote server.