Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 12: Stored Procedures
When a Good Sproc Goes Bad
Perhaps one of the most important things to recognize on the downside of sprocs is that, unless you
manually interfere (using the WITH RECOMPILE option), they are optimized based on either the first time
that they run or when the statistics have been updated on the table(s) involved in any queries.
That “optimize once, use many times” strategy is what saves the sproc time, but it’s a double-edged
sword. If our query is dynamic in nature (the query is built up as it goes using the EXEC command), then
the sproc may be optimized for the way things ran the first time, only to find that things never run that
way again — in short, it may be using the wrong plan!
It’s not just dynamic queries in sprocs that can cause this scenario either. Imagine a web page that lets us
mix and match several criteria for a search. For example, let’s say that we wanted to add a sproc to the
AdventureWorks2008 database that would support a web page that allows users to search for an order
based on:
❑ Customer name
❑ Sales Order ID
❑ Product ID
❑ Order date
The user is allowed to supply any mix of the information, with each new piece of information supplied
making the search a little more restricted and theoretically faster.
The approach we would probably take to this would be to have more than one query and to select the right
query to run depending on what was supplied by the user. The first time that we execute our sproc, it is
going to run through a few IF...ELSE statements and pick the right query to run. Unfortunately, it’s just
the right query for that particular time we ran the sproc (and an unknown percentage of the other times).
Any time after that first time the sproc selects a different query to run, it will still be using the query plan
based on the first time the sproc ran. In short, the query performance is really going to suffer.
Using the WITH RECOMPILE Option
398
We can choose to use the security and compartmentalization of code benefits of a sproc, but still ignore
the precompiled code side of things. This lets us get around this issue of not using the right query plan,
because we’re certain that a new plan was created just for this run. To do this, we make use of the WITH
RECOMPILE option, which can be included in two different ways.
First, we can include the WITH RECOMPILE at runtime. We simply include it with our execution script:
EXEC spMySproc ‘1/1/2004’
WITH RECOMPILE
This tells SQL Server to throw away the existing execution plan and create a new one — but just this
once. That is, just for this time that we’ve executed the sproc using the WITH RECOMPILE option.
We can also choose to make things more permanent by including the WITH RECOMPILE option right
within the sproc. If we do things this way, we add the WITH RECOMPILE option immediately before our
AS statement in our CREATE PROC or ALTER PROC statements.