Performance Tuning with SQL Server Dynamic Management Views

Chapter 6: Physical Disk Statistics and Utilization
A certain amount of physical I/O is inevitable. It will occur when data modifications,
written to the data cache in memory, need to be "hardened" to disk. The write-ahead
logging mechanism used by SQL Server means that the details of INSERT, UPDATE and
DELETE transactions are always first written to the transaction log (LDF) file on disk.
A data page that contains data that has been committed to the transaction log file but
not to the data (MDF) file is referred to as a "dirty page." A process called the "lazy writer"
manages the writing of dirty pages to physical disk when there is time, or when no more
data can be placed into the cache, while another process, called the "checkpoint" process,
makes sure the number of dirty pages is kept to a level such that, if you needed to recover
the database, a relatively small number of pages would need to be read from the log.
In addition, physical I/O will occur each time a requested data page is not found in the
data cache, and so needs to be first read into memory from the underlying disks. Logical
I/O is a less expensive operation than physical I/O, so the DBA will want as many queries
as possible to be served from the cache. This often means having as much RAM as can
be afforded, up to and perhaps slightly over the amount of data on the server. However,
this is frequently an unrealistic proposition. Even medium-sized organizations can store
hundreds of gigabytes of data, and their appetite for data is growing rapidly. While RAM
costs start out cheap, we aren't likely to have terabytes of cheap RAM any time soon.
While the focus of this chapter is disk (i.e. physical) I/O, it's worth remembering that
logical I/O, while cheaper, is far from free. Logical I/O occurs when a data request (read)
can be satisfied by serving up a page residing in memory, in the data cache. Writes are also
first written to the data cache, before later being written to disk. If your query workload
results in unnecessarily high logical I/O, then your performance will suffer. The best way
to ensure that as many data requests as possible are served from memory is to avoid all
unnecessary I/O. This means tuning the query workload so that each query returns the
minimum necessary data, reads the data as few times as possible, and uses solid, set-based
logic to manipulate the data set.
One of the most effective ways to minimize both logical and physical I/O is to create an
appropriate set of indexes, as discussed in Chapter 5. A scan of even a moderately-sized
table could easily result in reading 100,000 pages, even if you only need to return a small
219