Storing Wait Stats In tempdb

Max Vernon has a script which loads a bunch of wait stats definitions and then collects wait stat details:

Performance troubleshooting should begin with capturing wait stats so we can understand where SQL Server is busy. The script below captures wait stats into a table in tempdb; the script should be ran via a SQL Server Agent job or some other scheduling mechanism.

I like the definitions that Max provides.  My only recommendation would be to store this data someplace a bit more permanent than tempdb.

Related Posts

Tips On Running SQL Server In RDS

Matthew McGiffen shares some tips on running SQL Server in Amazon RDS: Or you can go with Amazon RDS (Relational Database Service).¬† This is more of a managed service where Amazon looks after some aspects of your database server for you. In return you give up some of the control you would have with your […]

Read More

Disabling SQL Agent Jobs For Maintenance Periods

Jon Shaulis shows us a way to disable SQL Agent jobs with T-SQL: A user had a unique issue where their system would have dynamically changing job names and schedules, but they need to disable and re-enable them during maintenance.¬†Obviously, this is a huge headache.I made a recommendation that they should ultimately create a list […]

Read More

1 Comment

  • Max Vernon on 2018-08-14

    Generally, I agree with the recommendation of storing wait-stats data in a more permanent place than tempdb. My script uses tempdb since tempdb exists everywhere and doesn’t require the user to create a new database. Even though the data will be deleted on instance restart, this at least lets you see what happened every 5 minutes since the last server startup.

Comments are closed

Categories

August 2018
MTWTFSS
« Jul Sep »
 12345
6789101112
13141516171819
20212223242526
2728293031