Upload
ivo-andreev
View
4.986
Download
1
Tags:
Embed Size (px)
DESCRIPTION
MS SQL parameter sniffing (or "Bind Variable Peeking" in Oracle) is designed for good. Following some common best practices developers create procedures, analyze actual execution plan, test performance with various sets of data and it is then that they deploy. How about when the same good procedure that used to run less than 100ms starts to timeout...in production? Then you may have become a victim of bad query plan due to parameter sniffing. This may sound as a sci-fi scenario but is rather a real life use case which anyone may encounter. Join this session to get practical ideas of how to identify the cause, avoid typical mistakes and perform a fix.
Citation preview
The Two Faces of SQL
Parameter Sniffing(or Just the Other Face)
About me
� Project Manager @
� 11 years professional experience
� MCPD .NET Web Development
� 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/[email protected]
� 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/[email protected]
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/[email protected]
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