SlideShare a Scribd company logo
1 of 53
Adaptive Query Optimization
Sangam 14 Anju Garg 1
ANJU GARG
About me
Sangam 14 Anju Garg
• More than 11 years of experience in IT Industry
• Sr. Corporate Trainer (Oracle DBA) with Koenig Solutions Ltd.
• Oracle blog : http://oracleinaction.com/
• Email : anjugarg66@gmail.com
• Oracle Certified Expert
2
Agenda
• Drawbacks of Pre-12c optimizer
• What's New in 12c?
 Adaptive Query Optimization
 Adaptive / Dynamic Plans
 Automatic Re-optimization
o SQL Plan Directives
 Automatic Query Optimization workflow
• Illustration-I : Cardinality Feedback in 11g
• Illustration-II : Adaptive plans in 12c
• Illustration-III : Automatic Re-optimization-I
• Illustration-IV : Automatic Re-optimization-II
• Conclusion
• References
• Q & A Sangam 14 Anju Garg 3
Pre-12c optimizer
Sangam 14 Anju Garg 4
• Drawbacks
– Insufficient or stale statistics do not trigger dynamic sampling
with default sampling level of 2.
– SQL has to execute sub-optimally at least once to exploit ACS and
Cardinality Feedback.
– Cardinality feedback cannot be employed after cursor ages out.
What's New in 12c?
Adaptive Query Optimization
– Adaptive / Dynamic plans
 Initial execution of a query improved by making run-time
adjustments to execution plan.
– Automatic Re-optimization
 Information gathered during initial execution is employed to
improve subsequent executions of SQL.
Sangam 14 Anju Garg 5
Adaptive Plans
• The default plan chosen at parse time switched to a better alternative plan
called final plan at run-time.
• Information found via dynamic plans is persisted as SQL plan directives
• Can dynamically change
– Join method between Nested Loops and Hash Join
– Parallel Query Distribution Method between Hash and Broadcast
• When?
– Initial cardinality misestimates
– Default and final plans have the same starting point.
• How?
– Optimizer stores alternative sub-plans with the cursor.
– Computes threshold cardinality.
– Statistic collectors embedded at critical points in the default execution
plan.
– Switches to an alternative plan, if row count crosses the threshold.
Sangam 14 Anju Garg 6
Automatic Re-optimization
Sangam 14 Anju Garg
7
• CBO switches to a better plan during subsequent executions.
• When?
– Optimizer requires more information than base table statistics.
– Adaptive Plans cannot be employed as default and final plans have the
different starting points.
• How?
– Information learnt during initial execution persisted in SPD and employed
during subsequent executions.
– Augmented statistics used to improve subsequent executions.
– if (identical query and cursor is cached)
Use statistics feedback
else (Similar query or cursor has aged out)
if column group statistics gathered
Use column group statistics
else
Use dynamic statistics
SQL Plan Directives (SPD)
• A key component of Automatic Query optimization framework.
• Created as a result of significant cardinality misestimates during the execution
of a SQL .
• Assist the optimizer in generating a more optimal plan for future executions of
the statement
– Record missing group statistics. Subsequent DBMS_STATS calls result in
creation of column groups automatically.
– Instruct the optimizer to use column group statistics if they have been
gathered , else perform dynamic sampling.
• Defined for a query expression.
• Not tied to a specific SQL statement.
• Applicable to multiple SQL statements with similar predicates.
Sangam 14 Anju Garg 8
Adaptive Query Optimization workflow
Sangam 14 Anju Garg
9
Illustration - I
Cardinality Feedback in 11g
Sangam 14 Anju Garg 10
Illustration - I: Cardinality Feedback in 11g
• What to expect?
• Cardinality feedback usage by a SQL
• Cardinality estimate aging out with cursor
Sangam 14 Anju Garg 11
Illustration - I: Cardinality Feedback in 11g
• Basic Statistics gathered
• Complex predicates
• Optimizer estimates EMP table to return 5 rows (Actual = 2 rows)
• Parse time Plan Join Method : Hash Join.
DB11g>explain plan for
select /*+ monitor*/ department_name
from emp e, dept d
where e.dept_id = d.department_id
and e.salary > 1000
and e.name like 'J%‘
and d.department_id > 10;
select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
Plan hash value: 3249786240
-----------------------------------------------------------------------------
| Id | Operation | Name |Rows|Bytes|Cost %CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 5 |155 |6 (17)|0:00:01 |
|* 1 | HASH JOIN | | 5 |155 |6 (17)|00:00:01|
|* 2 | TABLE ACCESS FULL |EMP | 5 | 75 |3 (0)|00:00:01|
| 3 | TABLE ACCESS BY INDEX ROWID|DEPT |26 |416 |2 (0)|00:00:01|
|* 4 | INDEX RANGE SCAN |DEPT_ID_IDX|26 | |1 (0)|00:00:01|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
2 - filter("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)
4 - access("D"."DEPARTMENT_ID">10)
Sangam 14 Anju Garg
12
Illustration - I: Cardinality Feedback in 11g
• First execution of query – misestimates 5 rows to be returned (Actual = 2 rows)
• Final Plan Join Method : Hash Join (same as parse time plan)
DB11g>select /*+ monitor*/ department_name
from emp e, dept d
where e.dept_id = d.department_id
and e.salary > 1000
and e.name like 'J%'
and d.department_id > 10;
select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 09daa1tu337ca, child number 1
-------------------------------------
select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000
and e.name like 'J%' and d.department_id > 10
Plan hash value: 3249786240
-----------------------------------------------------------------------------
| Id| Operation | Name |Rows|Bytes|Cost(%CPU)|Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | |6 (100)| |
|* 1 | HASH JOIN | | 5 | 155 |6 (17)| 0:00:01|
|* 2 | TABLE ACCESS FULL |EMP | 5 | 75 |3 (0)|00:00:01|
| 3 | TABLE ACCESS BY INDEX ROWID|DEPT | 26 | 416 |2 (0)|00:00:01|
|* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 26 | |1 (0)|00:00:01|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
2 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000))
4 - access("D"."DEPARTMENT_ID">10)
Sangam 14 Anju Garg 13
Illustration - I: Cardinality Feedback in 11g
• Second execution of the query employs cardinality feedback (cursor cached)
• No. of rows returned by EMP accurately estimated to be 2
• Join method changes to Nested Loops.
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 09daa1tu337ca, child number 2
-------------------------------------
select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary >
1000 and e.name like 'J%' and d.department_id > 10
Plan hash value: 1970561632
-----------------------------------------------------------------------------
| Id | Operation |Name |Rows|Bytes|Cost(%CPU)|Time |
-----------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | | |5 (100)| |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 2 | 62 |5 (0)| 00:00:01|
|* 3 | TABLE ACCESS FULL |EMP | 2 | 30 |3 (0)| 00:00:01|
|* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 1 | |0 (0)| |
| 5 | TABLE ACCESS BY INDEX ROWID|DEPT | 1 | 16 |1 (0)| 00:00:01|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000))
4 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
filter("D"."DEPARTMENT_ID">10)
Note
-----
- cardinality feedback used for this statement
Sangam 14 Anju Garg 14
Illustration - I: Cardinality Feedback in 11g
• Flush shared pool
• Third execution of the query : Optimizer misestimates cardinality again
(Execution statistics aged out with the cursor)
• Sub-optimal Join method (Hash join) chosen again
DB11g> alter system flush shared_pool;
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 09daa1tu337ca, child number 0
-------------------------------------
select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000
and e.name like 'J%' and d.department_id > 10
Plan hash value: 3249786240
-----------------------------------------------------------------------------
|Id | Operation | Name |Rows|Bytes|Cost(%CPU)|Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | |6(100)| |
|* 1 | HASH JOIN | | 5 | 155|6 (17)| 00:00:01|
|* 2 | TABLE ACCESS FULL |EMP | 5 | 75|3 (0)| 00:00:01|
| 3 | TABLE ACCESS BY INDEX ROWID|DEPT | 26 | 416|2 (0)| 00:00:01|
|* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 26 | |1 (0)| 00:00:01|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
2 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000))
4 - access("D"."DEPARTMENT_ID">10)
Sangam 14 Anju Garg 15
Illustration - I : Cardinality Feedback in 11g
Sangam 14 Anju Garg 16
Summary:
• In case of significant cardinality misestimates, execution statistics are stored in
the cursor itself.
• Until cursor is cached, Cardinality feedback is used during subsequent
executions.
• After the cursor ages out, cardinality estimate is lost and optimizer again
misestimates cardinality.
Illustration - II
Adaptive Plans in 12c
Sangam 14 Anju Garg 17
Illustration - II : Adaptive Plans in 12c
Sangam 14 Anju Garg
18
What to expect?
• Initial cardinality misestimate
• Run-time changes to execution plan during
first execution of query
• Cursor marked re-optimizable
• SQL plan directive created
Illustration - II: Adaptive Plans in 12c
• Parse time plan: Initial cardinality misestimate (5 rows)
– Default Plan Join Method : Hash Join (same as 11g)
– Note - this is an adaptive plan
DB12c>explain plan for
select /*+ monitor*/ department_name
from emp e, dept d
where e.dept_id = d.department_id
and e.salary > 1000
and e.name like 'J%'
and d.department_id > 10;
select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
Plan hash value: 1074770502
-----------------------------------------------------------------------------
|Id |Operation |Name |Rows|Bytes|Cost(%CPU)| Time |
-----------------------------------------------------------------------------
| 0|SELECT STATEMENT | | 5|155 |5(0)| 00:00:01|
|* 1| HASH JOIN | | 5|155 |5(0)| 00:00:01 |
|* 2| TABLE ACCESS FULL |EMP | 5|75 |3(0)| 00:00:01 |
| 3| TABLE ACCESS BY INDEX ROWID BATCHED|DEPT | 26|416 |2(0)| 00:00:01 |
|* 4 INDEX RANGE SCAN |DEPT_ID_IDX| 26| |1(0)| 00:00:01 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
2 - filter("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)
4 - access("D"."DEPARTMENT_ID">10)
Note
-----
- this is an adaptive plan
Sangam 14 Anju Garg 19
Initial cardinality
misestimate
Illustration - II: Adaptive Plans in 12c
Sangam 14 Anju Garg 20
•First execution : Join method changes from hash to nested loops at run-time.
– A statistics collector inserted in the plan
– Note : " this is an adaptive plan (rows marked '-' are inactive)“
Note : Output continued on next slides
Run-time changes
to plan
Illustration - II : Adaptive Plans in 12c
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 09daa1tu337ca, child number 0
-------------------------------------
select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000
and e.name like 'J%' and d.department_id > 10
Plan hash value: 1970561632
-----------------------------------------------------------------------------------------------
| Id | Operation | |Rows|Bytes|Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 5 (100)| |
|- * 1 | HASH JOIN | | 5 | 155| 5 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 5 | 155| 5 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | | | | |
|- 4 | STATISTICS COLLECTOR | | | | | |
| * 5 | TABLE ACCESS FULL |EMP | 5 | 75| 3 (0)| 00:00:01 |
| * 6 | INDEX RANGE SCAN |DEPT_ID_IDX | 26 | | 1 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID |DEPT | 1 | 16| 2 (0)| 00:00:01 |
|- 8 | TABLE ACCESS BY INDEX ROWID BATCHED|DEPT | 26 | 416| 2 (0)| 00:00:01 |
|- * 9 | INDEX RANGE SCAN |DEPT_ID_IDX | 26 | | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
5 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000))
6 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
filter("D"."DEPARTMENT_ID">10)
9 - access("D"."DEPARTMENT_ID">10)
Note
-----
- this is an adaptive plan (rows marked '-' are inactive)
Continued ...
Sangam 14 Anju Garg 21
Run-time changes
to plan
Illustration - II : Adaptive Plans in 12c
Continued from last slide ...
Reoptimized plan:
-----------------
This cursor is marked for automatic reoptimization. The plan that is
expected to be chosen on the next execution is displayed below.
Plan hash value: 1970561632
-----------------------------------------------------------------------------
|Id |Operation | Name |Rows|Bytes|Cost(%CPU)| Time|
-----------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | 1| 31| 5(0)| 00:00:01 |
| 1 | NESTED LOOPS | | 1| 31| 5(0)| 00:00:01 |
| 2 | NESTED LOOPS | | 2| 31| 5(0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL |EMP | 2| 30| 3(0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 1| | 0(0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID|DEPT | 1| 16| 1(0)| 00:00:01 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)
4 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
filter("D"."DEPARTMENT_ID">10)
Sangam 14 Anju Garg 22
– The plan expected to be chosen on the next execution
uses Nested Loops join
Note : Cursor marked
for re-optimization
Illustration - II : Adaptive Plans in 12c
• IS_RESOLVED_ADAPTIVE_PLAN = Y
– Adaptive Plan
• IS_REOPTIMIZABLE=Y
– Cursor marked for automatic re-optimization – will be hard parsed next time
DB12c>select sql_id, child_number, sql_text,
is_resolved_adaptive_plan resolved_adaptive_plan,
IS_REOPTIMIZABLE reoptimizable
from v$sql
where sql_id = '09daa1tu337ca';
SQL_ID CHILD_NUMBER SQL_TEXT RESOLVED_ADAPTIVE_PLAN REOPTIMIZABLE
------------- ------------ ----------------------------- ---------------------- -------------
09daa1tu337ca 0 select /*+ monitor*/ Y Y
department_name from
emp e, dept d where e
.dept_id = d.department_id
and e.salary > 1000
and e.name like 'J%'
and d.department_id
> 10
Sangam 14 Anju Garg 23
Cursor marked for
re-optimization
Illustration - II : Adaptive Plans in 12c
Sangam 14 Anju Garg
24
• The information learnt via dynamic plans is persisted as a SQL directive.
• Cardinality misestimates on columns DEPT_ID, NAME and SALARY of EMP table .
• On subsequent executions dynamic sampling should be performed.
DB12c> exec dbms_spd.flush_sql_plan_directive
select o.object_name object, 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 ('HR')
and o.object_name in ('EMP','DEPT')
order by object_type;
OBJECT COL_NAM OBJECT TYPE STATE REASON
------ ------- -------- ---------------- ------ ------------------------------------
EMP NAME COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE
EMP DEPT_ID COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE
EMP SALARY COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE
EMP xx TABLE DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE
SPD created
Illustration - II : Adaptive Plans in 12c
Summary:
• In case of initial cardinality misestimates, Adaptive Plans can change the
execution plan at run time during the first execution itself.
• The resulting cursor is marked for re-optimization and execution statistics are
stored in the cursor.
• Information learnt via Adaptive Plans is persisted as SQL Plan Directive.
Sangam 14 Anju Garg 25
Illustration - III
Automatic Re-optimization-I
Sangam 14 Anju Garg 26
Illustration – III: Automatic Re-optimization-I
Sangam 14 Anju Garg 27
What to expect?
•During subsequent executions of query
 Until cursor is cached, Statistics feedback is
used.
 After cursor ages out, SPD is checked and
Dynamic sampling is performed.
 SPD can be used for similar statements.
Illustration – III: Automatic Re-optimization-I
• Second Execution
– Buffering of rows by collector disabled.
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 09daa1tu337ca, child number 1
-------------------------------------
select /*+ monitor*/ department_name from emp e, dept
d where e.dept_id = d.department_id and e.salary >
1000 and e.name like 'J%' and d.department_id > 10
Plan hash value: 1970561632
-----------------------------------------------------------------------------
|Id |Operation |Name |Rows |Bytes|Cost(%CPU)|Time |
-----------------------------------------------------------------------------
| 0|SELECT STATEMENT | | | | 5 (100)| |
| 1| NESTED LOOPS | | 1 | 31| 5 (0)|00:00:01|
| 2| NESTED LOOPS | | 2 | 31| 5 (0)|00:00:01|
|* 3| TABLE ACCESS FULL |EMP | 2 | 30| 3 (0)|00:00:01|
|* 4| INDEX RANGE SCAN |DEPT_ID_IDX| 1 | | 0 (0)| |
| 5 TABLE ACCESS BY INDEX ROWID|DEPT | 1 | 16| 1 (0)|00:00:01|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000))
4 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
filter("D"."DEPARTMENT_ID">10)
Note
-----
- statistics feedback used for this statement
Sangam 14 Anju Garg
28
Issue SQL second time
Cursor cached
Use statistics feedback
Illustration-III: Automatic Re-optimization-I
• SQL Plan directive persists even after shared pool is flushed.
• Performs dynamic sampling with appropriate level (2) even
though basic statistics exist.
DB12c> alter system flush shared_pool;
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 09daa1tu337ca, child number 0
-------------------------------------
select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name
like 'J%' and d.department_id > 10
Plan hash value: 1970561632
----------------------------------------------------------------------------
|Id |Operation |Name |Rows|Bytes|Cost(%CPU)| Time|
|---------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | | | 5(100)| |
| 1 | NESTED LOOPS | | 2 | 62 | 5(0) |00:00:01|
| 2 | NESTED LOOPS | | 2 | 62 | 5(0) |00:00:01|
|* 3 | TABLE ACCESS FULL |EMP | 2 | 30 | 3(0) |00:00:01|
|* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 1 | | 0(0) | |
| 5 | TABLE ACCESS BY INDEX ROWID|DEPT | 1 | 16 | 1(0) |00:00:01|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000))
4 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
filter("D"."DEPARTMENT_ID">10)
Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- this is an adaptive plan
- 1 Sql Plan Directive used for this statement
Sangam 14 Anju Garg 29
Cursor flushed out
Subsequent execution
Check directive
Use dynamic Statistics
Illustration - II: Automatic Re-optimization-I
• Hard parse results in an new cursor
• Cannot be optimized further (IS_REOPTIMIZABLE = N)
• Will be used for subsequent executions until cached.
DB12c>select sql_id, child_number, sql_text, IS_REOPTIMIZABLE reoptimizable
from v$sql
where sql_id = '09daa1tu337ca';
SQL_ID CHILD_NUMBER SQL_TEXT REOPTIMIZABLE
------------- ------------ ------------------------------ -------------
09daa1tu337ca 0 select /*+ monitor*/ Y
department_name from
emp e, dept d where e
.dept_id = d.department_id
and e.salary > 1000
and e.name like 'J%'
and d.department_id
> 10
09daa1tu337ca 1 select /*+ monitor*/ N
Sangam 14 Anju Garg
30
Illustration-III: Automatic Re-optimization-I
• CBO can use directives for statements having similar predicate.
DB12c>select /*+ monitor*/ name
from emp e, dept d
where e.dept_id = d.department_id
and e.salary > 1000
and e.name like 'J%'
and d.department_id > 11;
select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID as8qw9s1jdc77, child number 0
-------------------------------------
select /*+ monitor*/ name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name
like 'J%' and d.department_id > 11
Plan hash value: 2629897806
-----------------------------------------------------------------------------
| Id | Operation | Name |Rows |Bytes|Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | NESTED LOOPS | | 2 | 38 | 3 (0)| 00:00:01 |
|* 2 | TABLE ACCESS FULL| EMP | 2 | 30 | 3 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | DEPT_ID_IDX | 1 | 4 | 0 (0)| |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">11 AND
"E"."SALARY">1000))
3 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID")
filter("D"."DEPARTMENT_ID">11)
Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- 1 Sql Plan Directive used for this statement
Sangam 14 Anju Garg 31
Illustration-III: Automatic Re-optimization-I
Summary:
• Until the cursor is cached, subsequent executions of identical query employ
statistics feedback.
• After the cursor ages out, subsequent hard parse uses SPD resulting in use
of dynamic statistics.
• Directives can be used for queries using similar predicate also.
Sangam 14 Anju Garg 32
Illustration–IV
Automatic Re-optimization – II
Sangam 14 Anju Garg 33
Illustration–IV : Automatic Re-optimization-II
Sangam 14 Anju Garg 34
What to expect?
• First execution of query is sub-optimal as Plan is
not adaptive.
• Cursor is marked re-optimizable and SPD created
• Second execution employs statistics feedback as
cursor is cached.
• Gathering statistics causes automatic creation of
column group
•After shared pool is flushed, subsequent
executions check SPD and
• Use column group statistics , if gathered.
• Else perform dynamic sampling
• SPD can be used for similar statements.
Illustration–IV: Automatic Re-optimization-II
Sangam 14 Anju Garg 35
• Table HR.BIRTHDAYS
• Correlation between columns
– DOW (Numeric day of week) and
– DOW_DESC (Literal day of week)
• Basic Statistics gathered
DB12c> select distinct dow, dow_desc from hr.birthdays order by dow;
DOW DOW
---------- ---
1 SUN
2 MON
3 TUE
4 WED
5 THU
6 FRI
7 SAT
7 rows selected.
Illustration–IV: Automatic Re-optimization-II
• First execution
– Query columns DOW and DOW_DESC together
– Missing column group
– Dynamic sampling not done (Default sampling level = 2 and basic statistics exist)
– Estimated rows (204) << Actual rows (1428)
DB12c>select /*+ gather_plan_statistics */ count(*)
from hr.birthdays
where dow = 1 and dow_desc = 'SUN';
select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST +REPORT'));
PLAN_TABLE_OUTPUT
--------------------------------------------------
SQL_ID 16fzuw8m34vas, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ count(*) from hr.birthdays where
dow = 1 and dow_desc = 'SUN'
Plan hash value: 1914637537
-----------------------------------------------------------------------------
|Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time |Buffers|
-----------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | 1 | | 1|00:00:00.01| 61|
| 1 | SORT AGGREGATE | | 1 | 1 | 1|00:00:00.01| 61|
|* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 204 | 1428|00:00:00.01| 61|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("DOW"=1 AND "DOW_DESC"='SUN'))
Continued…
Sangam 14 Anju Garg 36
Issue SQL first time
Cardinality misestimate
Illustration–IV: Automatic Re-optimization-II
• As optimizer's estimates are way off the mark
– Monitoring is enabled for statistics feedback
– Cursor is marked for re-optimization
– The plan that is expected to be chosen on the next execution is displayed.
... Continued from last slide
Reoptimized plan:
-----------------
This cursor is marked for automatic reoptimization. The plan that is
expected to be chosen on the next execution is displayed below.
Plan hash value: 1914637537
------------------------------------------------
| Id | Operation | Name | Rows |
------------------------------------------------
| 0 | SELECT STATEMENT | | 1 |
| 1 | SORT AGGREGATE | | 1 |
|* 2 | TABLE ACCESS FULL| BIRTHDAYS | 1428 |
------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("DOW"=1 AND "DOW_DESC"='SUN')
Sangam 14 Anju Garg 37
Note: Cursor marked
for re-optimization
Illustration–IV: Automatic Re-optimization-II
• Cursor is marked as re-optimizable (IS_REOPTIMIZABLE = Y).
– Will be hard parsed next time
DB12c> SELECT SQL_ID, CHILD_NUMBER, IS_REOPTIMIZABLE, SQL_TEXT
FROM V$SQL
WHERE SQL_ID = '16fzuw8m34vas';
SQL_ID CHILD_NUMBER IS_REOPTIMIZABLE SQL_TEXT
------------- ------------ ----------------- --------------------------------
16fzuw8m34vas 0 Y select /*+
gather_plan_statistics */
count(*) from hr.birthdays where
dow = 1 and dow_desc = 'SUN'
Sangam 14 Anju Garg 38
Cursor marked for
re-optimization
Illustration–IV: Automatic Re-optimization-II
• SQL Plan Directive generated
– REASON = SINGLE TABLE CARDINALITY MISESTIMATE
– STATE = USABLE (column group does not exist yet )
– TYPE = DYNAMIC_SAMPLING
DB12c>exec DBMS_SPD.FLUSH_SQL_PLAN_DIRECTIVE;
SELECT TO_CHAR(d.DIRECTIVE_ID) dir_id, o.OWNER, o.OBJECT_NAME OBJECT,
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.OBJECT_NAME = 'BIRTHDAYS'
ORDER BY 1,2,3,4,5;
DIR_ID OWNER OBJECT COL_NAME OBJECT_TYP TYPE STATE REASON
------------------------- ------- --------- ---------- ---------- ---------- ---------- --------------------
15511226280058347046 HR BIRTHDAYS DOW COLUMN DYNAMIC_SA USABLE SINGLE TABLE CARDINA
MPLING LITY MISESTIMATE
15511226280058347046 HR BIRTHDAYS DOW_DESC COLUMN DYNAMIC_SA USABLE SINGLE TABLE CARDINA
MPLING LITY MISESTIMATE
15511226280058347046 HR BIRTHDAYS xx TABLE DYNAMIC_SA USABLE SINGLE TABLE CARDINA
MPLING LITY MISESTIMATE
Sangam 14 Anju Garg 39
SPD created
Illustration–IV: Automatic Re-optimization-II
• Second execution
– Uses statistics feedback from last execution
PLAN_TABLE_OUTPUT
--------------------------------------------------
SQL_ID 16fzuw8m34vas, child number 1
-------------------------------------
select /*+ gather_plan_statistics */ count(*) from hr.birthdays where
dow = 1 and dow_desc = 'SUN'
Plan hash value: 1914637537
-----------------------------------------------------------------------------
|Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time |Buffers|
-----------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | 1 | | 1 |00:00:00.01 61 |
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01| 61 |
|* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 1428 | 1428 |00:00:00.01| 61 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("DOW"=1 AND "DOW_DESC"='SUN'))
Note
-----
- statistics feedback used for this statement
Sangam 14 Anju Garg 40
Issue SQL second time
Cursor cached
Use statistics feedback
Illustration–IV: Automatic Re-optimization-II
• A new cursor (CHILD_NUMBER = 1) has been created.
• New cursor cannot be optimized further (IS_REOPTIMIZABLE = N) .
• Subsequent executions will use the new cursor, if cached.
DB12c>SELECT SQL_ID, CHILD_NUMBER, IS_REOPTIMIZABLE, SQL_TEXT
FROM V$SQL
WHERE SQL_ID = '16fzuw8m34vas';
SQL_ID CHILD_NUMBER IS_REOPTIMIZABLE SQL_TEXT
------------- ------------ -------------------- -----------------------
16fzuw8m34vas 0 Y select /*+ gather_plan_statistics */ count(*) from hr.birthdays
where dow = 1
and dow_desc = 'SUN'
16fzuw8m34vas 1 N select /*+ gather_plan_statistics */ count(*) from hr.birthdays
where dow = 1
and dow_desc = 'SUN'
Sangam 14 Anju Garg
41
Illustration–IV: Automatic Re-optimization-II
Execution of a similar SQL with same query expression
• Hard parsing takes place
• The directive is applied (Directives are not tied to any SQL )
• Dynamic Statistics used: Dynamic sampling (level 2) is performed ( STATUS = USABLE).
Accurate cardinality estimate
DB12c>select /*+ gather_plan_statistics */ count(*)
from hr.birthdays
where dow = 2 and dow_desc = 'MON';
select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 2jjsaw12bw01d, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ count(*) from hr.birthdays where
dow = 2 and dow_desc = 'MON'
Plan hash value: 1914637537
-----------------------------------------------------------------------------
|Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time |Buffers|
-----------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | 1 | | 1 |00:00:00.01| 61 |
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01| 61 |
|* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 1428 | 1428 |00:00:00.01| 61 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("DOW"=2 AND "DOW_DESC"='MON'))
Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- 1 Sql Plan Directive used for this statement
Sangam 14 Anju Garg 42
Illustration–IV: Automatic Re-optimization-II
• Statistics gathered for HR.BIRTHDAYS
– Directives on the table are checked
– Column group created automatically for the columns DOW and DOW_DESC
DB12c>SELECT TABLE_NAME, EXTENSION_NAME, EXTENSION
FROM DBA_STAT_EXTENSIONS
WHERE OWNER='HR'
AND TABLE_NAME='BIRTHDAYS';
no rows selected
DB12c> exec dbms_stats.gather_table_stats('HR', 'BIRTHDAYS');
SELECT TABLE_NAME, EXTENSION_NAME, EXTENSION
FROM DBA_STAT_EXTENSIONS
WHERE OWNER='HR'
AND TABLE_NAME='BIRTHDAYS';
TABLE_NAME EXTENSION_NAME EXTENSION
--------------- ------------------------------ ------------------------------
BIRTHDAYS SYS_STSHCU09AIP06LHNSCFSKPJQ1P ("DOW","DOW_DESC")
Sangam 14 Anju Garg
43
Illustration–IV: Automatic Re-optimization-II
• The directive still has a state of USABLE as earlier
– The statement has not been recompiled after creation of extended statistics
DB12c>EXEC DBMS_SPD.FLUSH_SQL_PLAN_DIRECTIVE;
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.OBJECT_NAME = 'BIRTHDAYS'
ORDER BY 1,2,3,4,5;
DIR_ID OWNER OBJECT_NAME COL_NAME OBJECT_TYP TYPE STATE REASON
------------------------- ------ ------------ -------- ---------- ---------- ---------- --------------------
15511226280058347046 HR BIRTHDAYS DOW COLUMN DYNAMIC_SA USABLE SINGLE TABLE CARDINA
MPLING LITY MISESTIMATE
15511226280058347046 HR BIRTHDAYS DOW_DESC COLUMN DYNAMIC_SA USABLE SINGLE TABLE CARDINA
MPLING LITY MISESTIMATE
15511226280058347046 HR BIRTHDAYS xx TABLE DYNAMIC_SA USABLE SINGLE TABLE CARDINA
MPLING LITY MISESTIMATE
Sangam 14 Anju Garg
44
Illustration–IV: Automatic Re-optimization-II
• Force reparsing of the cursor .
– Optimizer checks the directive (SPD STATE =USABLE)
– Performs dynamic sampling
DB12c>select /*+ gather_plan_statistics REPARSE*/ count(*)
from hr.birthdays
where dow = 1 and dow_desc = 'SUN';
select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 6r41c03nunmdp, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ count(*) from hr.birthdays
where dow = 1 and dow_desc = 'SUN'
Plan hash value: 1914637537
------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 61 |
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01 | 61 |
|* 2 | TABLE ACCESS FULL| BIRTHDAYS | 1 | 1428 | 1428 |00:00:00.01 | 61 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("DOW"=1 AND "DOW_DESC"='SUN'))
Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- 1 Sql Plan Directive used for this statement
Sangam 14 Anju Garg 45
Subsequent execution
Force reparse
Check directive (USABLE)
Use dynamic Statistics
Illustration–IV: Automatic Re-optimization-II
• Reparsing of the statement causes STATE of the directive to change to SUPERSEDED
– An extension has been created for the corresponding column group
– Subsequent executions should use extended statistics instead of dynamic sampling.
DB12c>EXEC DBMS_SPD.FLUSH_SQL_PLAN_DIRECTIVE;
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.OBJECT_NAME = 'BIRTHDAYS'
ORDER BY 1,2,3,4,5;
DIR_ID OWNER OBJECT_NAME COL_NAME OBJECT_TYP TYPE STATE REASON
------------------------- ------- --------------- ---------- ---------- ---------- ---------- --------------------
12589029473066064605 HR BIRTHDAYS DOW COLUMN DYNAMIC_SA SUPERSEDED SINGLE TABLE CARDINA
MPLING LITY MISESTIMATE
12589029473066064605 HR BIRTHDAYS DOW_DESC COLUMN DYNAMIC_SA SUPERSEDED SINGLE TABLE CARDINA
MPLING LITY MISESTIMATE
12589029473066064605 HR BIRTHDAYS TABLE DYNAMIC_SA SUPERSEDED SINGLE TABLE CARDINA
Sangam 14 Anju Garg
46
Illustration–IV: Automatic Re-optimization-II
• Force reparse to use SUPERSEDED STATE of the directive
– Accurate estimate
• Extended statistics used
• No dynamic sampling (absence of a Note )
DB12c>select /*+ gather_plan_statistics */ /* force reparse */ count(*)
from hr.birthdays
where dow = 1 and dow_desc = 'SUN';
select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 1yptyv4kdfk70, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ /* force reparse */ count(*) from
hr.birthdays where dow = 1 and dow_desc = 'SUN'
Plan hash value: 1914637537
-----------------------------------------------------------------------------
|Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time |Buffers|
-----------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | 1 | | 1 |00:00:00.01| 61|
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01| 61|
|* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 1428 | 1428 |00:00:00.01| 61|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("DOW"=1 AND "DOW_DESC"='SUN'))
Sangam 14 Anju Garg
47
Subsequent execution
Force reparse
Check directive (SUPERSEDED)
Use extended Statistics
Illustration–IV: Automatic Re-optimization-II
• Issue a similar SQL selecting different column and with different values in predicate
– Checks existence of SPD
– Uses extended statistics (STATE = SUPERSEDED)
– Accurate estimate
DB12c> select /*+ gather_plan_statistics */ count(MM)
from hr.birthdays
where dow = 2 and dow_desc = 'MON';
select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 52u50yd55ad4x, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ count(MM) from hr.birthdays where
dow = 2 and dow_desc = 'MON'
Plan hash value: 1914637537
-----------------------------------------------------------------------------
|Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time | Buffers|
-----------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | 1 | | 1 |00:00:00.01| 61|
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01| 61|
|* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 1428 | 1428 |00:00:00.01| 61|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("DOW"=2 AND "DOW_DESC"='MON'))
Sangam 14 Anju Garg
48
Illustration–IV: Automatic Re-optimization-II
Summary:
• In case of initial cardinality misestimates, if adaptive Plan cannot be employed,
SQL is executed with parse time sub-optimal plan.
• The resulting cursor is marked for re-optimization and execution statistics are
stored in the cursor.
• Information learnt via first execution is persisted as SQL Plan Directive which
records missing group statistics. Subsequent DBMS_STATS calls result in
creation of column groups automatically.
• Until the cursor is cached, subsequent executions of identical query employ
statistics feedback.
• After the cursor ages out, during subsequent executions, optimizer uses column
group statistics, if they have been gathered else performs dynamic sampling.
• Directives can be used for queries using similar predicate also.
Sangam 14 Anju Garg
49
Conclusion
• In 12c, optimizer has evolved further as a result of a new adaptive approach to
query optimizations.
• Several enhancements to the statistical information available to optimizer.
• In all cases of significant cardinality misestimates, SQL Plan Directives are created
which record missing statistics and guide the optimizer during subsequent
executions of the statements that are identical or nearly identical.
• Adaptive Plans cause optimizer to make run-time adjustments to execution plans
during first execution.
• Automatic Re-optimization optimizes subsequent executions using information
gathered during earlier execution. Statistics Feedback is employed until reparsing
of the statement triggers application of SPD.
• In view of these enhancements, the optimizer should be able to select an optimal
execution plan every time.
Sangam 14 Anju Garg 50
References
• https://blogs.oracle.com/optimizer/entry/cardinality_feedback
• http://docs.oracle.com/database/121/TGSQL/tgsql_optcncpt.htm#TGSQL9498
3
• http://scn.sap.com/community/oracle/blog/2013/09/24/oracle-db-optimizer-
part-vii--looking-under-the-hood-of-adaptive-query-optimization-adaptive-
plans-oracle-12c
• https://s3-us-west-
2.amazonaws.com/utoug.documents/Training+Days+2014/JanisGriffinAdoptin
g_Adaptable_Query_Optimizer.pdf
• http://jimczuprynski.files.wordpress.com/2014/04/czuprynski-select-q1-
2014.pdf
• http://scn.sap.com/community/oracle/blog/2014/02/19/oracle-db-optimizer-
part-x--looking-under-the-hood-of-adaptive-query-optimization-adaptive-
statistics--sql-plan-directives-oracle-12c
Sangam 14 Anju Garg 51
52
53
ANJU GARG
Email:anjugarg66@gmail.com
My blog: http://oracleinaction.com/

More Related Content

What's hot

Oracle Database In-Memory and the Query Optimizer
Oracle Database In-Memory and the Query OptimizerOracle Database In-Memory and the Query Optimizer
Oracle Database In-Memory and the Query OptimizerChristian Antognini
 
Why is my_oracle_e-biz_database_slow_a_million_dollar_question
Why is my_oracle_e-biz_database_slow_a_million_dollar_questionWhy is my_oracle_e-biz_database_slow_a_million_dollar_question
Why is my_oracle_e-biz_database_slow_a_million_dollar_questionAjith Narayanan
 
SQL Plan Directives explained
SQL Plan Directives explainedSQL Plan Directives explained
SQL Plan Directives explainedMauro Pagano
 
Adapting to Adaptive Plans on 12c
Adapting to Adaptive Plans on 12cAdapting to Adaptive Plans on 12c
Adapting to Adaptive Plans on 12cMauro Pagano
 
Query Evaluation Techniques for Large Databases.pdf
Query Evaluation Techniques for Large Databases.pdfQuery Evaluation Techniques for Large Databases.pdf
Query Evaluation Techniques for Large Databases.pdfRayWill4
 
Analyze database system using a 3 d method
Analyze database system using a 3 d methodAnalyze database system using a 3 d method
Analyze database system using a 3 d methodAjith Narayanan
 
