September 13, 2012 at 12:03 am
Comments posted to this topic are about the item SSC Clinic: Finding the rogue query
"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
September 13, 2012 at 2:28 am
from the name of the table, I guess there is a considerable amount of records in it.
It looks like it, unneccessarily, computes the dateadd function for each row.
you might store the value in a variable
declare @yesterday smalldatetime = dateadd("d", -1, getdate())
and use it like
...
and date > @yesterday
September 13, 2012 at 6:03 am
Good suggestion. I haven't started tuning the query yet, but that's absolutely one of the changes I'll make. Thanks.
"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
September 13, 2012 at 6:45 am
"The measured average is only .4 at peaks around that time, so we're not looking at multiple processes fighting over the processor. That means one event is causing the problem."
How did you know it was only one event? Or that it wasn't multiple processes?
Thanks.
September 13, 2012 at 8:36 am
Where are those analysis pages coming from? Is it a feature in SQL activity monitor? If so, please advice the proper steps to do what you show. If you are using a tool to build sll that, let me know what u use.
September 13, 2012 at 9:20 am
tolga.kurkcuoglu (9/13/2012)
from the name of the table, I guess there is a considerable amount of records in it.It looks like it, unneccessarily, computes the dateadd function for each row.
you might store the value in a variable
declare @yesterday smalldatetime = dateadd("d", -1, getdate())
and use it like
...
and date > @yesterday
I doubt that that will make any difference. I'd be very surprised if the engine calls the dateadd function more than once. In the optimization phase it will do what you suggest. It just won't tell you about it.
September 13, 2012 at 10:46 am
Check the stats on the table.
Look at execution plan for bootlenecks/scans etc
Veryify order of Where parameters works to effectively
Check the indexes for existence and fragmentation.
Definitely pre calc the date comparision.
If stored procedure then after verifying stats are up to date then I'd do an sp_recompile on the sProc
Much to learn, teach me Yoda
Tom in Sacramento - For better, quicker answers on T-SQL questions, click on the following...http://www.sqlservercentral.com/articles/Best+Practices/61537/
September 14, 2012 at 6:02 am
OceanDeep (9/13/2012)
Where are those analysis pages coming from? Is it a feature in SQL activity monitor? If so, please advice the proper steps to do what you show. If you are using a tool to build sll that, let me know what u use.
It's all from Red Gate SQL Monitor. You can see it in action against SQL Server Central here at monitor.red-gate.com
"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
December 25, 2012 at 8:41 am
Good article.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply