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.
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
The two faces of sql parameter sniffing
1. The Two Faces of SQL
Parameter Sniffing
(or Just the Other Face)
2. 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 |
4. Not all [animals] are created equal
Image source http://hateandanger.wordpress.com/2012/06/05/fair/
5. 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)
6. 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
8. Query Plan Generation
CREATE [PROCEDURE]
Syntactic check
No plan built at this point
Execution
Sniff parameters
Analyze distribution statistics
Create plan
9. Plan cache contains only estimated plans
Image source http://123child.com/images/mine/DSCN4763.JPG
10. 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
11. Dr. Jekyll and Mr. Parameter Sniffing
Image source http://jtown67.deviantart.com/art/Jekyll-and-Hyde-352442994
12. When Parameter Sniffing Stinks
Parameter sniffing itself is not a problem
Until it is!
Negatively affecting performance?
1. Explain your customers
2. Other options ?
14. 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
16. Gathering Information
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?
18. 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
19. DEMO 2: Gather information
Image source http://netdna.webdesignerdepot.com/uploads/2012/12/featured45@wdd2x.jpg
20. 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)
21. 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
22. 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”
23. 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
24. 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
26. 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
28. 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
31. 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
32. 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
33. Credits
Milos Radivojevic
DB developer, Consultant, Speaker
http://sqlbits.com/Speakers/Milos_Radivojevic
Erland Sommarskog
SQL Server MVP
Consultant
http://www.sommarskog.se/