Query exec time of 2005 vs. 2000.

Greetings. We are going to begin moving our 2000 DB's to 2005 shortly and I
was wondering about performance. From reading a few posts here, some claim
that 2005 is showing slower performance than 2000. After answering the
"update stats" question, they are then referred to the exec plans. From there
all correspondence stops, leaving guys like me to wonder the outcome.
So, have those of you that have made the move seen degraded performance in
query times (excluding needing to update the stats)? If so, what was
determined to be the issue? I have 70+ DB's to move, the idea of replaying
profiler traces to do speed comparisons for each one sounds tragic. As does
looking at lots of different exec plans after the move.
TIA, ChrisRChrisR,
As a best practice we always re-index, at least our Production, databases if
we are moving up a version, 2000 to 2005, or installing a new service pack.
This should update the stats and help get execution plans more geared to the
newer version.
What build of SQL2005 are you going to go to? The higher builds start to
look at the TokenAndPermUserStore memory as a problem. See this blog: -
http://sqlblogcasts.com/blogs/grumpyolddba/archive/2007/07/19/more-tokenandpermuserstore.aspx
MS are introducing cumulative hot fixes post SP2 build 3042 so watch for
these and the problems they have fixed: -
http://support.microsoft.com/kb/937137
Back to your original question as always a lot depends on your application
code and the hardware that you run with. HyperThreaded servers are still not
the best: -
http://sqlblog.com/blogs/kevin_kline/archive/2007/08/18/the-perils-of-hyperthreading-for-sql-server.aspx
Good luck
Chris
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:0CA05B48-E696-4EB5-A383-BDBACCD5546C@.microsoft.com...
> Greetings. We are going to begin moving our 2000 DB's to 2005 shortly and
> I
> was wondering about performance. From reading a few posts here, some claim
> that 2005 is showing slower performance than 2000. After answering the
> "update stats" question, they are then referred to the exec plans. From
> there
> all correspondence stops, leaving guys like me to wonder the outcome.
> So, have those of you that have made the move seen degraded performance in
> query times (excluding needing to update the stats)? If so, what was
> determined to be the issue? I have 70+ DB's to move, the idea of replaying
> profiler traces to do speed comparisons for each one sounds tragic. As
> does
> looking at lots of different exec plans after the move.
> TIA, ChrisR