Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Query plan changes over time, query performance severely impacted Expand / Collapse
Author
Message
Posted Monday, July 8, 2013 2:26 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, July 17, 2014 2:40 AM
Points: 56, Visits: 442
i see what you mean now, thanks for that what on earth could be causing the optimiser to take ten minutes and only then timeout! ridiculous. hopefully cumulative update will sort this, it can't be normal behaviour.
Post #1471364
Posted Tuesday, July 9, 2013 1:10 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, July 17, 2014 2:40 AM
Points: 56, Visits: 442
Sorted! Your comments led me to the following website, I couldn't understand why the query was taking so long, and then timing out.

http://mssqlwiki.com/2012/10/07/optimizer-timeout-or-optimizer-memory-abort/

quote from the site below

"We can avoid optimizer from timing out and picking bad plan by enabling trace flag -T8780. This increases the time limit before the timeout occurs."

I decided to give this a shot today and guess what, that global trace flag was already on! I certainly didn't start it but my guess it is it is off when the service is restarted, and something is turning this trace flag on. I turned it off and hey presto, sql gives up finding the best plan quickly and runs the query in a couple of seconds.

I am currently running a trace to catch anything that turns this global trace flag on.

Thanks again, I would not have cracked it with your comments.
Post #1471811
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse