The document discusses SQL tuning methodology. The three pillars of SQL tuning are: 1) diagnostics collection to identify problematic SQL, 2) root cause analysis to determine why SQL is performing poorly, and 3) remediation steps to address issues. It covers tools for diagnostics collection like SQL trace, AWR, and explains execution plans and the cost-based optimizer. The document provides a methodology for SQL tuning including identifying SQL, collecting data, analyzing root causes, and testing and implementing solutions.

1. SQL Tuning 101
The three pillars of SQL Tuning:
Diagnostics Collection, Root Cause Analysis and
Remediation
Carlos Sierra

2. Agenda
• Motivation
• Methodology
– Diagnostics Collection
– Root Cause Analysis
– Remediation
• Some Important Topics
– Execution Plan
– Cost-based Optimizer
– Plan Stability
• Free Tools

3. Motivation
• One bad SQL can degrade overall DB performance!
• SQL Tuning is:
– A Complex Task
– Part Science and part Art
– The Responsibility of WHO?
• DBA?
• Developer?
• Oracle?
• Application Vendor?

4. Methodology
The three pillars of SQL Tuning
1. Good Practices
2. Diagnostics Collection
3. Root Cause Analysis (RCA)
4. Remediation

5. I. Good Practices
• The forgotten pillar of SQL Tuning
• Quid pro Quo (e.g. This for That or Give and Take)
– Be nice to the CBO and the CBO will be nice to you
• A healthy environment requires less SQL Tuning
• A win-win!
• Except for Consultants like myself!

6. Some Good Practices
• Start with a modern and solid database release
• Reset all CBO related parameters (and some more)
• Gather CBO Statistics as per Application or Product
– Automatic task does a decent job on 11.2.0.4+
• Write reasonable SQL
– Use the product as designed and avoid weird SQL
– If SQL is too long or too complex the CBO will struggle

7. Partial list of Parameters to Reset
• optimizer_features_enable
• optimizer_index_cost_adj
• optimizer_index_caching
• db_file_multiblock_read_count (not CBO exclusive)
• cursor_sharing (not an optimizer parameter)
• optimizer_dynamic_sampling
• optimizer_mode

8. II. Diagnostics Collection
a) Identify SQL_ID
b) Use Oracle-product base Tools
c) Supplement with specialized Tools

9. II.a Identify SQL_ID
• Oracle Enterprise Manager (OEM)
– [ OEM] [ Database | Grid | Cloud ] Control
• Automatic Workload Repository (AWR)
• Statspack (SP)
• SQL Trace (and TKPROF)
• V$ dynamic views (e.g. V$SQL and V$SESSION)

10. II.b Oracle-product base Tools
• SQL Trace (and TKPROF)
• Active Session History (ASH)
• EXPLAIN PLAN FOR
• AUTOTRACE
• SQL Developer
• DBMS_XPLAN
• SQL Monitor

11. SQL Trace
• ALTER SESSION SET
– SQL_TRACE = [ TRUE | FALSE ]
– EVENTS ‘10046 trace name context forever, level N’
• N = 1: all executions (10g-) or 1st execution (11g+)
• N = 4: Binds
• N = 8: Waits
• N = 12 = 4 + 8
• N = 16: each execution (11g+)
• N = 64: 1st + each where DB time > 1min (11.2.0.2+)

12. Where is my Trace?
• V$DIAG_INFO (11.1+)
• USER_DUMP_DEST (deprecated 12c)

13. TKPROF: SQL Text and DB Calls

14. TKPROF: Execution Plan and Wait Events

15. Active Session History (ASH)
• 1 sec snapshots of V$SESSION
• Every 10 ASH samples into AWR (10 sec granularity)
• Sessions “ON CPU” or “WAITING” (non-idle)
• Multiple Dimensions
• Excellent repository for performance data mining
• Requires Oracle Diagnostics Pack!

16. SQL Trace vs. ASH
Pros
• Precise
• Free
Pros
• Always available
• Multi-dimensional repository
• Plan line granularity (11g+)
Cons
• Re-execute transaction
• Waits per cursor
– No plan line granularity
Cons
• Requires Diagnostics Pack

17. EXPLAIN PLAN FOR
• Actual SQL is not executed
• Blind to Bind Peeking, thus unreliable with Binds

19. SET AUTOTRACE ON
• Actual SQL is executed
• Includes small subset of Session Statistics

