Performance Tuning with SQL Server Dynamic Management Views

109
Chapter 3: Query Plan Metadata
Depending on what columns we include, and which column we order by, we can
discover which cached stored procedures are the most expensive from several different
perspectives. In this case, we are interested in finding out which stored procedures are
generating the most total logical reads (which relates to memory pressure). This query is
especially useful if there are signs of memory pressure, such as a persistently low page life
expectancy and/or persistent values above zero for memory grants pending. This query is
filtered by the current database, but we can change it to be instance-wide by removing the
WHERE clause.
Simply by selecting the total_physical_reads column, instead of total_logical_
reads in this query, we can perform the same analysis from the perspective of physical
reads, which relates to read, disk I/O pressure. Lots of stored procedures with high total
physical reads or high average physical reads, could indicate severe memory pressure,
causing SQL Server to go to the disk I/O subsystem for data. It could also indicate lots of
missing indexes or "bad" queries (with no WHERE clauses, for example) that are causing
lots of clustered index or table scans on large tables.
Be aware, though, that there are a couple of caveats with these queries. The big one is
that you need to pay close attention to the cached_time column as you compare rows
in the result set. If you have stored procedures that have been cached for different periods
of time, this will skew the results. One easy, but perhaps controversial, solution to this
problem is to periodically clear your procedure cache, by running DBCC FREEPROCCACHE
with a SQL Agent job, as previously discussed.
The second caveat is that only cached stored procedures will show up in these queries.
If you are using WITH RECOMPILE or OPTION(RECOMPILE), which is usually not a good
idea anyway, then those plans won't be cached.