July 31, 2015 at 12:37 pm
We have a stored procedure.It has a select query and its taking long time.I have attached the image of select query,image of actual execution plan and image of index scan details.The index scan is costing 80%
Please help on what to do so that the query gets tuned.
July 31, 2015 at 12:46 pm
That doesn't help a lot. You should post DDL for the tables, views and indexes involved and actual execution plan (right click on the execution plan and Save As...).
The index scan might be the issue or it might not. It's very possible that the problem is the remote query.
One thing is sure, the NOLOCK hints are not helping with performance.
July 31, 2015 at 1:01 pm
Thanks for the reply. I had attached the execution plan in my previous post.
July 31, 2015 at 1:10 pm
coolchaitu (7/31/2015)
Thanks for the reply. I had attached the execution plan in my previous post.
No, you didn't. You attached an image of the execution plan which isn't the same thing as lots of information is lost.
Read the following article to post performance problems: http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
August 2, 2015 at 7:57 am
Please post the query, table definitions, index definitions and the actual execution plan. Without those it's near-impossible to offer any useful advice.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 2, 2015 at 8:19 am
it seems your using OPENquery in the select statement , what kind of performance does the second server have , are the two machines on the same network?
have you tried running the two parts of the query one by one , the inner table looks like its fecthing .5 M rows how long does it take on its own?
August 2, 2015 at 8:21 am
Piling on Luis's and Gail's posts, withholding or piecemeal'ing any relevant information is a waste of everybody's time! From the limited information supplied so far, one question arises, how are the indices and the statistics maintained? By the looks of it the statistics are stale, mind you that with out the full info this is just a wildcard guess, but seeing the estimate of 55 rows and actual number of rows roughly 1100 times greater is a hint.
😎
August 2, 2015 at 8:33 am
Eirikur Eiriksson (8/2/2015)
Piling on Luis's and Gail's posts, withholding or piecemeal'ing any relevant information is a waste of everybody's time! From the limited information supplied so far, one question arises, how are the indices and the statistics maintained? By the looks of it the statistics are stale, mind you that with out the full info this is just a wildcard guess, but seeing the estimate of 55 rows and actual number of rows roughly 1100 times greater is a hint.😎
Eirikur, did you confused the estimated I/o cost with the estimated rows?
August 2, 2015 at 8:38 am
Luis Cazares (8/2/2015)
Eirikur Eiriksson (8/2/2015)
Piling on Luis's and Gail's posts, withholding or piecemeal'ing any relevant information is a waste of everybody's time! From the limited information supplied so far, one question arises, how are the indices and the statistics maintained? By the looks of it the statistics are stale, mind you that with out the full info this is just a wildcard guess, but seeing the estimate of 55 rows and actual number of rows roughly 1100 times greater is a hint.😎
Eirikur, did you confused the estimated I/o cost with the estimated rows?
:blush: Spot on Luis, my bad
😎
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply