Capturing Baselines on SQL Server: Wait Statistics

  • Erin Stellato

    Ten Centuries

    Points: 1176

    Comments posted to this topic are about the item Capturing Baselines on SQL Server: Wait Statistics

  • _Beetlejuice

    Ten Centuries

    Points: 1004

    Hi Erin

    Nice article. I have a question relating to clearing the wait statistics on an instance. On my production Servers, I capture the wait statistics every hour, as soon as I have inserted the previous hours wait statistics into the table I then clear the wait statistics. I believe that this gives me a good indication on an hourly basis of the waits on a server. Question I have though is - will I get more benefit (in terms of more accurate data for a baseline) by capturing only once a day (after backups, maintenance etc) or is it ok to leave things as they are now and capture and clear every hour.

    Chris

  • Erin Stellato

    Ten Centuries

    Points: 1176

    _Beetlejuice (2/4/2013)


    Hi Erin

    Nice article. I have a question relating to clearing the wait statistics on an instance. On my production Servers, I capture the wait statistics every hour, as soon as I have inserted the previous hours wait statistics into the table I then clear the wait statistics. I believe that this gives me a good indication on an hourly basis of the waits on a server. Question I have though is - will I get more benefit (in terms of more accurate data for a baseline) by capturing only once a day (after backups, maintenance etc) or is it ok to leave things as they are now and capture and clear every hour.

    Chris

    Hi Chris-

    Thanks for reading and for your comment! I don't think you need to change your strategy to get more of a benefit. I'd be interested in knowing whether anyone else employs a similar method of capture - specifically clearing them every hour. Have you been able to use those hour snapshots to correlate the waits back to a problem? And, do you find that when a problem does occur on the server, the hour snapshots point you in the right direction?

    Thanks!

    Erin

  • mtassin

    SSC-Insane

    Points: 23096

    There is an option 4 on wait states (at least)

    1. Capture the wait stats every 15 minutes

    2. Store the current captured value into a staging table

    3. Calculate the differences in Wait Stats between the current capture and the previous one

    4. Store the differences

    5. Never clear wait stats at all. Instead add a job that runs at instance start up that clears the staging table and replaces the values in it with all zeros.

    Put those into a nice Tabular model in SQL 2012 or a Powerpivot in SQL 2008R2 and you can analyze with 15 minute rollups to half hours and hours. It's interesting to see your wait states across a given day.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • mtassin

    SSC-Insane

    Points: 23096

    Erin Stellato (2/4/2013)


    Hi Chris-

    Thanks for reading and for your comment! I don't think you need to change your strategy to get more of a benefit. I'd be interested in knowing whether anyone else employs a similar method of capture - specifically clearing them every hour. Have you been able to use those hour snapshots to correlate the waits back to a problem? And, do you find that when a problem does occur on the server, the hour snapshots point you in the right direction?

    I've managed to put my 15 minute windows to use troubleshooting a weird CMEMTHREAD wait that crops up every day at 3:30am. Haven't come up with a solution once I tracked it down by creating a trace to run between 3:15am and 3:45am and realized it as an SSIS job that was shredding tens of thousands of xml log files though. But at least I know what it is.

    I've tried tweaking that particular SSIS package seven ways to sunday, but I've come to the sad conclusion that SSIS and xml just equals CMEMTHREAD waits.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • tim_harkin

    SSCrazy

    Points: 2392

    Excellent series Erin - thanks for contributing.

  • Mark_Kimsey

    SSC Enthusiast

    Points: 124

    Found "Waits and Queues" article by Tom Davidson here:

    http://technet.microsoft.com/library/Cc966413

  • Kalegley

    Old Hand

    Points: 328

    Excellent work.....

  • webrunner

    One Orange Chip

    Points: 29945

    Thanks for this article!

    - webrunner

    -------------------
    A SQL query walks into a bar and sees two tables. He walks up to them and says Can I join you?
    Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

  • webrunner

    One Orange Chip

    Points: 29945

    mtassin (2/4/2013)


    There is an option 4 on wait states (at least)

    1. Capture the wait stats every 15 minutes

    2. Store the current captured value into a staging table

    3. Calculate the differences in Wait Stats between the current capture and the previous one

    4. Store the differences

    5. Never clear wait stats at all. Instead add a job that runs at instance start up that clears the staging table and replaces the values in it with all zeros.

    Put those into a nice Tabular model in SQL 2012 or a Powerpivot in SQL 2008R2 and you can analyze with 15 minute rollups to half hours and hours. It's interesting to see your wait states across a given day.

    Hello Mark,

    Thanks for your suggestion of an option 4. I have a related question.

    I just found and ran some code to store my SQL Server's wait stats to a table. It logged 653 rows. Adding 653 rows every 15 minutes comes out, by my rough estimate, to 2,207,520 rows per year.

    Is that expected as far as you're concerned? I'd like to keep as much data as needed to be useful, but I am not sure all of those rows would be. And I want to know more before I start collecting the wait stats at that rate.

    Thanks for any help.

    - webrunner

    -------------------
    A SQL query walks into a bar and sees two tables. He walks up to them and says Can I join you?
    Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

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

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