query plan issues
-
has anyone else seen issues in estimated (and occasionally actual) query plans ?
I can't really run some of the procs I have without doing a begin tran/rollback tran combination - and the ones i'm trying to fix can take up to half an hour...
so looking at the plan, there are sections of it where the cost is maybe 33% but there are maybe 10 nodes in the plan that have 33% which makes no sense - that means 330% (i'm picking random figures here)
I normally start performance tuning by going to the top right operation on the plan and then keep hunting left and then scrolling back and down until I find something I don't like (like a remote scan, index scan, bookmark lookup or a function call) - it's a pain in the bum if the % value are all the same... makes it hard to prioritise quick fixes (like a missing index)
anyone else seen this ?
MVDBA
-
Does the plan go parallel?
😎
The cost aggregation has never been proper or accurate, something that M$ needs to work on 😉
-
I haven't factored in the parallelism issue so far - but yes, a lot of the time "part" of the plan goes parallel, I was kinda thinking it might have been related to linked servers - before you ask... you do not want to see the query plan... i'm just attacking it a bit at a time, but here is an example of where "part" of it goes parallel.
I did not write this code, i'm just trying to fix it - and yes I can see the index scan and the key lookup... I hate legacy code, I hate functions, I hate cursors, I hate code that has been bodged for 10 years without a DBA around to get 3nf
MVDBA
-
I'm not kidding about the plan by the way - I picked the 2 main elements and set them to fit to screen
MVDBA
- MVDBA (Mike Vessey) wrote:
before you ask... you do not want to see the query plan...
Now you've said that, we want to see the query plan.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply