SSC Clinic: Finding the rogue query

  • 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 RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • 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

  • 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 RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • "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.

  • 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.

  • 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.

  • 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/

  • 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 RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • Good article.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply