- SQL Server has artificial intelligence built in and wants to annoy the developers and DBAs by randomly changing execution plans for the query to make it slow and have developers and DBAs spend extra hours trying to optimize it.
- SQL Server has artificial intelligence built in and has a bias toward SQL Server performance ocnsulting. Since the rates dropped somewhat it decided it will torture full-time employees until they will hire a consultant with a decent rate.
- This behaviour was a part of SP4 and was designed to annoy developers and DBAs so they will upgrade to SQL Server 2005 as soon as possible, thus generating much-needed revenue for Microsoft.
Wednesday, August 30, 2006
So why does SQL server change execution plan?
Well, some hypotheses:
Friday, August 25, 2006
Why does SQL server always change execution plan?
I just don't get it why does SQL server always changes execution plan.
I run
EXEC sp_MSforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
and still cannot get the same execution plan as the last time. I don't think any data were changed since a few weeks ago. And why does the SQL server all the sudden start usign hash or merge joins and try to use parallelism? I worked a couple of days ago to optimize the query and I've got it down to 71 milliseconds. Today it is back to 600 ms. Is the solution to use the real database, for example Oracle?
I run
EXEC sp_MSforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
and still cannot get the same execution plan as the last time. I don't think any data were changed since a few weeks ago. And why does the SQL server all the sudden start usign hash or merge joins and try to use parallelism? I worked a couple of days ago to optimize the query and I've got it down to 71 milliseconds. Today it is back to 600 ms. Is the solution to use the real database, for example Oracle?
Subscribe to:
Posts (Atom)