20. Query Output and Execution Plan

21. Predicate Information and Session Stats

22. SQL Developer

24. DBMS_XPLAN
• DISPLAY (from PLAN_TABLE)
• DISPLAY_CURSOR
• DISPLAY_AWR
• DISPLAY_SQL_PLAN_BASELINE
• DISPLAY_SQL_SET
• SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY%());

25. DBMS_XPLAN.DISPLAY_CURSOR
• SQL_ID
• CURSOR_CHILD_NO (defaults to 0!)
• FORMAT
– TYPICAL = DEFAULT
– ALL = TYPICAL + QB + PROJECTION + ALIAS + REMOTE
– ADVANCED = ALL + OUTLINE + BINDS
– ALLSTATS = IOSTATS + MEMSTATS (all executions)
– ALLSTATS LAST (last execution)
– ADAPTIVE (12c)

26. Sample query with hints and binds

28. SQL Monitor
• Part of the Oracle Tuning Pack
• Tabular and Graphical Execution Plan
• Timeline per Plan Line
• Binds and Predicates
• Nice and intuitive
• Executed from OEM or SQL*Plus

31. II.c Specialized Tools
• SQLTXPLAIN (a.k.a. SQLT)
– My Oracle Support (MOS) 215187.1
• SQLHC
– MOS 1366133.1
• SQLd360
– By Mauro Pagano
• Others?

32. III. Root Cause Analysis
• This is where you want to spend your time!
• Go over all the output of your specialized tool
• Look for correlations and possible causation
• Put yourself in the shoes of the Optimizer
• Question everything (is there a better way?)
• Ask for help after you have done your homework
• Enjoy the ride!

33. Typical Steps
1. Find where the time is spent (plan line)
– Too many executions or too much time per exec?
2. Validate estimated rows versus actual rows
– If off determine why (deficient statistics maybe?)
3. What is the history of this SQL?
– Can you find a better performing plan?
4. Can you make perfect sense of the SQL and plan?

34. IV. Remediation
• Explore multiple possibilities
– And try to prove yourself wrong!
• Implement the smallest-scope fix
– Avoid system-wide changes unless you are rock solid!
• Avoid guesses and assumptions (piñata method)
– Too many people out there are “tuning” blind-folded!
• Trust nobody! (be skeptic and test thoroughly)

35. Three Important Topics
1. Execution Plan
2. Cost-based Optimizer
3. Plan Stability

36. 1. Execution Plan
• If you do not understand the SQL or the Execution
Plan stop right there!
• From SQL text you can draw a diagram if that helps
• To understand the Execution Plan start small
– Review a two-tables query and review plan
– Move to a three-tables query and review plan
– Introduce subqueries and more complex constructions

37. 2. Cost-based Optimizer
• CBO was released on 7.3 (circa February 1996)
• A large and complex piece of software enhanced
for two decades
• By design the CBO produces an optimal execution
plan according to some representation of the data
– This means: execution plans are expected to change!
– Breathe deep and embrace the change!

38. 3. Plan Stability
• Most DBAs hate Execution Plan changes
– They never hear of changes for the better!
• To remediate undesired plan changes we do have
several Plan Stability techniques
– SQL Plan Management (Baselines) from 11g
– SQL Profiles from 10g
– Deprecated Stored Outlines from 9i
– And then some others (SQL Patches and CBO Hints)

39. Popular Free Diagnostics Tools
• SQLTXPLAIN
• SQLHC
• SQLd360
• Stand-alone scripts

40. SQLTXPLAIN

41. SQLd360

43. SQLd360 Plan Tree

46. SQLT XPLAIN vs. SQLd360
Pros
• Oracle Support Standard
• Free (requires MOS account)
• Comprehensive and mature
Pros
• Free Software (no strings)
• Installs nothing on database
• Graphical visualization of data
Cons
• Requires installation
• HTML Tables (no charts)
Cons
• Still young (frequent releases)

47. SQL Tuning Road Map
1. Start with a clean and healthy environment
2. Identify SQL_ID
3. Collect diagnostics using comprehensive tools
4. Spend time analyzing diagnostics collected
5. Determine root cause
6. Explore remediation actions
7. Test and implement solution

48. Questions

49. The End
• http://carlos-sierra.net/
– Blog and downloads
• carlos.sierra.usa@gmail.com
– Questions and follow-up
• SQL Tuning is more about understanding
what your eyes see at first