The Two Faces of SQL

Parameter Sniffing(or Just the Other Face)

About me

� Project Manager @

� 11 years professional experience

� MCPD .NET Web Development

� ivelin.andreev@icb.bg

� http://www.linkedin.com/in/ivelin

� Business Interests

� Web Development (ASP.NET, jQuery, AJAX)

� SOA, Integration

� GIS, Mapping

� SQL optimization

2 |

Agenda

� Execution plan cache

� Parameter sniffing

� Performance issues

� Diagnostics

� Solution options

� Other RDBMS

� Demos

Not all [animals] are created equal

Image source http://hateandanger.wordpress.com/2012/06/05/fair/

The Plan Cache

� Execution plan cache (SQL Server)

� Query plans

� Ad hoc queries

� Stored procedures and User functions

� Triggers

� Execution contexts (per user)

� Retrieve plan

� Retrieve: sys.dm_exec_query_plan (plan_handle)

Putting Query Plan in Cache

� Compilation is CPU intensive

� Plan evicted from cache when

� ALTER PROCEDURE

� sp_recompile

� UPDATE STATISTICS (w/o SQL 2012)

� DBCC FREEPROCCACHE

� Cache buffer full

� View cached plans

� sys.dm_exec_query_stats

Variable run-time values - unknown for optimizer

Query Plan Generation

� CREATE [PROCEDURE]

� Syntactic check

� No plan built at this point

� Execution

� Sniff parameters

� Analyze distribution statistics

� Create plan

Plan cache contains only estimated plans

Image source http://123child.com/images/mine/DSCN4763.JPG

Parameter Sniffing?

� Def: Optimiser looking at input values

� Estimates based on statistics

� Notes

� Applies to all versions of SQL Server

� Local variables get standard assumption

� Constants are not sniffed

Image source http://jtown67.deviantart.com/art/Jekyll-and-Hyde-352442994

Dr. Jekyll and Mr. Parameter Sniffing

When Parameter Sniffing Stinks

� Parameter sniffing itself is not a problem

� Until it is!

� Negatively affecting performance?

1. Explain your customers

2. Other options ?

Performance problems caused by parameter

sniffing are considered to be by design

Typical Cases

1. Sniffing inappropriate for query usage

� One group of calls very different from main bulk

� Plan good for execution not appropriate for next

� Index Seek + Key Lookup vs. Table Scan

2. No perfect index for the query

Not your DB design fault

� Reproducible with AdventureWorks DB

DEMO 1: Reproduce parameter sniffing

Image source http://netdna.webdesignerdepot.com/uploads/2012/12/featured45@wdd2x.jpg

� DO NOT schedule DBCC FREEPROCCACHE

� EXEC sp_recompile

If problem reoccurs: (most likely)

� Keep the slow plan to analyse it!

� Which statement is slow?

� Are there different query plans?

� What are the index definitions?

� What parameter values are sniffed

� Are distribution statistics up to date?

Gathering Information

Typical symptom is lots of logical reads

Cause and Symptoms

Cause: Cardinality Error

� Huge difference - estimated/actual rows

� Huge difference - resource cost for the same plan

Symptom: Logical Reads

� Monitor deviation from average

� Monitor high Min – Max fluctuations

DEMO 2: Gather information

Image source http://netdna.webdesignerdepot.com/uploads/2012/12/featured45@wdd2x.jpg

Solution 1 - Recompilation

Recompile SP on every execution

� OPTION (RECOMPILE)

� WITH RECOMPILE (Create/Execute)

� Pros

� The best query plan every time

� Cons

� CPU-intensive

� Not suitable for SP used frequently

� Plans not stored in cache (for debug)

Solution 2 – OPTIMIZE Query Hint

Use specified value when compiling the plan

� You know a value that produces good plan

� OPTION (OPTIMIZE FOR (@par=[Value]))

� OPTIMIZE FOR UNKNOWN (SQL 2008 +)

� Pros

� “Good Enough” plan

� Cons

� Not for frequent data distribution changes

Solution 3 – Local Variables

Copy SP parameter to local variable

� Pros

� Same as “OPTIMIZE FOR UNKNOWN”

� Works on every version of SQL server

� Cons

� Same as “OPTIMIZE FOR UNKNOWN”

Solution 4 – Trace Flag 4136

Average estimate instead of histogram stats

� DBCC TRACEON (4136[, -1])

� Pros

� Evens “highs” and “lows”

� Cons

� Disables sniffing at SQL instance level

� Affects all DBs

� No benefit if data is evenly distributed

Solution 5 – Plan Guides

Attach fixed query plan to queries

� Pros

� Optimize query w/o changes in SQL text

� 3rd party vendor SQL optimization

� Cons

� Only one guide enabled for object

� Modify object referred by plan guide causes error

DEMO 3: Fix parameter sniffing

Image source http://netdna.webdesignerdepot.com/uploads/2012/12/featured45@wdd2x.jpg

When it may not be Sniffing

SET Options

� Many are cache keys

� Causes different entries for one SP

ARITHABORT

� Terminates query on overflow / divide-by-zero

� SET ARITHABORT ON/OFF

� Defaults (OFF – ADO.NET, ON - SSMS)

� Always match ARITHABORT on troubleshoot

Poorly written SQL is always slow

Parameter Sniffing and Other RDMS

� Bind Variable Peeking

� Adaptive Cursor Sharing (11g) 2007

� Enables statement to use multiple plans

� Identify “bind-sensitive” cursor

� Promote to “bind-aware” cursor� Track expected/actual operator cardinalities

� Cache and use new plan

� Notes

� Enabled by default

� Does not apply for >14 bind variables

Microsoft will fix that… When pigs fly

http://connect.microsoft.com/SQLServer/feedback/details/377959/

The Two Faces (Summary)

Dr. Jekyll

� Parameter sniffing is not bad

� Useful for performance tuning

� Integral part of SQL server

� Learn how to diagnose

Mr. Hyde

� Until it is

� At great cost for server

� Oracle fixed it

� Apply non-ideal solutions

Uneven data distribution and cost cannot be

derived. It is the optimiser that failed

Image source http://blogs.urbancode.com/agile/maslows-hammer-the-curse-of-tool-blindness

Credits

� Milos Radivojevic

� DB developer, Consultant, Speaker

� http://sqlbits.com/Speakers/Milos_Radivojevic

� Erland Sommarskog

� SQL Server MVP

� Consultant

� http://www.sommarskog.se/

Sponsors