VirtaThon 2011 - Mining the AWR
VirtaThon 2011 - Mining the AWRVirtaThon 2011 - Mining the AWR
VirtaThon 2011 - Mining the AWRKristofferson A
 
New Tuning Features in Oracle 11g - How to make your database as boring as po...
New Tuning Features in Oracle 11g - How to make your database as boring as po...New Tuning Features in Oracle 11g - How to make your database as boring as po...
New Tuning Features in Oracle 11g - How to make your database as boring as po...Sage Computing Services
 
Whitepaper: Exadata Consolidation Success Story
Whitepaper: Exadata Consolidation Success StoryWhitepaper: Exadata Consolidation Success Story
Whitepaper: Exadata Consolidation Success StoryKristofferson A
 
Indexing in Exadata
Indexing in ExadataIndexing in Exadata
Indexing in ExadataEnkitec
 
Oracle sql high performance tuning
Oracle sql high performance tuningOracle sql high performance tuning
Oracle sql high performance tuningGuy Harrison
 
Oracle databasecapacityanalysisusingstatisticalmethods
Oracle databasecapacityanalysisusingstatisticalmethodsOracle databasecapacityanalysisusingstatisticalmethods
Oracle databasecapacityanalysisusingstatisticalmethodsAjith Narayanan
 
Create your oracle_apps_r12_lab_with_less_than_us1000
Create your oracle_apps_r12_lab_with_less_than_us1000Create your oracle_apps_r12_lab_with_less_than_us1000
Create your oracle_apps_r12_lab_with_less_than_us1000Ajith Narayanan
 
All on Adaptive and Extended Cursor Sharing
All on Adaptive and Extended Cursor SharingAll on Adaptive and Extended Cursor Sharing
All on Adaptive and Extended Cursor SharingMohamed Houri
 
Crack the complexity of oracle applications r12 workload v2
Crack the complexity of oracle applications r12 workload v2Crack the complexity of oracle applications r12 workload v2
Crack the complexity of oracle applications r12 workload v2Ajith Narayanan
 
Full Table Scan: friend or foe
Full Table Scan: friend or foeFull Table Scan: friend or foe
Full Table Scan: friend or foeMauro Pagano
 
Oracle database performance tuning
Oracle database performance tuningOracle database performance tuning
Oracle database performance tuningYogiji Creations
 
Managing Statistics for Optimal Query Performance
Managing Statistics for Optimal Query PerformanceManaging Statistics for Optimal Query Performance
Managing Statistics for Optimal Query PerformanceKaren Morton
 
Oracle ebs capacity_analysisusingstatisticalmethods
Oracle ebs capacity_analysisusingstatisticalmethodsOracle ebs capacity_analysisusingstatisticalmethods
Oracle ebs capacity_analysisusingstatisticalmethodsAjith Narayanan
 

What's hot (20)

Oracle Database In-Memory and the Query Optimizer
Oracle Database In-Memory and the Query OptimizerOracle Database In-Memory and the Query Optimizer
Oracle Database In-Memory and the Query Optimizer
 
Why is my_oracle_e-biz_database_slow_a_million_dollar_question
Why is my_oracle_e-biz_database_slow_a_million_dollar_questionWhy is my_oracle_e-biz_database_slow_a_million_dollar_question
Why is my_oracle_e-biz_database_slow_a_million_dollar_question
 
SQL Plan Directives explained
SQL Plan Directives explainedSQL Plan Directives explained
SQL Plan Directives explained
 
Adapting to Adaptive Plans on 12c
Adapting to Adaptive Plans on 12cAdapting to Adaptive Plans on 12c
Adapting to Adaptive Plans on 12c
 
Query Evaluation Techniques for Large Databases.pdf
Query Evaluation Techniques for Large Databases.pdfQuery Evaluation Techniques for Large Databases.pdf
Query Evaluation Techniques for Large Databases.pdf
 
Analyze database system using a 3 d method
Analyze database system using a 3 d methodAnalyze database system using a 3 d method
Analyze database system using a 3 d method
 
VirtaThon 2011 - Mining the AWR
VirtaThon 2011 - Mining the AWRVirtaThon 2011 - Mining the AWR
VirtaThon 2011 - Mining the AWR
 
New Tuning Features in Oracle 11g - How to make your database as boring as po...
New Tuning Features in Oracle 11g - How to make your database as boring as po...New Tuning Features in Oracle 11g - How to make your database as boring as po...
New Tuning Features in Oracle 11g - How to make your database as boring as po...
 
Whitepaper: Exadata Consolidation Success Story
Whitepaper: Exadata Consolidation Success StoryWhitepaper: Exadata Consolidation Success Story
Whitepaper: Exadata Consolidation Success Story
 
Indexing in Exadata
Indexing in ExadataIndexing in Exadata
Indexing in Exadata
 
Oracle sql high performance tuning
Oracle sql high performance tuningOracle sql high performance tuning
Oracle sql high performance tuning
 
Oracle databasecapacityanalysisusingstatisticalmethods
Oracle databasecapacityanalysisusingstatisticalmethodsOracle databasecapacityanalysisusingstatisticalmethods
Oracle databasecapacityanalysisusingstatisticalmethods
 
Create your oracle_apps_r12_lab_with_less_than_us1000
Create your oracle_apps_r12_lab_with_less_than_us1000Create your oracle_apps_r12_lab_with_less_than_us1000
Create your oracle_apps_r12_lab_with_less_than_us1000
 
All on Adaptive and Extended Cursor Sharing
All on Adaptive and Extended Cursor SharingAll on Adaptive and Extended Cursor Sharing
All on Adaptive and Extended Cursor Sharing
 
Crack the complexity of oracle applications r12 workload v2
Crack the complexity of oracle applications r12 workload v2Crack the complexity of oracle applications r12 workload v2
Crack the complexity of oracle applications r12 workload v2
 
Ash and awr deep dive hotsos
Ash and awr deep dive hotsosAsh and awr deep dive hotsos
Ash and awr deep dive hotsos
 
Full Table Scan: friend or foe
Full Table Scan: friend or foeFull Table Scan: friend or foe
Full Table Scan: friend or foe
 
Oracle database performance tuning
Oracle database performance tuningOracle database performance tuning
Oracle database performance tuning
 
Managing Statistics for Optimal Query Performance
Managing Statistics for Optimal Query PerformanceManaging Statistics for Optimal Query Performance
Managing Statistics for Optimal Query Performance
 
Oracle ebs capacity_analysisusingstatisticalmethods
Oracle ebs capacity_analysisusingstatisticalmethodsOracle ebs capacity_analysisusingstatisticalmethods
Oracle ebs capacity_analysisusingstatisticalmethods
 

Viewers also liked

Policy based cluster management in oracle 12c
Policy based cluster management in oracle 12c Policy based cluster management in oracle 12c
Policy based cluster management in oracle 12c Anju Garg
 
Oracle Database 12.1.0.2: New Features
Oracle Database 12.1.0.2: New FeaturesOracle Database 12.1.0.2: New Features
Oracle Database 12.1.0.2: New FeaturesDeiby Gómez
 
C++の話(本当にあった怖い話)
C++の話(本当にあった怖い話)C++の話(本当にあった怖い話)
C++の話(本当にあった怖い話)Yuki Tamura
 
C++ Files and Streams
C++ Files and Streams C++ Files and Streams
C++ Files and Streams Ahmed Farag
 
C++ Notes by Hisham Ahmed Rizvi for Class 12th Board Exams
C++ Notes by Hisham Ahmed Rizvi for Class 12th Board ExamsC++ Notes by Hisham Ahmed Rizvi for Class 12th Board Exams
C++ Notes by Hisham Ahmed Rizvi for Class 12th Board Examshishamrizvi
 

Viewers also liked (7)

Policy based cluster management in oracle 12c
Policy based cluster management in oracle 12c Policy based cluster management in oracle 12c
Policy based cluster management in oracle 12c
 
Qno 3 (a)
Qno 3 (a)Qno 3 (a)
Qno 3 (a)
 
Oracle Database 12.1.0.2: New Features
Oracle Database 12.1.0.2: New FeaturesOracle Database 12.1.0.2: New Features
Oracle Database 12.1.0.2: New Features
 
Stacks in c++
Stacks in c++Stacks in c++
Stacks in c++
 
C++の話(本当にあった怖い話)
C++の話(本当にあった怖い話)C++の話(本当にあった怖い話)
C++の話(本当にあった怖い話)
 
C++ Files and Streams
C++ Files and Streams C++ Files and Streams
C++ Files and Streams
 
C++ Notes by Hisham Ahmed Rizvi for Class 12th Board Exams
C++ Notes by Hisham Ahmed Rizvi for Class 12th Board ExamsC++ Notes by Hisham Ahmed Rizvi for Class 12th Board Exams
C++ Notes by Hisham Ahmed Rizvi for Class 12th Board Exams
 

Similar to Adaptive Query Optimization

Evolution of Performance Management: Oracle 12c adaptive optimizations - ukou...
Evolution of Performance Management: Oracle 12c adaptive optimizations - ukou...Evolution of Performance Management: Oracle 12c adaptive optimizations - ukou...
Evolution of Performance Management: Oracle 12c adaptive optimizations - ukou...Nelson Calero
 
Writing efficient sql
Writing efficient sqlWriting efficient sql
Writing efficient sqlj9soto
 
Oracle dbms_xplan.display_cursor format
Oracle dbms_xplan.display_cursor formatOracle dbms_xplan.display_cursor format
Oracle dbms_xplan.display_cursor formatFranck Pachot
 
Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Understanding Query Optimization with ‘regular’ and ‘Exadata’ OracleUnderstanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Understanding Query Optimization with ‘regular’ and ‘Exadata’ OracleGuatemala User Group
 
EvolveExecutionPlans.pdf
EvolveExecutionPlans.pdfEvolveExecutionPlans.pdf
EvolveExecutionPlans.pdfPraveenPolu1
 
D73549GC10_06.pptx
D73549GC10_06.pptxD73549GC10_06.pptx
D73549GC10_06.pptxVLQuyNhn
 
NOCOUG_201311_Fine_Tuning_Execution_Plans.pdf
NOCOUG_201311_Fine_Tuning_Execution_Plans.pdfNOCOUG_201311_Fine_Tuning_Execution_Plans.pdf
NOCOUG_201311_Fine_Tuning_Execution_Plans.pdfcookie1969
 
Top 10 tips for Oracle performance
Top 10 tips for Oracle performanceTop 10 tips for Oracle performance
Top 10 tips for Oracle performanceGuy Harrison
 
My Experience Using Oracle SQL Plan Baselines 11g/12c
My Experience Using Oracle SQL Plan Baselines 11g/12cMy Experience Using Oracle SQL Plan Baselines 11g/12c
My Experience Using Oracle SQL Plan Baselines 11g/12cNelson Calero
 
Sydney Oracle Meetup - access paths
Sydney Oracle Meetup - access pathsSydney Oracle Meetup - access paths
Sydney Oracle Meetup - access pathspaulguerin
 
Oracle Database Performance Tuning Basics
Oracle Database Performance Tuning BasicsOracle Database Performance Tuning Basics
Oracle Database Performance Tuning Basicsnitin anjankar
 
Oracle Query Tuning Tips - Get it Right the First Time
Oracle Query Tuning Tips - Get it Right the First TimeOracle Query Tuning Tips - Get it Right the First Time
Oracle Query Tuning Tips - Get it Right the First TimeDean Richards
 
MySQL/MariaDB query optimizer tuning tutorial from Percona Live 2013
MySQL/MariaDB query optimizer tuning tutorial from Percona Live 2013MySQL/MariaDB query optimizer tuning tutorial from Percona Live 2013
MySQL/MariaDB query optimizer tuning tutorial from Percona Live 2013Sergey Petrunya
 
Randolf Geist – IT-Tage 2015 – Oracle Parallel Execution – Analyse und Troubl...
Randolf Geist – IT-Tage 2015 – Oracle Parallel Execution – Analyse und Troubl...Randolf Geist – IT-Tage 2015 – Oracle Parallel Execution – Analyse und Troubl...
Randolf Geist – IT-Tage 2015 – Oracle Parallel Execution – Analyse und Troubl...Informatik Aktuell
 
Advanced Query Optimizer Tuning and Analysis
Advanced Query Optimizer Tuning and AnalysisAdvanced Query Optimizer Tuning and Analysis
Advanced Query Optimizer Tuning and AnalysisMYXPLAIN
 
Window functions in MySQL 8.0
Window functions in MySQL 8.0Window functions in MySQL 8.0
Window functions in MySQL 8.0Mydbops
 

Similar to Adaptive Query Optimization (20)

Evolution of Performance Management: Oracle 12c adaptive optimizations - ukou...
Evolution of Performance Management: Oracle 12c adaptive optimizations - ukou...Evolution of Performance Management: Oracle 12c adaptive optimizations - ukou...
Evolution of Performance Management: Oracle 12c adaptive optimizations - ukou...
 
Writing efficient sql
Writing efficient sqlWriting efficient sql
Writing efficient sql
 
Oracle dbms_xplan.display_cursor format
Oracle dbms_xplan.display_cursor formatOracle dbms_xplan.display_cursor format
Oracle dbms_xplan.display_cursor format
 
Do You Know The 11g Plan?
Do You Know The 11g Plan?Do You Know The 11g Plan?
Do You Know The 11g Plan?
 
Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Understanding Query Optimization with ‘regular’ and ‘Exadata’ OracleUnderstanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
 
EvolveExecutionPlans.pdf
EvolveExecutionPlans.pdfEvolveExecutionPlans.pdf
EvolveExecutionPlans.pdf
 
D73549GC10_06.pptx
D73549GC10_06.pptxD73549GC10_06.pptx
D73549GC10_06.pptx
 
Oracle 12c SPM
Oracle 12c SPMOracle 12c SPM
Oracle 12c SPM
 
NOCOUG_201311_Fine_Tuning_Execution_Plans.pdf
NOCOUG_201311_Fine_Tuning_Execution_Plans.pdfNOCOUG_201311_Fine_Tuning_Execution_Plans.pdf
NOCOUG_201311_Fine_Tuning_Execution_Plans.pdf
 
Top 10 tips for Oracle performance
Top 10 tips for Oracle performanceTop 10 tips for Oracle performance
Top 10 tips for Oracle performance
 
PoC Oracle Exadata - Retour d'expérience
PoC Oracle Exadata - Retour d'expériencePoC Oracle Exadata - Retour d'expérience
PoC Oracle Exadata - Retour d'expérience
 
My Experience Using Oracle SQL Plan Baselines 11g/12c
My Experience Using Oracle SQL Plan Baselines 11g/12cMy Experience Using Oracle SQL Plan Baselines 11g/12c
My Experience Using Oracle SQL Plan Baselines 11g/12c
 
Sydney Oracle Meetup - access paths
Sydney Oracle Meetup - access pathsSydney Oracle Meetup - access paths
Sydney Oracle Meetup - access paths
 
Part5 sql tune
Part5 sql tunePart5 sql tune
Part5 sql tune
 
Oracle Database Performance Tuning Basics
Oracle Database Performance Tuning BasicsOracle Database Performance Tuning Basics
Oracle Database Performance Tuning Basics
 
Oracle Query Tuning Tips - Get it Right the First Time
Oracle Query Tuning Tips - Get it Right the First TimeOracle Query Tuning Tips - Get it Right the First Time
Oracle Query Tuning Tips - Get it Right the First Time
 
MySQL/MariaDB query optimizer tuning tutorial from Percona Live 2013
MySQL/MariaDB query optimizer tuning tutorial from Percona Live 2013MySQL/MariaDB query optimizer tuning tutorial from Percona Live 2013
MySQL/MariaDB query optimizer tuning tutorial from Percona Live 2013
 
Randolf Geist – IT-Tage 2015 – Oracle Parallel Execution – Analyse und Troubl...
Randolf Geist – IT-Tage 2015 – Oracle Parallel Execution – Analyse und Troubl...Randolf Geist – IT-Tage 2015 – Oracle Parallel Execution – Analyse und Troubl...
Randolf Geist – IT-Tage 2015 – Oracle Parallel Execution – Analyse und Troubl...
 
Advanced Query Optimizer Tuning and Analysis
Advanced Query Optimizer Tuning and AnalysisAdvanced Query Optimizer Tuning and Analysis
Advanced Query Optimizer Tuning and Analysis
 
Window functions in MySQL 8.0
Window functions in MySQL 8.0Window functions in MySQL 8.0
Window functions in MySQL 8.0
 

Recently uploaded

Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on ThanabotsContinuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on ThanabotsLeah Henrickson
 
State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!Memoori
 
Microsoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireMicrosoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireExakis Nelite
 
Vector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptxVector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptxjbellis
 
Introduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptxIntroduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptxFIDO Alliance
 
ADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptxADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptxFIDO Alliance
 
الأمن السيبراني - ما لا يسع للمستخدم جهله
الأمن السيبراني - ما لا يسع للمستخدم جهلهالأمن السيبراني - ما لا يسع للمستخدم جهله
الأمن السيبراني - ما لا يسع للمستخدم جهلهMohamed Sweelam
 
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxHarnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxFIDO Alliance
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024Lorenzo Miniero
 
Design Guidelines for Passkeys 2024.pptx
Design Guidelines for Passkeys 2024.pptxDesign Guidelines for Passkeys 2024.pptx
Design Guidelines for Passkeys 2024.pptxFIDO Alliance
 
Generative AI Use Cases and Applications.pdf
Generative AI Use Cases and Applications.pdfGenerative AI Use Cases and Applications.pdf
Generative AI Use Cases and Applications.pdfalexjohnson7307
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...FIDO Alliance
 
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc
 
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...ScyllaDB
 
JohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptxJohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptxJohnPollard37
 
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?(Explainable) Data-Centric AI: what are you explaininhg, and to whom?
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?Paolo Missier
 
Top 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development CompaniesTop 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development CompaniesTopCSSGallery
 
How to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cfHow to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cfdanishmna97
 
CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)Wonjun Hwang
 

Recently uploaded (20)

Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on ThanabotsContinuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
 
State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!
 
Microsoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireMicrosoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - Questionnaire
 
Vector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptxVector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptx
 
Introduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptxIntroduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptx
 
ADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptxADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptx
 
الأمن السيبراني - ما لا يسع للمستخدم جهله
الأمن السيبراني - ما لا يسع للمستخدم جهلهالأمن السيبراني - ما لا يسع للمستخدم جهله
الأمن السيبراني - ما لا يسع للمستخدم جهله
 
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxHarnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024
 
Design Guidelines for Passkeys 2024.pptx
Design Guidelines for Passkeys 2024.pptxDesign Guidelines for Passkeys 2024.pptx
Design Guidelines for Passkeys 2024.pptx
 
Overview of Hyperledger Foundation
Overview of Hyperledger FoundationOverview of Hyperledger Foundation
Overview of Hyperledger Foundation
 
Generative AI Use Cases and Applications.pdf
Generative AI Use Cases and Applications.pdfGenerative AI Use Cases and Applications.pdf
Generative AI Use Cases and Applications.pdf
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
 
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
 
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
 
JohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptxJohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptx
 
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?(Explainable) Data-Centric AI: what are you explaininhg, and to whom?
(Explainable) Data-Centric AI: what are you explaininhg, and to whom?
 
Top 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development CompaniesTop 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development Companies
 
How to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cfHow to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cf
 
CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)
 

