May 2, 2011 at 11:50 am
Prob solved by updating the stats
May 2, 2011 at 12:37 pm
Please post the execution plans as per
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
There are a fair few udf used there , remove those as see if performance improves.
UDFs (except inline table valued ones) perform poorly plus you wont see any cost associated to them in the execution plan.
May 2, 2011 at 12:44 pm
As Dave mentioned, please post the execution plans. The actuals by preference.
I noticed this: WHERE 1=1
This usually occurs when you're dealing with dynamic SQL builds. It looks like you're trying to troubleshoot one iteration of the call. What other background can you give us on this? Also, any chance you can provide the table DDL? It'll help us analyze the indexes in use.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
May 2, 2011 at 3:33 pm
Without the execution plan the only thing that really leaps out at my eye is the use of DISTINCT in the derived tables. That can frequently be a crutch for inapropriate joins or bad data. It's an aggregate function, so it's quite costly for performance. But that's all I can see in a quick scan. The execution plan (actual please) will help.
"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
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply