1. Stored Procedures – Facts and Myths

2. About Me Over 15 years’ experience with SQL Server
Trainer & Consultant
Books & Articles Writer
OLTP and DW/BI Systems Architect
SQL Microsoft Most Valuable Professional since 2006
Founder of SQLExpert.pl
2 |

3. Agenda Is Plan Caching and Reuse a Good Thing?
What is its cost in terms of time, memory and concurrency?
Are there other options beside stored procedures?
Can You Avoid Recompilations?
Will putting all DML statements at the beginning help?
What is the impact of changing SET options?
Shoud you control recomplilations due to statistics changes?
When Plan Reusing is a Bad Thing?
Is Parameter Sniffing a bug or a feature?
Does a conditional logic hurt SPs performance?
Can a SP name affect performance?
3 |

4. Is Plan Caching and Reuse 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. Does Compilation/Recompilation Really Matter?
Measuring compilation cost, in terms of time and memory
Looking inside the Procedure Cache
YES, IT DOES

7. Are There Other Options ?
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. Are There Other Options ?
Checking two other options: query preparation and forced parameterization
YES, THERE ARE

9. Can You Avoid Recompilations?
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. Will Putting All DML Statements at the Beginning Help?
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. Will Putting All DML Statements at the Beginning Help?
Avoiding recompilation due to schema changes
NOT AT ALL

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
NEGLIGIBLE IMPACT

13. 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 % 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

14. Shoud You Control Recomplilations 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

15. Shoud You Control Recomplilations Due to Statistics Changes?
Avoiding recompilation due to statistics changes
YES, YOU SHOUD

16. 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

17. Is Parameter Sniffing a Bug or a Feature?
To deal with it 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
Recompiling a new plan for a given parameter value might be way cheaper than reusing a plan optimized for different values
Especially for DWs

18. Is Parameter Sniffing a Bug or a Feature?
Parameter Sniffing Revealed
Dealing with Parameter Sniffing
IT’S A FEATURE

19. Does a Conditional Logic Hurt Performance?
During the first execution SQL Server compiles and stores the execution plan for the whole stored procedure
If there are multiple execution paths, all of them will be included, though only one of them will be actually used
In all other branches the estimated numbers of rows will be one
There are some exeptions
The optimizer has to find good enough execution plans for a query that will never be executed with the given parameter values
The only robust solution is to move the conditional logic to the wrapper stored procedure, from which we will call the inner ones

20. Does a Conditional Logic Hurt Performance?
Following multiple execution paths
REALLY BADLY

21. Can a Name Affect Performance?
sp_ stands for Special Prefix not System Procedure
Microsoft uses the sp_ naming convention for their system stored procedures and so this should be avoided
Procedure prefixed with sp_ might conflict with one of system procedures and thus may never be called
Always use at least two part names
And be careful with DBO schema

22. Can a Name Affect Performance?
DBO Schema and sp_ prefix nuisance
STILL IT CAN

23. Sponsors