Getting the most out of your Oracle 12.2 Optimizer (i.e. The Brain)

Getting the most out of your Oracle
12.2+ Optimizer (i.e. The Brain)
Janis Griffin
Senior DBA / Performance Evangelist

© 2018 SolarWinds Worldwide, LLC. All rights reserved.
Who Am I
• Senior DBA / Performance Evangelist for SolarWinds
• Janis.Griffin@solarwinds.com
• Twitter® - @DoBoutAnything
• Current – 25+ Years in Oracle®, DB2®, ASE, SQL Server®, MySQL®
• DBA and Developer
• Specialize in Performance Tuning
• Review Database Performance for Customers and Prospects
• Common Question – How do I tune it?

Agenda
• 12.2 Optimizer
• Adaptive Plans
• Adaptive Statistics
• Dynamic Statistics / Statistic Feedback review
• New Sql Plan Directives features explained
• New Optimizer Statistics Advisor
• SQL Plan Management - What’s new?
• How it coexists with adaptive plans
• How to control baselines
• Approximate Query Processing
• What is it
• When and how to use it

In The Beginning… Optimizer Overview
• Rule Based Optimizer (Version < 7.3)
• Rules based on 17 possible access paths
• Only one execution plan chosen and only simple rewrites of ‘OR’ to ‘Union ALL’
• Cost Based Optimizer (Version > = 7.3)
• Multiple plans generated with estimated cost of IO/CPU
• Plan with lowest cost chosen
• Allows for hash joins, histograms, partitioning and parallel queries
• More complex rewrites and transformations
• Required statistics gathering and plans changed
• 8.1.7, Stored outlines to control plan changes
• 9.2, Dynamic sampling of statistics
• 10g, SQL Profiles / Tuning Advisor
• DBMS_SQLTUNE – Costs $$$
• Oracle 11, Adaptive cursor sharing / SQL plan management / SQL patches
• Oracle 12.1, Adaptive optimizer – could only turn on or off feature

Adaptive Optimizer 12.2
• Two new parameters
• Adaptive statistics turned off (default)
• SQL plan directives
• Statistics feedback for joins
• Performance feedback
• Dynamic sampling for parallel query
Adaptive Query Optimizer
Adaptive Plans
Adaptive
Statistics
Join
Methods
Parallel
Distribution
Dynamic
Statistics
Automatic
Reoptimization
Sql Plan
Directives
Bitmap Index
Pruning

How the Optimizer Works
Default Plan sent to Row Source Generator
Query Transformer – rewrites
query to be more efficient
Plan Generator – creates
multiple plans using different
access paths & join types.
Plan with lowest cost is chosen
Estimator – looks at
selectivity, cardinality & cost
Data Dictionary
Schema Definition
Statistics
Parsed Query (from Parser)
Transformed Query
Query + Estimates
Init.ora parameter to control behavior:
OPTIMIZER_FEATURES_ENABLED
OR Expansion
View Merging
Predicate Pushing
Subquery Unnesting
Query Rewrite with
Materialized Views
Star Transformation
In-Memory Aggregation
Table Expansion
Join Factorization

Execution Plan
• Show the sequence of operations performed to run SQL Statement
• Order of the tables referenced in the statements
• Access method for each table in the statement
• INDEX
• INLIST ITERATOR
• TABLE ACCESS
• VIEW
• Join method in accessing multiple tables
• HASH JOIN
• MERGE JOIN
• NESTED LOOPS
• Data manipulations
• CONCATENATION
• COUNT
• FILTER
• SORT
• Statistic Collectors
• New in 12C

Execution Plan
• Optimizer instruments default plan with statistics collector (SC)
• SC buffers a portion of rows coming into each sub-plan on initial execution
• Optimizer computes inflection points
• Determines optimal join type
• At runtime
• Works only on:
• Join Methods
• Nested loops and hash joins
• Parallel Distribution Method
• No adaptation occurs
• If initial join is sort merge join

Optimizer Computes Inflection Points (IPs)
• IPs are statistics where two plan choices are equally good
CBO trace or
10053 event
(see appendix)

Optimizer Computes Inflection Points – cont.
• NLJ vs. HJ plans are equally good
• When cardinality = 8.48
Nested Loop
Join
Hash
Join
Order_Items
Table Scan
Statistics
Collector
Product
Index Scan
Product
Table Scan

How To Identify Adaptive Plans
• New columns in V$SQL:
• IS_RESOLVED_ADAPTIVE_PLAN
• If ‘Y’, the plan was adapted & is the final plan
• If ‘N’, the plan is adaptive
• But final plan has not been selected
• If NULL, the plan is non-adaptive
• IS_REOPTIMIZABLE is for next execution
• Y - the next execution will trigger a reoptimization
• R – has reoptimization info
• But won’t trigger due to reporting mode
• N -the child cursor has no reoptimization info
alter (system / session) set optimizer_adaptive_reporting_only=TRUE;

Why Plans Changes
• Execution plans can change as underlying inputs to optimizer change
• Same Sql – Different Schemas
• Different table sizes / statistics / indexes
• Same Sql – Different Costs
• Data volume & Statistic Changes over time
• Bind variable types and values
• Initialization parameters (set globally or session level)
• Adaptive Cursor Sharing – 11G
• V$SQL - IS_BIND_SENSITIVE: optimizer peeked –plan may change
• V$SQL - IS_BIND_AWARE: ‘Y’ after query has been marked bind sensitive
• Adaptive Plans / Statistics – 12C
• V$SQL_SHARED_CURSOR
• Can give clues to why plan changed
• 70 columns showing mismatches /differences
• Hard to view
• Script, ‘shared_proc.sql’ in appendix

V$SQL_SHARED_CURSOR
• Shared_proc.sql script in appendix
Explain Plans
are blind to
bind variables
Adaptive
Reporting
Only Mode

Get Real Execution Plan (reporting_only)

Get Real Execution Plan
• Optimizer Mismatch

Adaptive Cursor Sharing
• V$SQL_CS_SELECTIVITY (BIND AWARE)
• V$SQL_CS_HISTOGRAM
• Summary of monitoring
• Three buckets (S/M/L)
• V$SQL_CS_STATISTICS
• Show rows processed
• Empty in 12.2?
:b1 = 1000000.5
:b1 = 150.0
:b1 = 1.05

Parallel Distribution Method
• Optimizer must distribute data across all parallel processes
• Parallel queries are useful for sorts, aggregation & join operations
• Optimizer chooses between broadcast or hybrid hash (NEW in 12c)
• Chosen method depends on number of rows and Degree of Parallelism (DOP)
• Hybrid hash, if rows > than threshold
• Broadcast, if rows < than threshold
• Threshold is defined as 2 X DOP
• Optimizer decides final data distribution method during each execution time
• Different from adaptive joins which are limited to first execution only
• Statistic collectors are inserted in front of the parallel server processes
• On producer side of the operation
• Hybrid hash distribution can help with data skew
• Potential performance problem if few parallel processes distribute many rows

Parallel Distribution - Hybrid Hash Example
• Alter session set optimizer_adaptive_statistics = TRUE;

• Other parameters
• parallel_degree_policy (Manual)
• Can be Adaptive or Auto
• parallel_adaptive_multi_user
• parallel_degree_limit
• parallel_min_time_threshold
• v$pq_tqstat
• Valid only in current session
• Shows message traffic
• At table queue level

Bitmap Index Pruning (Star Schemas)
• Adaptive plans will prune out insufficient bitmap indexes
• STAR_TRANSFORMATION_ENABLED parameter must be enabled (TRUE)
• Default is FALSE
• Hidden parameter: _optimizer_strans_adaptive_pruning
• see appendix for script to get all 12.2 hidden optimizer parameters
• If optimizer generates a star transformation plan
• Needs to decide which bitmap indexes to use
• If too many indexes, some may not reduce the numbers of rows returned
• Can cause unnecessary cost and overhead
US DOT - On-time Performance

Bitmap Index Pruning

Adaptive Statistics: Quality of Plan = Quality of Statistics
• Optimizer can re-optimize a query several times
• Learning more info and further improving the plan
• Dynamic statistics
• Automatic reoptimization
• Statistics feedback
• Sql plan directives
What’s wrong
with these
pictures?

Dynamic Statistics
• Augment missing or insufficient base table statistics
• Table / index block counts
• Table / join cardinalities (estimated number of rows)
• Join column statistics
• GROUP BY statistics
• Are gathered during the parse stage
• Uses recursive SQL to scan a random sample of table blocks
• Statistics gathered are not as high a quality as DBMS_STATS
• Due to sampling
• Controlled by dynamic sampling init.ora parameter
• OPTIMIZER_DYNAMIC_SAMPLING
• New in 12.1 - level 11
• Automatically controls the creation of dynamic statistics
• Results are stored to minimize performance impact
• 12.1 - In Server Result Cache
• 12.2 - As SQL Plan Directive
alter session set OPTIMIZER_DYNAMIC_SAMPLING = 11;

Dynamic Statistics Example
Estimates
2X off!
Notes:
Parse time takes longer.
Results are persisted &
used elsewhere

Statistics Feedback
• Optimizer enables monitoring for statistics feedback when
• Missing statistics, inaccurate statistics, or complex predicates
• Such as multiple conjunctive or disjunctive filter predicates on a table
• After 1st execution, estimates are compared with actual rows
• If they differ significantly, optimizer stores correct estimates for future use
• Stored as OPT_ESTIMATE hints in V$SQL_REOPTIMIZATION_HINTS
• Can create a SQL PLAN DIRECTIVE for other SQL statements
• If they differ, the cursor is marked IS_REOPTIMIZABLE
• IS_REOPTIMIZABLE column in V$SQL is updated to ‘Y’
• Cursor will not be used again
• After 1st execution, optimizer disables statistics collectors
• Next execution will incur a hard parse
• Optimizer uses the statistics found during 1st execution to determine better plan

Statistics Feedback Example

Statistics Feedback Example – Cont.

Performance Feedback
• Automatically improves the degree of parallelism
• Init.ora parameter, PARALLEL_DEGREE_POLICY = ’ADAPTIVE’
• On 1st execution, the optimizer decides
• Whether to execute the statement in parallel
• The degree of parallelism based on estimates
• After 1st execution, optimizer compares
• Estimates with actual performance statistics
• e.g. CPU Time
• i.e. PARALLEL_MIN_TIME_THRESHOLD
• If significantly different, the statement
• Cursor is marked for reparsing
• New execution statistics are stored as feedback
• Following executions use the performance feedback to determine DOP
• If PARALLEL_DEGREE_POLICY not set, statistics feedback may change DOP

Performance Feedback – Strange Behavior
• OPTIMIZER_ADAPTIVE_STATISTICS
• Set to FALSE by default
• Can set to TRUE to enable adaptive parallel distribution
• Dynamic sampling for parallel query
• Statistics feedback
• PARALLEL_DEGREE_POLICY
• Set to MANUAL by default
• Must be ADAPTIVE
• To enable Performance feedback
• Check hidden parameter _OPTIMIZER_PERFORMANCE_FEEDBACK
• Must be set to ALL
• http://www.oaktable.net/content/activating-and-deactivating-performance-feedback

Performance Feedback
select tq_id , cast(server_type as varchar2(10)) as server_type
, instance , cast(process as varchar2(8)) as process, num_rows
, round(ratio_to_report(num_rows)
over (partition by dfo_number, tq_id, server_type) * 100) as "%"
, cast(rpad('#', round(num_rows * 10 / nullif(max(num_rows)
over (partition by dfo_number, tq_id, server_type), 0)), '#') as varchar2(10)) as
graph
, round(bytes / 1024 / 1024) as mb
, round(bytes / nullif(num_rows, 0)) as "bytes/row"
from v$pq_tqstat
order by dfo_number , tq_id , server_type desc , instance , process;

SQL Plan Directives
• Are additional instructions for missing column group statistics or histograms
• The optimizer performs dynamic sampling on directive
• Until statistics are gathered for the column group or extension
• Not tied to a specific sql statement – defined on a query expression
• Can be used by similar queries (e.g. city, state, zip in where clause)
• Are created in shared_pool & periodically written to the SYSAUX tablespace
• DBA_SQL_PLAN_DIRECTIVES
• DBA_SQL_PLAN_DIR_OBJECTS
• DBMS_SPD package
SELECT TO_CHAR(d.directive_id) dir_id,
o.owner, o.object_name, o.subobject_name col_name,
o.object_type, d.type,d.state,d.reason
FROM dba_sql_plan_directives d, dba_sql_plan_dir_objects o
WHERE d.directive_id = o.directive_id
AND o.owner IN ('SOE') ORDER BY 1,2,3,4,5;

SQL Plan Directives
• Must enable adaptive statistics
• New directive type in 12.2 - DYNAMIC_SAMPLING_RESULTS
• Results are stored for future use
• Need to turn on feature to automatically create extended statistics
• exec DBMS_STATS.SET_PARAM ('AUTO_STAT_EXTENSIONS','ON');

12c Statistic Gathering
• Automatically gathered
• Index, insert append, CTAS

Understand Statistics Gathering
• GATHER_*_STATS procedures have many parameters
• Consider taking the default values
• exec dbms_stats.gather_schema_stats(‘SOE’);
• New 12.2 optimizer statistics advisor
• Based on 23 predefined rules
• V$STATS_ADVISOR_RULES
• Run using DBMS_STATS
• View tasks in DBA_ADVISOR_TASKS
• Makes recommendations on collecting stats
• Can generate scripts for statistics gathering
• Uses statistic gathering best practices
• Advisor scripts on next slides
GET_PREFS function
DBMS_STATS package
• Rewritten in 11g
• A Faster & better AUTO_SAMPLE_SIZE
• 100% in less time & more accurate than 10%
estimate
• Avoid using ESTIMATE_PERCENT
select
dbms_stats.get_prefs('PREFERENCE_OVERRIDES_PARAMETER')
from dual;

Optimizer Statistics Advisor
1. Create task 2. Define filters>
3. Execute task
EXEC DBMS_STATS.DROP_ADVISOR_TASK('STAT_ADVICE');
DECLARE
task_name VARCHAR2(100);
results VARCHAR2(32767);
BEGIN
task_name := 'STAT_ADVICE';
results := DBMS_STATS.CREATE_ADVISOR_TASK(task_name);
END;
/
select task_name, advisor_name, created, status from
dba_advisor_tasks where advisor_name = 'Statistics Advisor‘;
filter1 CLOB; -- disable advisor on all objects
filter2 CLOB; -- enable advice on SOE.ORDER_LINE
filter3 CLOB; -- disable rule AvoidDropRecreate
filter4 CLOB; -- enable rule UseGatherSchemaStats
BEGIN
filter1 := DBMS_STATS.CONFIGURE_ADVISOR_OBJ_FILTER(
task_name => 'STAT_ADVICE',
stats_adv_opr_type => 'EXECUTE',
rule_name => NULL,
ownname => NULL,
tabname => NULL,
action => 'DISABLE' );
filter2 := DBMS_STATS.CONFIGURE_ADVISOR_OBJ_FILTER(
rule_name => NULL,
ownname => 'SOE',
tabname => 'ORDER_LINE',
action => 'ENABLE' );
filter3 := DBMS_STATS.CONFIGURE_ADVISOR_RULE_FILTER(
rule_name => 'AvoidDropRecreate',
action => 'DISABLE' );
filter4 := DBMS_STATS.CONFIGURE_ADVISOR_RULE_FILTER(
rule_name => 'UseGatherSchemaStats',
action => 'ENABLE' );
END;
/
DECLARE
results VARCHAR2(32767);
BEGIN
results := DBMS_STATS.EXECUTE_ADVISOR_TASK(task_name);
END;
/

Optimizer Statistics Advisor – Cont.
4. Report task 6. Display script>
5. Generate script
set pagesize 1000
set linesize 132
set long 1000000
select dbms_stats.report_advisor_task('STAT_ADVICE',null,'text','all','all') as report from dual;
VAR script CLOB
DECLARE
BEGIN
:script := DBMS_STATS.SCRIPT_ADVISOR_TASK(task_name);
END;
/
set linesize 132
set long 100000
set pagesize 0
set longchunksize 100000
set serveroutput on
DECLARE
v_len NUMBER(10);
v_offset NUMBER(10) :=1;
v_amount NUMBER(10) :=10000;
BEGIN
v_len := DBMS_LOB.getlength(:script);
WHILE (v_offset < v_len)
LOOP
DBMS_OUTPUT.PUT_LINE(DBMS_LOB.SUBST
R(:script,v_amount,v_offset));
v_offset := v_offset + v_amount;
END LOOP;
END;
/

Optimizer Statistics Advisor Report

Optimizer Statistics Advisor Script

SQL Plan Management (Baselines)
• 12.1 SPM/Baseline Changes
• SPM evolve advisor is an Auto Task (SYS_AUTO_SPM_EVOLVE_TASK)
• Runs nightly in maintenance window
• Automatically runs the evolve process for non-accepted plans in SPM
• DBA views results of nightly task using DBMS_SPM.REPORT_AUTO_EVOLVE_TASK
• Can Manage via OEM or DBMS_AUTO_TASK_ADMIN
• Still can manually evolve an unaccepted plan using OEM or DBMS_SPM
• DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE has been deprecated but still there
• 12.2 New ability to limit which SQL statements are captured using filters
alter system set optimizer_capture_sql_plan_baselines=true;
exec dbms_spm.configure(‘AUTO_CAPTURE_PARSING_SCHEMA_NAME’,’SOE’, true);

SQL Plan Management
• 12.2 Can manually capture baselines from AWR
• DBMS_SPM.LOAD_PLANS_FROM_AWR
• Takes begin and end snapshots
• How SPM works with adaptive plans
• If auto-capture is enabled
• Only the final plan is captured in baseline
• When unaccepted adaptive plans evolve, the optimizer considers all subplans
• If 1.5x better than existing baseline, the plan is accepted
• Accepted plans are never adaptive
• How SPM works with adaptive cursor sharing (ACS)
• If auto-capture is enabled, only one plan will be accepted
• Recommendation is to manually load and accept all possible plans
• So ACS will work
• Otherwise the cursor will not be marked bind sensitive
• Because the baseline will prevent it

Approximate Query Processing
• Used for approximate ‘count distinct’ values and adds percentile aggregation
• Allows for faster processing of large data sets
• Not exact but usually within 95%+ range
• Three new parameters – alter system/session
• approx_for_aggregation Default=FALSE
• Can be overridden by the next 2 parameters
• If true, sets approx_for_percentile=ALL
• approx_for_count_distinct Default=FALSE
• Overrides exact COUNT DISTINCT clause
• approx_for_percentile Default=NONE
• Overrides MEDIAN clause (PERCENTILE_CONT)
• Values can be PERCENTILE_CONT, PERCENTILE_DISC, and ALL
• Can be used without any changes to existing code
• Replaces exact functions with SQL functions that return approximate results

New SQL functions in 12.2
• Approximate query functions
• APPROX_COUNT_DISTINCT (Introduced in 12.1)
• APPROX_COUNT_DISTINCT_DETAIL
• APPROX_COUNT_DISTINCT_AGG
• TO_APPROX_COUNT_DISTINCT
• APPROX_MEDIAN
• APPROX_PERCENTILE
• APPROX_PERCENTILE_DETAIL
• APPROX_PERCENTILE_AGG
• TO_APPROX_PERCENTILE
• Also in 12.2, support for approximate query functions
• For materialized views and subsequent query rewrites

Approximate SQL Example
95% accurate

Approximate SQL Example With Changing Code
Why is it exact?
Need to
set both

Approximate Percentile Example With Changing Code
99.68% accurate

Summary
• The 12.2 Optimizer is getting smarter and easier to control
• Two new parameters
• Optimizer_adaptive_plans (true)
• New feature: bitmap index pruning
• Optimizer_adaptive_statistics (false)
• Controls SQL plan directives, statistics feedback for joins,
• Performance feedback, dynamic sampling for parallel query
• Plans can and do change
• V$SQL_SHARED_CURSOR can help find out the why
• New 12.2 optimizer statistics advisor can help fine-tune statistics gathering
• SQL plan management
• Can filter which SQL gets captured for baselines
• Approximate query processing
• Consider this for analytic queries

The SolarWinds, SolarWinds & Design, Orion, and THWACK trademarks are the exclusive
property of SolarWinds Worldwide, LLC or its affiliates, are registered with the U.S.
Patent and Trademark Office, and may be registered or pending registration in other
countries. All other SolarWinds trademarks, service marks, and logos may be common
law marks or are registered or pending registration. All other trademarks mentioned
herein are used for identification purposes only and are trademarks of (and may be
registered trademarks) of their respective companies.
Thank You!!!

www.solarwinds.com/dpa-download/
Resolve Performance Issues quickly—Free Trial
• Try Database Performance Analyzer FREE for 14 days
• Improve root cause of slow performance
o Quickly identify root cause of issues that impact end-user
response time
o See historical trends over days, months, and years
o Understand impact of VMware® performance
o Agentless architecture with no dependence on Oracle Packs,
installs in minutes

Appendix
• CBO trace or 10053 event
• Edit *&trc_name*.trc
-- trc.sql
alter session set tracefile_identifier='&trc_name';
exec dbms_sqldiag.dump_trace(p_sql_id=>'&sql_id',p_child_number=>&child,p_component=>'Compiler',p_file_id=>'');

Appendix
• 10053 Event TreeViewer UI (2011 but still works)
• https://jonathanlewis.files.wordpress.com/2011/12/tvzip1.doc

Appendix
--shared_proc.sql --formats output from v$sql_shared_cursor
set serverout on size 1000000
Declare
c number;
col_cnt number;
col_rec dbms_sql.desc_tab;
col_value varchar2(4000);
ret_val number;
Begin
c := dbms_sql.open_cursor;
dbms_sql.parse(c,'select q.sql_text, s.* from v$sql_shared_cursor s, v$sql q where s.sql_id = q.sql_id
and s.child_number = q.child_number and q.sql_id = ''&1''', dbms_sql.native);
dbms_sql.describe_columns(c, col_cnt, col_rec);
for idx in 1 .. Col_cnt loop
dbms_sql.define_column(c, idx, col_value, 4000);
end loop;
ret_val := dbms_sql.execute(c);
while(dbms_sql.fetch_rows(c) > 0) loop
for idx in 1 .. Col_cnt loop
dbms_sql.column_value(c, idx, col_value);
if col_rec(idx).col_name in ('SQL_ID', 'ADDRESS', 'CHILD_ADDRESS','CHILD_NUMBER', 'SQL_TEXT', 'REASON') then
dbms_output.put_line(rpad(col_rec(idx).col_name, 30) || ' = ' || col_value);
elsif col_value = 'Y' then
dbms_output.put_line(rpad(col_rec(idx).col_name, 30) || ' = ' || col_value);
end if;
end loop;
dbms_output.put_line('--------------------------------------------------');
end loop;
dbms_sql.close_cursor(c);
End;
/

Appendix
• 191 _optimizer_* hidden parameters
• OPTIMIZER_ADAPTIVE_PLANS control:
• _OPTIMIZER_NLJ_HJ_ADAPTIVE_JOIN
• _PX_ADAPTIVE_DIST_METHOD
• _OPTIMIZER_STRANS_ADAPTIVE_PRUNING
• OPTIMIZER_ADAPTIVE_STATISTICS controls:
• _OPTIMIZER_GATHER_FEEDBACK
• _OPTIMIZER_USE_FEEDBACK
• _OPTIMIZER_DSDIR_USAGE_CONTROL
• _OPTIMIZER_USE_FEEDBACK_FOR_JOIN
• _OPTIMIZER_ADS_FOR_PQ
• Many others not listed
-- hidden.sql
COLUMN ksppinm FORMAT A50
COLUMN ksppstvl FORMAT A50
SELECT
ksppinm,
ksppstvl
FROM
x$ksppi a,
x$ksppsv b
WHERE
a.indx=b.indx
AND
substr(ksppinm,1,1) = '_'
and ksppinm like '_opt%'
ORDER BY ksppinm;

Getting the most out of your Oracle 12.2 Optimizer (i.e. The Brain)

More Related Content

What's hot (20)

Similar to Getting the most out of your Oracle 12.2 Optimizer (i.e. The Brain) (20)

More from SolarWinds (20)

Recently uploaded (20)

Getting the most out of your Oracle 12.2 Optimizer (i.e. The Brain)