Adaptive Query Optimization

  • 1. Adaptive Query Optimization Sangam 14 Anju Garg 1 ANJU GARG
  • 2. About me Sangam 14 Anju Garg • More than 11 years of experience in IT Industry • Sr. Corporate Trainer (Oracle DBA) with Koenig Solutions Ltd. • Oracle blog : http://oracleinaction.com/ • Email : anjugarg66@gmail.com • Oracle Certified Expert 2
  • 3. Agenda • Drawbacks of Pre-12c optimizer • What's New in 12c?  Adaptive Query Optimization  Adaptive / Dynamic Plans  Automatic Re-optimization o SQL Plan Directives  Automatic Query Optimization workflow • Illustration-I : Cardinality Feedback in 11g • Illustration-II : Adaptive plans in 12c • Illustration-III : Automatic Re-optimization-I • Illustration-IV : Automatic Re-optimization-II • Conclusion • References • Q & A Sangam 14 Anju Garg 3
  • 4. Pre-12c optimizer Sangam 14 Anju Garg 4 • Drawbacks – Insufficient or stale statistics do not trigger dynamic sampling with default sampling level of 2. – SQL has to execute sub-optimally at least once to exploit ACS and Cardinality Feedback. – Cardinality feedback cannot be employed after cursor ages out.
  • 5. What's New in 12c? Adaptive Query Optimization – Adaptive / Dynamic plans  Initial execution of a query improved by making run-time adjustments to execution plan. – Automatic Re-optimization  Information gathered during initial execution is employed to improve subsequent executions of SQL. Sangam 14 Anju Garg 5
  • 6. Adaptive Plans • The default plan chosen at parse time switched to a better alternative plan called final plan at run-time. • Information found via dynamic plans is persisted as SQL plan directives • Can dynamically change – Join method between Nested Loops and Hash Join – Parallel Query Distribution Method between Hash and Broadcast • When? – Initial cardinality misestimates – Default and final plans have the same starting point. • How? – Optimizer stores alternative sub-plans with the cursor. – Computes threshold cardinality. – Statistic collectors embedded at critical points in the default execution plan. – Switches to an alternative plan, if row count crosses the threshold. Sangam 14 Anju Garg 6
  • 7. Automatic Re-optimization Sangam 14 Anju Garg 7 • CBO switches to a better plan during subsequent executions. • When? – Optimizer requires more information than base table statistics. – Adaptive Plans cannot be employed as default and final plans have the different starting points. • How? – Information learnt during initial execution persisted in SPD and employed during subsequent executions. – Augmented statistics used to improve subsequent executions. – if (identical query and cursor is cached) Use statistics feedback else (Similar query or cursor has aged out) if column group statistics gathered Use column group statistics else Use dynamic statistics
  • 8. SQL Plan Directives (SPD) • A key component of Automatic Query optimization framework. • Created as a result of significant cardinality misestimates during the execution of a SQL . • Assist the optimizer in generating a more optimal plan for future executions of the statement – Record missing group statistics. Subsequent DBMS_STATS calls result in creation of column groups automatically. – Instruct the optimizer to use column group statistics if they have been gathered , else perform dynamic sampling. • Defined for a query expression. • Not tied to a specific SQL statement. • Applicable to multiple SQL statements with similar predicates. Sangam 14 Anju Garg 8
  • 9. Adaptive Query Optimization workflow Sangam 14 Anju Garg 9
  • 10. Illustration - I Cardinality Feedback in 11g Sangam 14 Anju Garg 10
  • 11. Illustration - I: Cardinality Feedback in 11g • What to expect? • Cardinality feedback usage by a SQL • Cardinality estimate aging out with cursor Sangam 14 Anju Garg 11
  • 12. Illustration - I: Cardinality Feedback in 11g • Basic Statistics gathered • Complex predicates • Optimizer estimates EMP table to return 5 rows (Actual = 2 rows) • Parse time Plan Join Method : Hash Join. DB11g>explain plan for select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%‘ and d.department_id > 10; select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- Plan hash value: 3249786240 ----------------------------------------------------------------------------- | Id | Operation | Name |Rows|Bytes|Cost %CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5 |155 |6 (17)|0:00:01 | |* 1 | HASH JOIN | | 5 |155 |6 (17)|00:00:01| |* 2 | TABLE ACCESS FULL |EMP | 5 | 75 |3 (0)|00:00:01| | 3 | TABLE ACCESS BY INDEX ROWID|DEPT |26 |416 |2 (0)|00:00:01| |* 4 | INDEX RANGE SCAN |DEPT_ID_IDX|26 | |1 (0)|00:00:01| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") 2 - filter("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000) 4 - access("D"."DEPARTMENT_ID">10) Sangam 14 Anju Garg 12
  • 13. Illustration - I: Cardinality Feedback in 11g • First execution of query – misestimates 5 rows to be returned (Actual = 2 rows) • Final Plan Join Method : Hash Join (same as parse time plan) DB11g>select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10; select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 09daa1tu337ca, child number 1 ------------------------------------- select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10 Plan hash value: 3249786240 ----------------------------------------------------------------------------- | Id| Operation | Name |Rows|Bytes|Cost(%CPU)|Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | |6 (100)| | |* 1 | HASH JOIN | | 5 | 155 |6 (17)| 0:00:01| |* 2 | TABLE ACCESS FULL |EMP | 5 | 75 |3 (0)|00:00:01| | 3 | TABLE ACCESS BY INDEX ROWID|DEPT | 26 | 416 |2 (0)|00:00:01| |* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 26 | |1 (0)|00:00:01| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") 2 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)) 4 - access("D"."DEPARTMENT_ID">10) Sangam 14 Anju Garg 13
  • 14. Illustration - I: Cardinality Feedback in 11g • Second execution of the query employs cardinality feedback (cursor cached) • No. of rows returned by EMP accurately estimated to be 2 • Join method changes to Nested Loops. PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 09daa1tu337ca, child number 2 ------------------------------------- select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10 Plan hash value: 1970561632 ----------------------------------------------------------------------------- | Id | Operation |Name |Rows|Bytes|Cost(%CPU)|Time | ----------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | | |5 (100)| | | 1 | NESTED LOOPS | | | | | | | 2 | NESTED LOOPS | | 2 | 62 |5 (0)| 00:00:01| |* 3 | TABLE ACCESS FULL |EMP | 2 | 30 |3 (0)| 00:00:01| |* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 1 | |0 (0)| | | 5 | TABLE ACCESS BY INDEX ROWID|DEPT | 1 | 16 |1 (0)| 00:00:01| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)) 4 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") filter("D"."DEPARTMENT_ID">10) Note ----- - cardinality feedback used for this statement Sangam 14 Anju Garg 14
  • 15. Illustration - I: Cardinality Feedback in 11g • Flush shared pool • Third execution of the query : Optimizer misestimates cardinality again (Execution statistics aged out with the cursor) • Sub-optimal Join method (Hash join) chosen again DB11g> alter system flush shared_pool; PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 09daa1tu337ca, child number 0 ------------------------------------- select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10 Plan hash value: 3249786240 ----------------------------------------------------------------------------- |Id | Operation | Name |Rows|Bytes|Cost(%CPU)|Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | |6(100)| | |* 1 | HASH JOIN | | 5 | 155|6 (17)| 00:00:01| |* 2 | TABLE ACCESS FULL |EMP | 5 | 75|3 (0)| 00:00:01| | 3 | TABLE ACCESS BY INDEX ROWID|DEPT | 26 | 416|2 (0)| 00:00:01| |* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 26 | |1 (0)| 00:00:01| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") 2 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)) 4 - access("D"."DEPARTMENT_ID">10) Sangam 14 Anju Garg 15
  • 16. Illustration - I : Cardinality Feedback in 11g Sangam 14 Anju Garg 16 Summary: • In case of significant cardinality misestimates, execution statistics are stored in the cursor itself. • Until cursor is cached, Cardinality feedback is used during subsequent executions. • After the cursor ages out, cardinality estimate is lost and optimizer again misestimates cardinality.
  • 17. Illustration - II Adaptive Plans in 12c Sangam 14 Anju Garg 17
  • 18. Illustration - II : Adaptive Plans in 12c Sangam 14 Anju Garg 18 What to expect? • Initial cardinality misestimate • Run-time changes to execution plan during first execution of query • Cursor marked re-optimizable • SQL plan directive created
  • 19. Illustration - II: Adaptive Plans in 12c • Parse time plan: Initial cardinality misestimate (5 rows) – Default Plan Join Method : Hash Join (same as 11g) – Note - this is an adaptive plan DB12c>explain plan for select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10; select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- Plan hash value: 1074770502 ----------------------------------------------------------------------------- |Id |Operation |Name |Rows|Bytes|Cost(%CPU)| Time | ----------------------------------------------------------------------------- | 0|SELECT STATEMENT | | 5|155 |5(0)| 00:00:01| |* 1| HASH JOIN | | 5|155 |5(0)| 00:00:01 | |* 2| TABLE ACCESS FULL |EMP | 5|75 |3(0)| 00:00:01 | | 3| TABLE ACCESS BY INDEX ROWID BATCHED|DEPT | 26|416 |2(0)| 00:00:01 | |* 4 INDEX RANGE SCAN |DEPT_ID_IDX| 26| |1(0)| 00:00:01 | ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") 2 - filter("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000) 4 - access("D"."DEPARTMENT_ID">10) Note ----- - this is an adaptive plan Sangam 14 Anju Garg 19 Initial cardinality misestimate
  • 20. Illustration - II: Adaptive Plans in 12c Sangam 14 Anju Garg 20 •First execution : Join method changes from hash to nested loops at run-time. – A statistics collector inserted in the plan – Note : " this is an adaptive plan (rows marked '-' are inactive)“ Note : Output continued on next slides Run-time changes to plan
  • 21. Illustration - II : Adaptive Plans in 12c PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 09daa1tu337ca, child number 0 ------------------------------------- select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10 Plan hash value: 1970561632 ----------------------------------------------------------------------------------------------- | Id | Operation | |Rows|Bytes|Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 5 (100)| | |- * 1 | HASH JOIN | | 5 | 155| 5 (0)| 00:00:01 | | 2 | NESTED LOOPS | | 5 | 155| 5 (0)| 00:00:01 | | 3 | NESTED LOOPS | | | | | | |- 4 | STATISTICS COLLECTOR | | | | | | | * 5 | TABLE ACCESS FULL |EMP | 5 | 75| 3 (0)| 00:00:01 | | * 6 | INDEX RANGE SCAN |DEPT_ID_IDX | 26 | | 1 (0)| 00:00:01 | | 7 | TABLE ACCESS BY INDEX ROWID |DEPT | 1 | 16| 2 (0)| 00:00:01 | |- 8 | TABLE ACCESS BY INDEX ROWID BATCHED|DEPT | 26 | 416| 2 (0)| 00:00:01 | |- * 9 | INDEX RANGE SCAN |DEPT_ID_IDX | 26 | | 1 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") 5 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)) 6 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") filter("D"."DEPARTMENT_ID">10) 9 - access("D"."DEPARTMENT_ID">10) Note ----- - this is an adaptive plan (rows marked '-' are inactive) Continued ... Sangam 14 Anju Garg 21 Run-time changes to plan
  • 22. Illustration - II : Adaptive Plans in 12c Continued from last slide ... Reoptimized plan: ----------------- This cursor is marked for automatic reoptimization. The plan that is expected to be chosen on the next execution is displayed below. Plan hash value: 1970561632 ----------------------------------------------------------------------------- |Id |Operation | Name |Rows|Bytes|Cost(%CPU)| Time| ----------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | 1| 31| 5(0)| 00:00:01 | | 1 | NESTED LOOPS | | 1| 31| 5(0)| 00:00:01 | | 2 | NESTED LOOPS | | 2| 31| 5(0)| 00:00:01 | |* 3 | TABLE ACCESS FULL |EMP | 2| 30| 3(0)| 00:00:01 | |* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 1| | 0(0)| 00:00:01 | | 5 | TABLE ACCESS BY INDEX ROWID|DEPT | 1| 16| 1(0)| 00:00:01 | ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000) 4 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") filter("D"."DEPARTMENT_ID">10) Sangam 14 Anju Garg 22 – The plan expected to be chosen on the next execution uses Nested Loops join Note : Cursor marked for re-optimization
  • 23. Illustration - II : Adaptive Plans in 12c • IS_RESOLVED_ADAPTIVE_PLAN = Y – Adaptive Plan • IS_REOPTIMIZABLE=Y – Cursor marked for automatic re-optimization – will be hard parsed next time DB12c>select sql_id, child_number, sql_text, is_resolved_adaptive_plan resolved_adaptive_plan, IS_REOPTIMIZABLE reoptimizable from v$sql where sql_id = '09daa1tu337ca'; SQL_ID CHILD_NUMBER SQL_TEXT RESOLVED_ADAPTIVE_PLAN REOPTIMIZABLE ------------- ------------ ----------------------------- ---------------------- ------------- 09daa1tu337ca 0 select /*+ monitor*/ Y Y department_name from emp e, dept d where e .dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10 Sangam 14 Anju Garg 23 Cursor marked for re-optimization
  • 24. Illustration - II : Adaptive Plans in 12c Sangam 14 Anju Garg 24 • The information learnt via dynamic plans is persisted as a SQL directive. • Cardinality misestimates on columns DEPT_ID, NAME and SALARY of EMP table . • On subsequent executions dynamic sampling should be performed. DB12c> exec dbms_spd.flush_sql_plan_directive select o.object_name object, 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 ('HR') and o.object_name in ('EMP','DEPT') order by object_type; OBJECT COL_NAM OBJECT TYPE STATE REASON ------ ------- -------- ---------------- ------ ------------------------------------ EMP NAME COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE EMP DEPT_ID COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE EMP SALARY COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE EMP xx TABLE DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE SPD created
  • 25. Illustration - II : Adaptive Plans in 12c Summary: • In case of initial cardinality misestimates, Adaptive Plans can change the execution plan at run time during the first execution itself. • The resulting cursor is marked for re-optimization and execution statistics are stored in the cursor. • Information learnt via Adaptive Plans is persisted as SQL Plan Directive. Sangam 14 Anju Garg 25
  • 26. Illustration - III Automatic Re-optimization-I Sangam 14 Anju Garg 26
  • 27. Illustration – III: Automatic Re-optimization-I Sangam 14 Anju Garg 27 What to expect? •During subsequent executions of query  Until cursor is cached, Statistics feedback is used.  After cursor ages out, SPD is checked and Dynamic sampling is performed.  SPD can be used for similar statements.
  • 28. Illustration – III: Automatic Re-optimization-I • Second Execution – Buffering of rows by collector disabled. PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 09daa1tu337ca, child number 1 ------------------------------------- select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10 Plan hash value: 1970561632 ----------------------------------------------------------------------------- |Id |Operation |Name |Rows |Bytes|Cost(%CPU)|Time | ----------------------------------------------------------------------------- | 0|SELECT STATEMENT | | | | 5 (100)| | | 1| NESTED LOOPS | | 1 | 31| 5 (0)|00:00:01| | 2| NESTED LOOPS | | 2 | 31| 5 (0)|00:00:01| |* 3| TABLE ACCESS FULL |EMP | 2 | 30| 3 (0)|00:00:01| |* 4| INDEX RANGE SCAN |DEPT_ID_IDX| 1 | | 0 (0)| | | 5 TABLE ACCESS BY INDEX ROWID|DEPT | 1 | 16| 1 (0)|00:00:01| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)) 4 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") filter("D"."DEPARTMENT_ID">10) Note ----- - statistics feedback used for this statement Sangam 14 Anju Garg 28 Issue SQL second time Cursor cached Use statistics feedback
  • 29. Illustration-III: Automatic Re-optimization-I • SQL Plan directive persists even after shared pool is flushed. • Performs dynamic sampling with appropriate level (2) even though basic statistics exist. DB12c> alter system flush shared_pool; PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 09daa1tu337ca, child number 0 ------------------------------------- select /*+ monitor*/ department_name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10 Plan hash value: 1970561632 ---------------------------------------------------------------------------- |Id |Operation |Name |Rows|Bytes|Cost(%CPU)| Time| |--------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | | | 5(100)| | | 1 | NESTED LOOPS | | 2 | 62 | 5(0) |00:00:01| | 2 | NESTED LOOPS | | 2 | 62 | 5(0) |00:00:01| |* 3 | TABLE ACCESS FULL |EMP | 2 | 30 | 3(0) |00:00:01| |* 4 | INDEX RANGE SCAN |DEPT_ID_IDX| 1 | | 0(0) | | | 5 | TABLE ACCESS BY INDEX ROWID|DEPT | 1 | 16 | 1(0) |00:00:01| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">10 AND "E"."SALARY">1000)) 4 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") filter("D"."DEPARTMENT_ID">10) Note ----- - dynamic statistics used: dynamic sampling (level=2) - this is an adaptive plan - 1 Sql Plan Directive used for this statement Sangam 14 Anju Garg 29 Cursor flushed out Subsequent execution Check directive Use dynamic Statistics
  • 30. Illustration - II: Automatic Re-optimization-I • Hard parse results in an new cursor • Cannot be optimized further (IS_REOPTIMIZABLE = N) • Will be used for subsequent executions until cached. DB12c>select sql_id, child_number, sql_text, IS_REOPTIMIZABLE reoptimizable from v$sql where sql_id = '09daa1tu337ca'; SQL_ID CHILD_NUMBER SQL_TEXT REOPTIMIZABLE ------------- ------------ ------------------------------ ------------- 09daa1tu337ca 0 select /*+ monitor*/ Y department_name from emp e, dept d where e .dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 10 09daa1tu337ca 1 select /*+ monitor*/ N Sangam 14 Anju Garg 30
  • 31. Illustration-III: Automatic Re-optimization-I • CBO can use directives for statements having similar predicate. DB12c>select /*+ monitor*/ name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 11; select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID as8qw9s1jdc77, child number 0 ------------------------------------- select /*+ monitor*/ name from emp e, dept d where e.dept_id = d.department_id and e.salary > 1000 and e.name like 'J%' and d.department_id > 11 Plan hash value: 2629897806 ----------------------------------------------------------------------------- | Id | Operation | Name |Rows |Bytes|Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 3 (100)| | | 1 | NESTED LOOPS | | 2 | 38 | 3 (0)| 00:00:01 | |* 2 | TABLE ACCESS FULL| EMP | 2 | 30 | 3 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN | DEPT_ID_IDX | 1 | 4 | 0 (0)| | ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(("E"."NAME" LIKE 'J%' AND "E"."DEPT_ID">11 AND "E"."SALARY">1000)) 3 - access("E"."DEPT_ID"="D"."DEPARTMENT_ID") filter("D"."DEPARTMENT_ID">11) Note ----- - dynamic statistics used: dynamic sampling (level=2) - 1 Sql Plan Directive used for this statement Sangam 14 Anju Garg 31
  • 32. Illustration-III: Automatic Re-optimization-I Summary: • Until the cursor is cached, subsequent executions of identical query employ statistics feedback. • After the cursor ages out, subsequent hard parse uses SPD resulting in use of dynamic statistics. • Directives can be used for queries using similar predicate also. Sangam 14 Anju Garg 32
  • 34. Illustration–IV : Automatic Re-optimization-II Sangam 14 Anju Garg 34 What to expect? • First execution of query is sub-optimal as Plan is not adaptive. • Cursor is marked re-optimizable and SPD created • Second execution employs statistics feedback as cursor is cached. • Gathering statistics causes automatic creation of column group •After shared pool is flushed, subsequent executions check SPD and • Use column group statistics , if gathered. • Else perform dynamic sampling • SPD can be used for similar statements.
  • 35. Illustration–IV: Automatic Re-optimization-II Sangam 14 Anju Garg 35 • Table HR.BIRTHDAYS • Correlation between columns – DOW (Numeric day of week) and – DOW_DESC (Literal day of week) • Basic Statistics gathered DB12c> select distinct dow, dow_desc from hr.birthdays order by dow; DOW DOW ---------- --- 1 SUN 2 MON 3 TUE 4 WED 5 THU 6 FRI 7 SAT 7 rows selected.
  • 36. Illustration–IV: Automatic Re-optimization-II • First execution – Query columns DOW and DOW_DESC together – Missing column group – Dynamic sampling not done (Default sampling level = 2 and basic statistics exist) – Estimated rows (204) << Actual rows (1428) DB12c>select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN'; select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST +REPORT')); PLAN_TABLE_OUTPUT -------------------------------------------------- SQL_ID 16fzuw8m34vas, child number 0 ------------------------------------- select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN' Plan hash value: 1914637537 ----------------------------------------------------------------------------- |Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time |Buffers| ----------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | 1 | | 1|00:00:00.01| 61| | 1 | SORT AGGREGATE | | 1 | 1 | 1|00:00:00.01| 61| |* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 204 | 1428|00:00:00.01| 61| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(("DOW"=1 AND "DOW_DESC"='SUN')) Continued… Sangam 14 Anju Garg 36 Issue SQL first time Cardinality misestimate
  • 37. Illustration–IV: Automatic Re-optimization-II • As optimizer's estimates are way off the mark – Monitoring is enabled for statistics feedback – Cursor is marked for re-optimization – The plan that is expected to be chosen on the next execution is displayed. ... Continued from last slide Reoptimized plan: ----------------- This cursor is marked for automatic reoptimization. The plan that is expected to be chosen on the next execution is displayed below. Plan hash value: 1914637537 ------------------------------------------------ | Id | Operation | Name | Rows | ------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | | 1 | SORT AGGREGATE | | 1 | |* 2 | TABLE ACCESS FULL| BIRTHDAYS | 1428 | ------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("DOW"=1 AND "DOW_DESC"='SUN') Sangam 14 Anju Garg 37 Note: Cursor marked for re-optimization
  • 38. Illustration–IV: Automatic Re-optimization-II • Cursor is marked as re-optimizable (IS_REOPTIMIZABLE = Y). – Will be hard parsed next time DB12c> SELECT SQL_ID, CHILD_NUMBER, IS_REOPTIMIZABLE, SQL_TEXT FROM V$SQL WHERE SQL_ID = '16fzuw8m34vas'; SQL_ID CHILD_NUMBER IS_REOPTIMIZABLE SQL_TEXT ------------- ------------ ----------------- -------------------------------- 16fzuw8m34vas 0 Y select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN' Sangam 14 Anju Garg 38 Cursor marked for re-optimization
  • 39. Illustration–IV: Automatic Re-optimization-II • SQL Plan Directive generated – REASON = SINGLE TABLE CARDINALITY MISESTIMATE – STATE = USABLE (column group does not exist yet ) – TYPE = DYNAMIC_SAMPLING DB12c>exec DBMS_SPD.FLUSH_SQL_PLAN_DIRECTIVE; SELECT TO_CHAR(d.DIRECTIVE_ID) dir_id, o.OWNER, o.OBJECT_NAME OBJECT, 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.OBJECT_NAME = 'BIRTHDAYS' ORDER BY 1,2,3,4,5; DIR_ID OWNER OBJECT COL_NAME OBJECT_TYP TYPE STATE REASON ------------------------- ------- --------- ---------- ---------- ---------- ---------- -------------------- 15511226280058347046 HR BIRTHDAYS DOW COLUMN DYNAMIC_SA USABLE SINGLE TABLE CARDINA MPLING LITY MISESTIMATE 15511226280058347046 HR BIRTHDAYS DOW_DESC COLUMN DYNAMIC_SA USABLE SINGLE TABLE CARDINA MPLING LITY MISESTIMATE 15511226280058347046 HR BIRTHDAYS xx TABLE DYNAMIC_SA USABLE SINGLE TABLE CARDINA MPLING LITY MISESTIMATE Sangam 14 Anju Garg 39 SPD created
  • 40. Illustration–IV: Automatic Re-optimization-II • Second execution – Uses statistics feedback from last execution PLAN_TABLE_OUTPUT -------------------------------------------------- SQL_ID 16fzuw8m34vas, child number 1 ------------------------------------- select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN' Plan hash value: 1914637537 ----------------------------------------------------------------------------- |Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time |Buffers| ----------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | 1 | | 1 |00:00:00.01 61 | | 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01| 61 | |* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 1428 | 1428 |00:00:00.01| 61 | ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(("DOW"=1 AND "DOW_DESC"='SUN')) Note ----- - statistics feedback used for this statement Sangam 14 Anju Garg 40 Issue SQL second time Cursor cached Use statistics feedback
  • 41. Illustration–IV: Automatic Re-optimization-II • A new cursor (CHILD_NUMBER = 1) has been created. • New cursor cannot be optimized further (IS_REOPTIMIZABLE = N) . • Subsequent executions will use the new cursor, if cached. DB12c>SELECT SQL_ID, CHILD_NUMBER, IS_REOPTIMIZABLE, SQL_TEXT FROM V$SQL WHERE SQL_ID = '16fzuw8m34vas'; SQL_ID CHILD_NUMBER IS_REOPTIMIZABLE SQL_TEXT ------------- ------------ -------------------- ----------------------- 16fzuw8m34vas 0 Y select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN' 16fzuw8m34vas 1 N select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN' Sangam 14 Anju Garg 41
  • 42. Illustration–IV: Automatic Re-optimization-II Execution of a similar SQL with same query expression • Hard parsing takes place • The directive is applied (Directives are not tied to any SQL ) • Dynamic Statistics used: Dynamic sampling (level 2) is performed ( STATUS = USABLE). Accurate cardinality estimate DB12c>select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 2 and dow_desc = 'MON'; select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 2jjsaw12bw01d, child number 0 ------------------------------------- select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 2 and dow_desc = 'MON' Plan hash value: 1914637537 ----------------------------------------------------------------------------- |Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time |Buffers| ----------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | 1 | | 1 |00:00:00.01| 61 | | 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01| 61 | |* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 1428 | 1428 |00:00:00.01| 61 | ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(("DOW"=2 AND "DOW_DESC"='MON')) Note ----- - dynamic statistics used: dynamic sampling (level=2) - 1 Sql Plan Directive used for this statement Sangam 14 Anju Garg 42
  • 43. Illustration–IV: Automatic Re-optimization-II • Statistics gathered for HR.BIRTHDAYS – Directives on the table are checked – Column group created automatically for the columns DOW and DOW_DESC DB12c>SELECT TABLE_NAME, EXTENSION_NAME, EXTENSION FROM DBA_STAT_EXTENSIONS WHERE OWNER='HR' AND TABLE_NAME='BIRTHDAYS'; no rows selected DB12c> exec dbms_stats.gather_table_stats('HR', 'BIRTHDAYS'); SELECT TABLE_NAME, EXTENSION_NAME, EXTENSION FROM DBA_STAT_EXTENSIONS WHERE OWNER='HR' AND TABLE_NAME='BIRTHDAYS'; TABLE_NAME EXTENSION_NAME EXTENSION --------------- ------------------------------ ------------------------------ BIRTHDAYS SYS_STSHCU09AIP06LHNSCFSKPJQ1P ("DOW","DOW_DESC") Sangam 14 Anju Garg 43
  • 44. Illustration–IV: Automatic Re-optimization-II • The directive still has a state of USABLE as earlier – The statement has not been recompiled after creation of extended statistics DB12c>EXEC DBMS_SPD.FLUSH_SQL_PLAN_DIRECTIVE; 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.OBJECT_NAME = 'BIRTHDAYS' ORDER BY 1,2,3,4,5; DIR_ID OWNER OBJECT_NAME COL_NAME OBJECT_TYP TYPE STATE REASON ------------------------- ------ ------------ -------- ---------- ---------- ---------- -------------------- 15511226280058347046 HR BIRTHDAYS DOW COLUMN DYNAMIC_SA USABLE SINGLE TABLE CARDINA MPLING LITY MISESTIMATE 15511226280058347046 HR BIRTHDAYS DOW_DESC COLUMN DYNAMIC_SA USABLE SINGLE TABLE CARDINA MPLING LITY MISESTIMATE 15511226280058347046 HR BIRTHDAYS xx TABLE DYNAMIC_SA USABLE SINGLE TABLE CARDINA MPLING LITY MISESTIMATE Sangam 14 Anju Garg 44
  • 45. Illustration–IV: Automatic Re-optimization-II • Force reparsing of the cursor . – Optimizer checks the directive (SPD STATE =USABLE) – Performs dynamic sampling DB12c>select /*+ gather_plan_statistics REPARSE*/ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN'; select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 6r41c03nunmdp, child number 0 ------------------------------------- select /*+ gather_plan_statistics */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN' Plan hash value: 1914637537 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 61 | | 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01 | 61 | |* 2 | TABLE ACCESS FULL| BIRTHDAYS | 1 | 1428 | 1428 |00:00:00.01 | 61 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(("DOW"=1 AND "DOW_DESC"='SUN')) Note ----- - dynamic statistics used: dynamic sampling (level=2) - 1 Sql Plan Directive used for this statement Sangam 14 Anju Garg 45 Subsequent execution Force reparse Check directive (USABLE) Use dynamic Statistics
  • 46. Illustration–IV: Automatic Re-optimization-II • Reparsing of the statement causes STATE of the directive to change to SUPERSEDED – An extension has been created for the corresponding column group – Subsequent executions should use extended statistics instead of dynamic sampling. DB12c>EXEC DBMS_SPD.FLUSH_SQL_PLAN_DIRECTIVE; 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.OBJECT_NAME = 'BIRTHDAYS' ORDER BY 1,2,3,4,5; DIR_ID OWNER OBJECT_NAME COL_NAME OBJECT_TYP TYPE STATE REASON ------------------------- ------- --------------- ---------- ---------- ---------- ---------- -------------------- 12589029473066064605 HR BIRTHDAYS DOW COLUMN DYNAMIC_SA SUPERSEDED SINGLE TABLE CARDINA MPLING LITY MISESTIMATE 12589029473066064605 HR BIRTHDAYS DOW_DESC COLUMN DYNAMIC_SA SUPERSEDED SINGLE TABLE CARDINA MPLING LITY MISESTIMATE 12589029473066064605 HR BIRTHDAYS TABLE DYNAMIC_SA SUPERSEDED SINGLE TABLE CARDINA Sangam 14 Anju Garg 46
  • 47. Illustration–IV: Automatic Re-optimization-II • Force reparse to use SUPERSEDED STATE of the directive – Accurate estimate • Extended statistics used • No dynamic sampling (absence of a Note ) DB12c>select /*+ gather_plan_statistics */ /* force reparse */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN'; select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 1yptyv4kdfk70, child number 0 ------------------------------------- select /*+ gather_plan_statistics */ /* force reparse */ count(*) from hr.birthdays where dow = 1 and dow_desc = 'SUN' Plan hash value: 1914637537 ----------------------------------------------------------------------------- |Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time |Buffers| ----------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | 1 | | 1 |00:00:00.01| 61| | 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01| 61| |* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 1428 | 1428 |00:00:00.01| 61| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(("DOW"=1 AND "DOW_DESC"='SUN')) Sangam 14 Anju Garg 47 Subsequent execution Force reparse Check directive (SUPERSEDED) Use extended Statistics
  • 48. Illustration–IV: Automatic Re-optimization-II • Issue a similar SQL selecting different column and with different values in predicate – Checks existence of SPD – Uses extended statistics (STATE = SUPERSEDED) – Accurate estimate DB12c> select /*+ gather_plan_statistics */ count(MM) from hr.birthdays where dow = 2 and dow_desc = 'MON'; select * from table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- SQL_ID 52u50yd55ad4x, child number 0 ------------------------------------- select /*+ gather_plan_statistics */ count(MM) from hr.birthdays where dow = 2 and dow_desc = 'MON' Plan hash value: 1914637537 ----------------------------------------------------------------------------- |Id |Operation |Name |Starts|E-Rows|A-Rows| A-Time | Buffers| ----------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | 1 | | 1 |00:00:00.01| 61| | 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01| 61| |* 2 | TABLE ACCESS FULL|BIRTHDAYS| 1 | 1428 | 1428 |00:00:00.01| 61| ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(("DOW"=2 AND "DOW_DESC"='MON')) Sangam 14 Anju Garg 48
  • 49. Illustration–IV: Automatic Re-optimization-II Summary: • In case of initial cardinality misestimates, if adaptive Plan cannot be employed, SQL is executed with parse time sub-optimal plan. • The resulting cursor is marked for re-optimization and execution statistics are stored in the cursor. • Information learnt via first execution is persisted as SQL Plan Directive which records missing group statistics. Subsequent DBMS_STATS calls result in creation of column groups automatically. • Until the cursor is cached, subsequent executions of identical query employ statistics feedback. • After the cursor ages out, during subsequent executions, optimizer uses column group statistics, if they have been gathered else performs dynamic sampling. • Directives can be used for queries using similar predicate also. Sangam 14 Anju Garg 49
  • 50. Conclusion • In 12c, optimizer has evolved further as a result of a new adaptive approach to query optimizations. • Several enhancements to the statistical information available to optimizer. • In all cases of significant cardinality misestimates, SQL Plan Directives are created which record missing statistics and guide the optimizer during subsequent executions of the statements that are identical or nearly identical. • Adaptive Plans cause optimizer to make run-time adjustments to execution plans during first execution. • Automatic Re-optimization optimizes subsequent executions using information gathered during earlier execution. Statistics Feedback is employed until reparsing of the statement triggers application of SPD. • In view of these enhancements, the optimizer should be able to select an optimal execution plan every time. Sangam 14 Anju Garg 50
  • 51. References • https://blogs.oracle.com/optimizer/entry/cardinality_feedback • http://docs.oracle.com/database/121/TGSQL/tgsql_optcncpt.htm#TGSQL9498 3 • http://scn.sap.com/community/oracle/blog/2013/09/24/oracle-db-optimizer- part-vii--looking-under-the-hood-of-adaptive-query-optimization-adaptive- plans-oracle-12c • https://s3-us-west- 2.amazonaws.com/utoug.documents/Training+Days+2014/JanisGriffinAdoptin g_Adaptable_Query_Optimizer.pdf • http://jimczuprynski.files.wordpress.com/2014/04/czuprynski-select-q1- 2014.pdf • http://scn.sap.com/community/oracle/blog/2014/02/19/oracle-db-optimizer- part-x--looking-under-the-hood-of-adaptive-query-optimization-adaptive- statistics--sql-plan-directives-oracle-12c Sangam 14 Anju Garg 51
  • 52. 52