Performance Tuning with SQL Server Dynamic Management Views

Chapter 7: OS and Hardware Interaction
DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);
Listing 7.1: Resetting the wait statistics.
If your SQL Server instance has been running for quite a while and you make a significant
change, such as adding an important new index, you might consider clearing the old wait
stats in order to prevent the old cumulative wait stats masking the impact of your change
on the wait times.
The following columns are available in the view (times are all in millisecond units):
• wait_type – the type of wait
• waiting_tasks_count – the cumulative total number of waits that have occurred
for the given wait_type
• wait_time_ms – total amount of time that tasks have waited on this given wait type;
this value includes the time in the signal_wait_time_ms column
• max_wait_time_ms – the maximum amount of time that a task has been delayed, for
a wait of this type
• signal_wait_time_ms – the total amount of time tasks took to start executing after
being signaled; this is time spent on the runnable queue, and is pure CPU wait.
There are many reasons why a certain task within SQL Server may need to wait before
proceeding, which means there are many possible values for the wait_type column.
Some are quite usual, such as the need to wait for a lock to be released before it can
access the required resource (e.g. a data page), and these are indicated by the "normal"
lock modes such as shared, intent, exclusive, and so on (see Chapter 4, Transactions,
for more detail). Other common causes of waits include latches, backups, external
operations like extended stored procedure execution, replication, resource semaphores
(used for memory access synchronization), and many more. There are too many to
cover them all in detail, though most of the wait types are at least listed, if not well
documented, in Books Online.
266