Performance Tuning with SQL Server Dynamic Management Views

Chapter 3: Query Plan Metadata
--Determine the id of your database
DECLARE @intDBID INTEGER
SET @intDBID = ( SELECT dbid
FROM master.dbo.sysdatabases
WHERE name = 'mydatabasename'
)
--Flush the procedure cache for your database
DBCC FLUSHPROCINDB (@intDBID)
Listing 3.1: Flushing the cache of plans belonging to a particular database.
The flushed plans will go back into the cache the next time they are executed, the result
being that most of the stored procedures that are run frequently and are part of your
normal workload will have a similar cache time. This will make the statistics much easier
to interpret (until and unless they get recompiled again for some other reason).
Flushing the cache is a controversial suggestion; many DBAs avoid doing it on a production
server. After all, clearing the cache means that new plans need to be determined and
created, which has an associated cost. It's true that recompiling all of the query plans will
cause some extra work for your processor(s), but many modern processors shrug this off
with little effect beyond a brief (few seconds) spike of CPU activity.
Viewing the Text of Cached Queries
and Query Plans
The root cause of many performance problems is the fact that the plan you get when
query execution is optimized under a full production server load can be very different
from the one you saw in Management Studio while building the query. For example, on
your development server, you may have only a single CPU, several orders of magnitude
fewer rows, different amounts of RAM, statistics that are completely up to date, fewer
concurrent users, and so on.
78