1. NASI SPONSORZY I PARTNERZY

2. Stored Procedures –
Facts and Myths
Marcin Szeliga
www.sqlexpert.pl
http://blog.sqlexpert.pl/
http://www.facebook.com/SQLExpertpl
marcin@sqlexpert.pl

3. Agenda
• Basic Fact - Plan Caching and Reuse is (usually) a
Good Thing
• Obvious Consequence – You Should Avoid
Recompilations …
• But Sometimes Plan Reusing is a Bad Thing
• Recap

4. Plan Caching and Reuse is a Good
Thing
• Stored procedures
– Are a convenient container for code reuse
• They can be called many times and the query plans can be
reused, saving the time, CPU and memory
– Are optimized and compiled during their first execution
• Optimization is based on parameters supplied during this
execution
• Future executions will reuse the query plan stored in plan
cache
• There are at most two instances of a query plan at any time in
plan cache:
– One for all of the serial executions.
– One for all of the parallel executions
• From a query plan, an execution context is derived
– Execution contexts hold the values needed for a specific execution of
a query plan, and they are also cached and reused

5. Does compilation/recompilation
really matter?
• In terms of time
– Compilation is really expensive and CPU-heavy process
• In terms of memory
– Storing large number of execution plans the procedure cache “steals”
memory from the Buffer Pool
– The currently used formula looks like this:
• 75% 0-4GB + 10% 4-64GB + 5% 64GB
– On 16GB box 4.2 GB may be used for the procedure cache
• In terms of concurrency
– Getaways throttle simultaneous compilation to really small number
• Three of them:
– Small - 4 x number of logical CPUs allocated to SQL Server
– Medium - Number of logical CPUs allocated to SQL Server
– Large - 1
• Look for 'RESOURCE_SEMAPHORE_QUERY_COMPILE' wait

6. Demo
• Measuring compilation cost, in terms of time and
memory
• Looking inside the Procedure Cache

7. Stored procedures are not the only
option
• SQL Server can cache query plans for different types of
batches beside ad-hoc queries and stored procedures:
– Query preparation
• ODBC and OLE DB expose this functionality via
SQLPrepare/SQLExecute and ICommandPrepare interfaces
• Very similar result can be achieved by using sp_executesql
– Simple parameterization
• SQL Server automatically replaces constant literal values
with variables before the query plan will be compiled
• SQL Server 2008 allows us to forced parameterization of
almost all types of queries
– Dynamic SQL
• Strings submitted via EXEC for execution

8. Demo
• Checking two other options: query preparation and
forced parameterization

9. Avoiding recompilations due to plan
stability-related reasons
• Stored procedure (or a batch) must be recompiled if
not doing so would result in incorrect results or
actions
• 14 recompilation reasons
• 2 sub-categories:
– Scheme changes
– SET options changes

10. Recompilation due to schema
changes
• Putting all DML statements at the beginning of a stored
procedure will NOT minimize recompilations
– SQL Server 2005 onwards does statement level recompilations
• Deferred compilations mean that objects didn't exist during
creation the stored procedure
• The only solution is to use temporary tables
– SQL Server caches temporary objects but altering definitions of
those temporary objects disables this caching mechanism
• In addition, objects cannot have named constraints
• Accessing objects created outside the current scope requires
object id to name resolution
– Recompilation due to the changed scheme occurs

11. Demo
• Avoiding recompilation due to schema changes

12. Recompilation due to SET option
changes
• When an execution plan is created, the SQL Server stores
the environmental setting with it
– Some SET options used when the stored procedure was
created or altered will be saved as part of its metadata
– Some execution plan attributes are considered cache key
ones
• Subsequent execution will not trigger recompilations
– During the first execution a procedure is recompiled with
the correct values, and from now on its execution plan is
valid
• On SQL Server 2005 onwards this has a much less impact
than before

13. Demo
• Avoiding recompilation due to SET option changes

14. Recompilations due to plan
optimality-related reasons
•
•
•
•
SQL Server collects statistics about individual columns or sets of columns
Statistics contain:
– The average key length
– A single-column histogram, including up to 200 values of a given column
– The estimated number of rows matching the filter, or all rows in the table
Statistics can be not only automatically created but also kept up to date
Statistics will be considered stale when:
– The first row is inserted into the empty table
– The number of rows in the table was less or equal to 500 and the
colmodctr of the leading column of the statistics object has changed by
more than 500
– The table had more than 500 and the colmodctr of the leading column of
the statistics object has changed by more than 500 + 20% of the number
of rows
– If the statistics object is defined on a temporary table, there is an
additional threshold for recomputation at 6 rows

15. Recompilations due to statistics
changes
• Even if a statistic becomes outdated, it will not be
automatically updated after the modification completes
– It will automatically update the next time a query plan
uses it
• Default mechanism may lead to unnecessary
recompilations
• Triggers are also being recompiled when the number of
rows in the inserted or deleted virtual tables changes
significantly from one execution to the next
• This is where hints come in
– KEEP PLAN, disables the “6 rows” rule
– KEEPFIXED PLAN disables recompilations due to statistics
changes completely

16. Demo
• Avoiding recompilation due to statistics changes

17. When Plan Reusing is a Bad Thing
• Optimization and execution are two completely separate
processes
– Sometime during an optimization SQL Server does not
know the actual values used in queries
– Incorrect estimation in one part of the execution plan can
(and probably will) be spread to others part of the plan
• Parameter Sniffing is an expected SQL Server behavior
– Parameter values used for the first execution of a stored
procedure will be used to compile an execution plan and
this plan will be used over and over again
– The problem arises when a stored procedure is executed
for the first time with unusual parameter values

18. Dealing with Parameter Sniffing
• You can:
– Disable plan caching for the problematic stored procedure
by adding WITH RECOMPILE to the procedure header
– Force a new compilation for a specific execution only by
adding WITH RECOMPILE to the EXEC statement
– Force a compilation with typical parameter values
• By using variables
• By using OPTIMIZE FOR UNKNOWN
• Remember, recompiling a new plan for a given parameter
value might be way cheaper than reusing a plan
optimized for different values
– Especially for DWs

19. Demo
• Parameter Sniffing Revealed
• Dealing with Parameter Sniffing

20. Recap
• Recompilation not only takes a lot of resources (both CPU
cycles and memory), but also can considerably slow down
your queries
• There are two other mechanisms, beside stored procedures
(queries preparation and auto-parameterization) that can be
used to avoid unnecessary recompilations
• Temporary tables, not the permanent ones, should be used
inside stored procedures
• Make an informed choice when to disable recompilations,
without changing database options and using table variables
• Parameter Sniffing is rather a feature than a bug and now you
know how to deal with it

21. NASI SPONSORZY I PARTNERZY
Organizacja: Polskie Stowarzyszenie Użytkowników SQL Server - PLSSUG
Produkcja: DATA MASTER Maciej Pilecki