Performance Tuning with SQL Server Dynamic Management Views

Chapter 1: Using Dynamic Management Objects
Point-in-time versus cumulative data
We can query data held on the DMOs just as we would any other table, view, or function.
However, always remember that the data returned is "dynamic" in nature. It is collected
from a range of different structures in the database engine and represents, in the main, a
point-in-time "snapshot" of the activity that was occurring on the server at the time the
DMO query was executed.
Sometimes, this is exactly what is required; we have a performance issue right now, and
want to find out what sessions and queries are running, right now, on the server that
could be causing it. Bear in mind, though, that this point-in-time data can, and likely
will, change each time you query it, as the state of the server changes. You should expect
to occasionally see anomalous or non-representative results, and you may need to run a
script many times to get a true picture of activity on your instance.
Also, it is quite difficult to query the data in these point-in-time DMOs in the hope
that the problem will simply "jump out at you." If, for example, you have a performance
problem and you want to check for any "unusual" locking patterns, then it's unlikely
that a "select [columns] from [locking DMV]" will tell you much, unless you're already
very familiar with what "normal" locking looks like on your system, and you can therefore
easily spot anomalies.
In other cases, the DMOs are cumulative. In other words, the data in a given column is
cumulative and incremented whenever a certain event occurs. For example, every time
a session waits a period of time for a resource to become available, this is recorded in a
column of the sys.dm _ os _ wait _ stats DMV. When querying such a DMV, you
will be seeing, for instance, the total amount of time spent waiting for various resources,
across all sessions, since SQL Server was started or restarted. While this will give you a
broad overview of where time has been spent waiting, over a long period, it will make it
hard to see the smaller details. If you want to measure the impact of a certain change to
the database (a new index for example), you'll need to take a baseline measurement, make
the change, and then measure the difference.
26