0. Executing Explain Plans and Explaining Execution Plans
Pittsburgh, PA – November 20, 2015
Craig Martin

1. Who is Craig Martin? Manager, Nationwide – Columbus, OH
Applications DBA team
Worked with Oracle since 2002
Specialize in Performance Improvement of SQL and PL/SQL
Very much enjoy teaching what I have learned
Not a professional speaker, so I need your help
Ask Questions!
@c_martin2
November 20, 2015

2. Nationwide Disclaimer
The opinions I share are mine, and do not necessarily reflect those of Nationwide
Nationwide does not endorse any process or product mentioned
It is up to each individual to evaluate the content in this presentation and do their own testing
Use this information at your own risk

3. Craig’s Query Tuning Process
Understand History of query
Use tools like Solarwinds Database Performance Analyzer, OEM, AWR, etc.
Get detailed query execution plan Collect information about what is currently happening
Make sense of query execution plan Understand what is currently happening and why
Determine correct starting point for query Which table should Oracle start with for the most efficient execution
Determine correct join order for query How should Oracle bring in other tables to keep row count as low as possible for as long as possible
Ensure access methods are correct Index access vs. Full Table Scan, etc.
Ensure join methods are correct Nested Loops vs. Hash Join, etc.
@c_martin2
November 20, 2015

4. NOT Craig’s Query Tuning Process
Collect statistics Rebuild indexes Rewrite query SQL Tuning Advisor … and on and on …
I am not saying I won’t do these things.. I just don’t do them as my first step. I want to understand where the performance issue is coming from so I make an educated guess that the action I am taking will resolve the issue.
@c_martin2
November 20, 2015

5. John Wooden
Gene Kranz
During Apollo 13 mission when everyone was panicking and yelling out what they thought the problem had to be and how to fix it, Gene Kranz gave specific instructions: “Work the problem people. Don’t make things worse by guessing”. If they had enough time to analyze the data available when lives were at stake and every minute counted, you have enough time to analyze the data for your slow running queries.
John Wooden was the coach of the UCLA men’s basketball team from 1948 – His teams were National Champions 10 of his final 12 seasons. One of my favorite of his quotes: “If you don't have time to do it right, when will you have time to do it over?”
@c_martin2
November 20, 2015

6. Executing Explain Plans
Get Detailed Query Execution Plan
@c_martin2
November 20, 2015

7. Explain Plan statement
explain plan for select e. , d.department_name, l.city, mgr. manager_ from employees e inner join departments d on d.department_id = e.department_id inner join locations l on l.location_id = d.location_id left outer join employees mgr on mgr.employee_id = e.manager_id where e.salary > 10000;
From documentation: Use the EXPLAIN PLAN statement to determine the execution plan Oracle Database follows to execute a specified SQL statement. This statement inserts a row describing each step of the execution plan into a specified table.
Show options and a simple example.
@c_martin2
November 20, 2015

8. Query PLAN_TABLE Directly
Displaying Results
Query PLAN_TABLE Directly
Explain Plan feature in SQL Developer, TOAD, etc
DBMS_XPLAN package
Explain plan actually puts data into the plan_table. In Oracle 10g or above, by default a plan_table is created as a global temporary table owned by SYS along with a plan_table public synonym so it can be used by all users. Once explain plan has been executed, there are a few different ways to access the information.
@c_martin2
November 20, 2015

