Huge Records...

Question

Huge Records...

Viewing 2 posts - 16 through 16 (of 16 total)

You must be logged in to reply to this topic. Login to reply

Grant Fritchey SSC Guru Points: 398697 More actions · Answer 1

That's... a lot. I'm not going through all of it in detail. Summary: Tons of key lookup operations. Every one of those is probably hurting your performance. You need to look at the clustered indexes on the tables to be sure they're appropriate to how you're accessing data. Secondarily you can look at covering indexes on all that. Also, you've got a lot of disparity between estimated rows & actual rows. This could be caused by all the TVFs or it could be that your statistics are out of date. Instead of running sp_updatestats, try running UPDATE STATISTICS WITH FULL SCAN against the tables involved, see if that changes things.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

Jeff Moden SSC Guru Points: 1003872 More actions · Answer 2

ChrisM@home (10/26/2010)
hosseini.mehran (10/26/2010)
So what is your suggestion?
Post the whole query. Could a doctor diagnose a sore throat from looking at a single toe?

BWAA-HAA!!! If someone has their foot in their mouth, maybe. 😛

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)