SQL Server Execution Plans - Red Gate Software

Chapter 1: Execution Plan Basics
see how the optimizer and storage engine created your plan. With DMVs and dynamic
management functions, we can easily put together a query to get a very complete set of
information about the execution plans on our system:
SELECT [cp].[refcounts] ,
[cp].[usecounts] ,
[cp].[objtype] ,
[st].[dbid] ,
[st].[objectid] ,
[st].[text] ,
[qp].[query_plan]
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) qp;
Listing 1.18
With this query, we can see the SQL and the XML plan generated by the execution of
that SQL. There are a number of different DMOs available. I used one, sys.dm_exec_
cached_plans, which shows properties about the object in the plan cache, but not the
plan, as the basis for this query. I then used the CROSS APPLY statement to access the two
dynamic management functions to retrieve the query from sys.dm_exec_sql_text
and the plan from sys.dm_exec_query_plan. The CROSS APPLY applies a function
once for every row in the result set. This query returns all queries from the cache as XML.
These plans that are stored in cache do not contain runtime information such as the
actual number of rows or actual number of executions. They are the estimated plans.
This makes them slightly less useful than the real plans (obtained from tools such as
Profiler) when you're doing detailed performance tuning because you can't see those
runtime values. However, the ability to immediately pull the plan straight out of cache is
incredibly useful, so this method is going to serve you well.
We can use the XML directly or open it as a graphical execution plan. Furthermore, information
available in the cache allows us to take more direct control over our execution
plans. For example, as was mentioned earlier, we can retrieve the plan_handle from the
52