Performance Tuning with SQL Server Dynamic Management Views

Chapter 6: Physical Disk Statistics and Utilization
a SAN with many other users, or someone is serving web pages from the same physical
drives as your database.
We also briefly discussed the use of the sys.dm_io_pending_io_requests DMV to
see currently pending I/O requests, i.e. to view how much data is currently in the I/O
pipeline to be processed by SQL Server but, for some reason, has not been consumed.
Next, we demonstrated two methods of finding the read:write ratio at the file, database,
or table level. This information is invaluable when determining, for example, the most
appropriate RAID configuration for a given disk (RAID 10 for frequently updated data,
RAID 5 for read-only data, and so on). We saw how the value for this ratio could vary
dramatically, depending on whether it was based on the amount of data being read or
written to disk, or on the number of individual read/write operations. If you see a value of
99:1 in terms of amount of data, but 40:60 in terms of the number of operations, it means
that your queries are reading way too much data, and you have some tuning work to do.
Finally, we covered the sys.dm_db_file_space_usage DMV, and used it to
investigate tempdb space usage, an understanding of which is critical since, in SQL
Server 2005 and 2008, tempdb is central to so much of the query activity on your server.
If you are a newbie to performance tuning from a disk I/O perspective, I know that you
are thinking, "Disk I/O tuning is hard!" and that is completely true. In all but the most
talented shops, it is a very common practice to guess high and buy too much hardware
for small applications, and guess way too low for very active applications. The goal of this
chapter and, in fact, the whole book is to help you understand the tools that are available
to help you to reach the "right" solution.
261