SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Poor performing query on


Poor performing query on

Author
Message
cunningham
cunningham
Ten Centuries
Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)

Group: General Forum Members
Points: 1021 Visits: 856
mayurkb I switched parametrization to forced on the offending database, and now when I run the query (after it's initial 10 minute run into the cache), even if I change it slightly by adding/removing spaces it returns in seconds.

This is definitely a problem with the compilation of the query, but what would be causing this extra long compilation time, does compilation utilise CPU heavily? there are 8 cores on the server, but it is a virtual server, see any problems here?

The query takes seconds to compile on the test and current live servers.

Thanks for all your help in this guys, getting me on the right track i think.

Rich
mayurkb
mayurkb
SSC Veteran
SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)

Group: General Forum Members
Points: 213 Visits: 246
Glad I could help.
We were also having some CPU issues with our virtual servers running on vSphere. We did not see those issues while running on hyperv.
Also, keep in mind this is a short term solution. For long term solution, you will have to tune your query by fixing query, views and indexes.
cunningham
cunningham
Ten Centuries
Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)

Group: General Forum Members
Points: 1021 Visits: 856
update on this, restored the backups to another sql server with exactly the same OS and SQL server version and SP, and the query returns in seconds, even on the intial compile. So that's 3 servers handling the queries with ease, but the super awesome production server can't deal with it!

I can only think it's something in the configuration somewhere, Need to find why it is using a different execution plan on the slowly running server.
cunningham
cunningham
Ten Centuries
Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)

Group: General Forum Members
Points: 1021 Visits: 856
FYI, solved this by adding 7 extra tempdb files to match the 8 cores, then restarted the sql server. Now the query plans match exactly, and the query returns in no time.
cunningham
cunningham
Ten Centuries
Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)

Group: General Forum Members
Points: 1021 Visits: 856
just to let you know the tempdbs didn't sort it, the restart sorted it temporarily but then the issue returned. Eventually tracked it down to trace flag T8780 being turned on. This trace flag increases the timeime the optimiser can search for the best plan before a timeout occurs. Because the query was so complex this was taking 10minutes and STILL timing out.

I turned the trace flag off and the query now runs in seconds, all be it with a sub optimal plan.

Just need to figure out what is turning the trace flag on.
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (210K reputation)SSC Guru (210K reputation)SSC Guru (210K reputation)SSC Guru (210K reputation)SSC Guru (210K reputation)SSC Guru (210K reputation)SSC Guru (210K reputation)SSC Guru (210K reputation)

Group: General Forum Members
Points: 210499 Visits: 41973
First, thanks a bunch for the updates on this. We're getting close to doing the same thing (update) and this will help with some of the things to watch for

richard.austin (7/9/2013)
I turned the trace flag off and the query now runs in seconds, all be it with a sub optimal plan.


BWAAA-HAAA!!!! Considering what you just went through, I'm thinking that the sub optimal plan isn't so bad. :-D

--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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search