9. DISPLAY_SQL_PLAN_BASELINE DISPLAY_PLAN DIFF_PLAN
DBMS_XPLAN!
7 Functions (as of 12.1)
DISPLAY
DISPLAY_CURSOR
DISPLAY_AWR
DISPLAY_SQLSET
DISPLAY_SQL_PLAN_BASELINE
DISPLAY_PLAN
DIFF_PLAN
10g
11gR1
My personal preference is the DBMS_XPLAN package. It formats the data consistently and can be run from any tool. There are 6 different “display” functions and a new “compare” function in DBMS_XPLAN:
DISPLAY – Displays output from plan table. Used with “Explain Plan”.
DISPLAY_CURSOR – Displays information for any SQL in cursor cache
DISPLAY_AWR – Displays information for any SQL stored in AWR
DISPLAY_SQLSET – Displays information for any SQL stored in tuning set
DISPLAY_SQL_PLAN_BASELINE – Displays execution plans for specific SQL_HANDLE from SQL plan baseline
DISPLAY_PLAN – Like display, but returns CLOB and allows for more output types (HTML, XML, etc)
DIFF_PLAN – Compares plans
11gR2
12c
@c_martin2
November 20, 2015

10. Pros Cons DBMS_XPLAN.DISPLAY
Actual SQL doesn’t have to be executed just explained
Cons
The plan produced may not be the actual plan used when executing the SQL
@c_martin2
November 20, 2015

11. Explain Plan can Lie!
@c_martin2
November 20, 2015

12. Different Tools – Same Wrong Result
@c_martin2
November 20, 2015

13. DBMS_XPLAN.DISPLAY_CURSOR
Pros
Can display plan information for any SQL in cursor cache
Allows displaying of additional statistics (I/O, memory, timing)
Cons
SQL must have already been executed
(At least started)
@c_martin2
November 20, 2015

14. DBMS_XPLAN.DISPLAY_CURSOR
Parameters
SQL_ID
Child Number
Format
Gathering Additional Details
Memory Management Statistics
Set parameter pga_aggregate_target to non-zero
I/O Statistics
Set parameter statistics_level to “ALL”
Use gather_plan_statistics hint during execution
The DISPLAY_CURSOR function accepts 3 parameters:
* SQL_ID – The SQL_ID of the SQL in cursor cache. Can be retrieved from V$SQL or V$SQL_AREA
CHILD_NUMBER – The Child number of the cursor to display. Can also be retrieved from V$SQL or V$SQL_AREA. If null, then will display information for all cursors matching SQL_ID
FORMAT – Controls detail of information displayed. See documentation for all options.
Some of the Memory and I/O information requires specific parameters to be set before running the SQL to be analyzed.
@c_martin2
November 20, 2015

15. DBMS_XPLAN.DISPLAY_CURSOR
alter session set statistics_level = ALL select e. , d.department_name, l.city, mgr. manager_ from employees e inner join departments d on d.department_id = e.department_id inner join locations l on l.location_id = d.location_id left outer join employees mgr on mgr.employee_id = e.manager_id where e.salary > 10000; select * from table(dbms_xplan.display_cursor(null,null,'ADVANCED IOSTATS LAST'));
Alter session (or provide hint) to tell Oracle to gather additional details
Run query
Select from dbms_xplan.display_cursor table function to view results
@c_martin2
November 20, 2015

16. DISPLAY_CURSOR: Output
Up to 7 sections possible
Information about SQL Statement
Execution Plan
Query Blocks / Object Alias
Outline
Predicates
Column Projection
Notes
There are 7 possible sections of output for DISPLAY_CURSOR. Whether or not each section is shown is determined by the value passed into the FORMAT parameter.
@c_martin2
November 20, 2015

17. DISPLAY_CURSOR: Output
Information about SQL
Section 1: Information about the SQL statement. Includes the SQL_ID, Child Number and SQL that was executed.
@c_martin2
November 20, 2015

18. DISPLAY_CURSOR: Output
Execution Plan
Section 2: The Execution Plan. This shows the path that was taken to complete the SQL statement. The columns shown in this section depends on the value passed into the FORMAT parameter. We will look in detail at this output in a little bit.
@c_martin2
November 20, 2015

19. DISPLAY_CURSOR: Output
Query Blocks / Object Alias
Section 3: Query Blocks. This section is useful when you are wanting to hint specific query blocks from one location (for example when adding hints through OBIEE). The number in the beginning corresponds to the number in the execution plan table.
@c_martin2
November 20, 2015

20. DISPLAY_CURSOR: Output
Outline
Section 4: Outline. This section shows all the hints that would be needed to ensure the query executes in exactly the same fashion again. This is typically used with stored outlines and SQL plan baselines.
@c_martin2
November 20, 2015

21. DISPLAY_CURSOR: Output
Predicates
Section 5: The predicate information shows the filters that get applied when accessing the data. This section is helpful to see any transformations that may have been done to the query by Oracle, including data type conversions. The number in the beginning corresponds to the number in the execution plan table.
Access = Only matching rows are retrieved
Filter = All rows are retrieved, matching rows kept
@c_martin2
November 20, 2015

22. DISPLAY_CURSOR: Output
Column Projection
Section 6: Column projection information shows each field and its corresponding data type that is returned from each step in the execution plan. The number in the beginning corresponds to the number in the execution plan table.
@c_martin2
November 20, 2015

23. DISPLAY_CURSOR: Output
Notes
Section 7: Notes. Oracle displays any relevant information about what it may have done. Examples are dynamic sampling, star transformations, and even comments that you are trying to display information in DISPLAY_CURSOR that wasn’t collected due to the proper parameters not being set.
@c_martin2
November 20, 2015

24. DISPLAY vs. DISPLAY_CURSOR
A quick comparison between the information shown in the execution plans returned from DISPLAY (top) and DISPLAY_CURSOR (bottom). Note how in the DISPLAY_CURSOR output the rows, bytes, and time columns are more accurately labeled as “E-” since they are estimated values. Also note that this is just a sampling of the possible columns that DISPLAY_CURSOR might display. Consult the Oracle documentation for a full list of all possible columns and their meanings.
@c_martin2
November 20, 2015

25. DISPLAY_CURSOR: Output
The typical format option I use is ‘IOSTATS LAST’… This displays just the columns and sections that I use the most. The LAST modifier only shows statistics for the last execution (default is to show sum of all executions)
@c_martin2
November 20, 2015

26. DISPLAY_CURSOR: 12c Adaptive Query Optimization
In 12c, with the introduction of Adaptive Plans, your final plan might not be what Oracle set out to do in the first place.
@c_martin2
November 20, 2015

27. DISPLAY_CURSOR: 12c Adaptive Query Optimization
The format option ‘ADAPTIVE’ will show the full details of what Oracle thought it was doing, and what it actually did. The other formats just show the final execution plan of what actually happened.
@c_martin2
November 20, 2015

28. DISPLAY_CURSOR: SQL Developer 4 and higher
@c_martin2
November 20, 2015

29. Explaining Execution Plans
Make Sense of Query Execution Plan
@c_martin2
November 20, 2015

30. Understanding the Columns
E-Rows = Estimated number of rows returned by operation per execution
A-Rows = Actual number of rows returned by operation (total)
Starts = Number of times this operation was executed
A-Rows = Time consumed by this operation (and its children)
Buffers = Number of blocks accessed by this operation (and its children)
@c_martin2
November 20, 2015

31. Reading Execution Plans
From Oracle Documentation (12.1)
How to read execution plans as documented by Oracle. Pay special attention to the last bullet. I believe the author was trying to indicate that children steps run before its parents, but as it is written, it is at most blatantly incorrect and at least very misleading.
@c_martin2
November 20, 2015

32. Reading Execution Plans1 2 3
Reading Execution Plans – Example 1: Hash Joins. Execution order = 2, 5, 6, 4, 7, 3, 1. Note how this differs from the Oracle documentation, which says to start with the most indented lines first, and move to less indented lines, which would come up with the incorrect order of 5, 6, 4, 7, 3, 2, 1 4 7 5 6
@c_martin2
November 20, 2015

33. Stand-Alone Operations
Common Operations
Stand-Alone Operations
Most operations of this type
Parents have at most one child
Child executed at most once
Child feeds its parent
Examples:
TABLE ACCESS
HASH GROUP BY
COUNT
Review of 3 different types of operations that can appear in the execution plans. The naming of these 3 types are from Christian Antognini, but I like them as they are pretty descriptive as to what is happening. Knowing how each type works is important to understanding what is actually happening during execution.
@c_martin2
November 20, 2015

34. Unrelated-Combine Operations
Common Operations
Unrelated-Combine Operations
Parents have multiple children that are executed independently
Children are executed sequentially
Starts with child with smallest ID
Every child executed at most once
Every child feeds its parent
Examples:
HASH JOIN
MERGE JOIN
UNION-ALL
Important: Children are executed sequentially and is executed at most once. All records from the first child are retrieved and then all records from the second child are retrieved. This is the big difference between unrelated-combine operations and related-combine operations.
@c_martin2
November 20, 2015

35. Related-Combine Operations
Common Operations
Related-Combine Operations
Parents have multiple children where one child controls execution of the other children
Children are not executed sequentially
Only first child executed at most once
All others may be executed many times or not at all
Not every child feeds its parent
Some are used only as restrictions
Examples:
NESTED LOOPS
UPDATE
FILTER
The Starts column in the execution plan being greater than one helps to spot when a related-combine operation is occurring.
@c_martin2
November 20, 2015

36. 1 2 3
Reading Execution Plans – Example 2: Hash Joins mixed with Nested Loops. Execution order = 2, 5, 6, 4, 7, 3, 1. Note how the Starts columns have values > 1 for the 2nd child of the Nested Loop operations. 4 7 5 6
@c_martin2
November 20, 2015

37. 1 2 7
Reading Execution Plans – Example 3: Nested Loops. Execution order = 4, 5, 3, 6, 2, 7, 1. Note how the Starts columns have values > 1 for the 2nd child of the Nested Loop operations. 3 6 4 5
@c_martin2
November 20, 2015

38. Reading Execution Plans – Example 3: A more complicated example
Reading Execution Plans – Example 3: A more complicated example. The important thing to realize is that even the execution plan is bigger and more complicated, it is still read in exactly the same way.
@c_martin2
November 20, 2015

39. 1 2 3 4 5 10 11 12 6 7 13 8 9 14 15
Reading Execution Plans – Example 3: A more complicated example. The important thing to realize is that even the execution plan is bigger and more complicated, it is still read in exactly the same way. Execution order = 2, 6, 8, 9, 7, 5, 11, 14, 15, 13, 12, 10, 4, 3, 1
@c_martin2
November 20, 2015

40. Cost! Rules of Always What to Ignore Can’t be directly controlled
May not be an accurate indication of performance
Rules of Always
Full table scans are always bad
Indexes are always good
Like everything else with Oracle, there are no silver bullets when it comes to execution plans. You really need to understand how your data is stored and understand what is happening to know if there is a better way to accomplish the same result.
@c_martin2
November 20, 2015

41. Estimates that don’t match the actual data Wasted Operations / Rows
What to Look For
Estimates that don’t match the actual data
Inaccurate statistics may exist
Wasted Operations / Rows
Many more rows are read for an operation than are used
Full scans
Unselective range scans
Wrong join order
Late filter operations
High Execution Time / Buffer Count
If you ignore cost and looking for things like FTS, what are you looking for? Inaccurate counts and Non-Optimal paths to the end result. If you are looking for a number to compare between different plans, I would look at execution time and buffer count. Lower execution time is obviously preferred. Lower buffer counts will mean more scalability.
@c_martin2
November 20, 2015

42. Troubleshooting Oracle Performance by Christian Antognini
References
Oracle Documentation
Oracle Database Performance Tuning Guide
Oracle Database PL/SQL Packages and Types Reference
Troubleshooting Oracle Performance by Christian Antognini
@c_martin2
November 20, 2015

43. cmartin2@cmartin2.com @c_martin2 Questions? @c_martin2
November 20, 2015