February 3, 2013 at 3:50 am
Comments posted to this topic are about the item Capturing Baselines on SQL Server: Wait Statistics
February 4, 2013 at 1:49 am
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
February 4, 2013 at 6:54 am
_Beetlejuice (2/4/2013)
Hi ErinNice 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
February 4, 2013 at 7:39 am
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.
February 4, 2013 at 7:43 am
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.
February 4, 2013 at 11:09 am
Excellent series Erin - thanks for contributing.
December 30, 2014 at 6:51 pm
Found "Waits and Queues" article by Tom Davidson here:
July 18, 2015 at 4:11 am
Excellent work.....
April 27, 2016 at 2:27 pm
Thanks for this article!
- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
April 27, 2016 at 2:30 pm
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 asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply