1 10/17/2015 sql tuning kyle hailey explain plans, erss, tcf, vst,rtsm

104/21/23

SQL Tuning

Kyle Haileyhttp://oraclemonitor.com

Explain Plans, ERSS, TCF, VST,RTSM

Bibliography

•Troubleshooting Oracle Performance (TOP)

• Christian Antognini (TOP)

•Cost –Based Oracle Fundaments (CBOF)

• Jonathan Lewis

•SQL Tuning

• Dan Tow

•Blogs & Websites

• Wolfgang Breitling - TCF

• Greg Rahn – TCF, dynamic_sampling

• Kerry Osborne – plan stability

• Randolf Geist – same plans different access

204/21/23

Content

Copyright 2006 Kyle Hailey

• EXPLAIN PLAN – review • ERSS – extended rows source statistics• TCF - tuning by cardinality feedback• VST – visual SQL tuning• RTSM – real time SQL monitoringpossibly• Object Statistics• Plan Variation,• Hints and query transformations• Hints, Outlines, Profiles, SQL Plan Baselines

Explain Plan Summary

10g* use

dbms_xplan.display_cursor()

Real executed plan V$sql_plan is source Other methods deceptive**

* Trick for 9i available** Except tracing (starting v7.? )

Explain Plan


Four Methods

1. EXPLAIN PLAN (v6?)

• Calculated • Ignores bind variables• No execution

2.SQL_TRACE (v7?)

•Reliable but have to trace and use tkprof3.AUTOTRACE (v8.1.7)

•Uses Explain Plan4.V$SQL_PLAN(_statistics)_all)) (v9iR2)

• Actual executed plan• 9i trick with dbms_xplan.display • 10g use dbms_xplan.display_cursor

Estimated

ActualEasy

Estimated

Actualclunky

Explain Plan

•Set UpSQL> @?/rdbms/admin/utlxplan.sqlSQL> Create public synonym plan_table for plan_table;

SQL> Grant all on plan_table to public ;

•Using: SQL> delete from plan_table;

SQL> EXPLAIN PLAN for [your query]

* SQL> @?/rdbms/admin/utlxpls.sql

NOTE “?” = $ORACLE_HOME in sqlplus

* @?/rdbms/admin/utlxplp.sql - Parallel query explain

Explain Plan 8iSQL> EXPLAIN PLAN FOR 2 SELECT * 3 FROM emp e, dept d 4 WHERE e.deptno = d.deptno 5 AND e.ename = 'SMITH';Explained.

SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql

Plan Table--------------------------------------------------------------------------------| Operation | Name | Rows | Bytes| Cost | Pstart| Pstop |--------------------------------------------------------------------------------| SELECT STATEMENT | | | | | | || NESTED LOOPS | | | | | | || TABLE ACCESS FULL |EMP | | | | | || TABLE ACCESS BY INDEX RO|DEPT | | | | | || INDEX UNIQUE SCAN |PK_DEPT | | | | | |--------------------------------------------------------------------------------8 rows selected.

• Estimated • No Execution Stats

Explain Plan 9i , 10g9.2.0 (uses dbms_xplan.display)----------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost |----------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | || 1 | NESTED LOOPS | | | | ||* 2 | TABLE ACCESS FULL | EMP | | | || 3 | TABLE ACCESS BY INDEX ROWID| DEPT | | | ||* 4 | INDEX UNIQUE SCAN | PK_DEPT | | | |----------------------------------------------------------------------------

2 - filter("E"."ENAME"='SMITH') 4 - access("E"."DEPTNO"="D"."DEPTNO")

10.2.0 (uses dbms_xplan.display) -------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time -------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 117 | 3 (0)| 00:00:01 | 1 | NESTED LOOPS | | 1 | 117 | 3 (0)| 00:00:01 |* 2 | TABLE ACCESS FULL | EMP | 1 | 87 | 2 (0)| 00:00:01 | 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 30 | 1 (0)| 00:00:01 |* 4 | INDEX UNIQUE SCAN | PK_DEPT | 1 | | 0 (0)| 00:00:01-------------------------------------------------------------------------------------------

2 - filter("E"."ENAME"='SMITH') 4 - access("E"."DEPTNO"="D"."DEPTNO")

Predicate Filters

Estimations

Empty

SQL Trace

alter session set max_dump_file_size=unlimited;

alter session set timed_statistics = true;

alter session set statistics_level = all ;

-- 9i alter session set "_rowsource_execution_statistics" = true;

alter session set tracefile_identifier = XXX_TRACE_XXX ;

alter session set sql_trace = true ;

-- alter session set events ‘10046 trace name context forever, level 12';

From

http://tonguc.wordpress.com/2006/12/30/introduction-to-oracle-trace-utulity-and-understanding-the-fundamental-performance-equation/

Tracefile Analyzer

http://www.ubtools.com/ubtools/products/itrprof/itrprof_user_manual.html

SQL Trace


Sql_trace=true, then tkprof

8.1.7Rows Row Source Operation------- --------------------------------------------------- 1 NESTED LOOPS 1 TABLE ACCESS FULL EMP 1 TABLE ACCESS BY INDEX ROWID DEPT 1 INDEX UNIQUE SCAN (object id 276222)

9.2.0 Rows Row Source Operation------- --------------------------------------------------- 1 NESTED LOOPS 1 TABLE ACCESS FULL EMP 1 TABLE ACCESS BY INDEX ROWID DEPT 1 INDEX UNIQUE SCAN PK_DEPT (object id 675001)

10.2.0Rows Row Source Operation------- --------------------------------------------------- 1 NESTED LOOPS (cr=6 pr=0 pw=0 time=100 us) 1 TABLE ACCESS FULL EMP (cr=4 pr=0 pw=0 time=69 us) 1 TABLE ACCESS BY INDEX ROWID DEPT (cr=2 pr=0 pw=0 time=32 us) 1 INDEX UNIQUE SCAN PK_DEPT (cr=1 pr=0 pw=0 time=17 us)(object id 156597)

With extended rows source statistics

Jonathan Lewis : 9.2.0.2 through to 9.2.0.5, enabling sql_trace gave you some row source execution statistics in the STAT# lines of trace files. This feature disappeared in 9.2.0.6 because of the overheads, re-appearing in 10g when the parameter to set a sampling frequency was introduced.

autotrace


•Examplesset autotrace offset autotrace on -- explain and statistics

set autotrace traceonly -- don’t print query results

set autotrace on explainset autotrace on statistics

set autotrace traceonly explainset autotrace traceonly statistics

•Requirements@?/rdbms/admin/utlxplan.sql@?/sqlplus/admin/plustrce.sql

-- run as system creates plustracegrant plustrace to [user];

autotrace 8i 9i 10g


8.1.7 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 NESTED LOOPS 2 1 TABLE ACCESS (FULL) OF 'EMP' 3 1 TABLE ACCESS (BY INDEX ROWID) OF 'DEPT' 4 3 INDEX (UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)

9.2.0Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=57) 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'DEPT' (Cost=1 Card=1 Bytes=20) 2 1 NESTED LOOPS (Cost=3 Card=1 Bytes=57) 3 2 TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=1 Bytes=37) 4 2 INDEX (RANGE SCAN) OF 'PK_DEPT' (NON-UNIQUE)

10.2.0 (starts using dbms_xplan )----------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |----------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 117 | 3 (0)| 00:00:01 || 1 | NESTED LOOPS | | 1 | 117 | 3 (0)| 00:00:01 ||* 2 | TABLE ACCESS FULL | EMP | 1 | 87 | 2 (0)| 00:00:01 || 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 30 | 1 (0)| 00:00:01 ||* 4 | INDEX UNIQUE SCAN | PK_DEPT | 1 | | 0 (0)| 00:00:01 |----------------------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 2 - filter("E"."ENAME"='SMITH') 4 - access("E"."DEPTNO"="D"."DEPTNO")

Wow, look at these statistics, looks great huh?

Estimates

Estimates

Autotrace subtleties set autotrace onselect id from t1 where n1 > :m_n1;

----------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time |----------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 50 | 350 | 1 (0)|00:00:01 || 1 | TABLE ACCESS BY INDEX ROWID| T1 | 50 | 350 | 1 (0)|00:00:01 ||* 2 | INDEX RANGE SCAN | T1_I1| 21 | | 1 (0)|00:00:01|---------------------------------------------------------------------------------

select id from t1 where n1 > :m_n1; select * from table (dbms_xplan.display_cursor());

------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 5 (100)| |

|* 1 | TABLE ACCESS FULL| T1 | 1000 | 7000 | 5 (0)| 00:00:01 |-------------------------------------------------------------------------------

•Autotrace uses Explain Plan command• Autotrace doesn’t uses bind variable peeking

Same QueryDifferent Plan

9i dbms_xplan.display()

new in 9i

• dbms_xplan.display()– simply old explain plan formatting

• V$SQL_PLAN– exciting ! live execution plans

9i dbms_xplan.display()

SQL> EXPLAIN PLAN FOR SELECT * FROM emp e, dept d WHERE e.deptno = d.deptno AND e.ename = 'SMITH';Explained.

SQL> set linesize 132

SQL> SELECT * FROM TABLE(dbms_xplan.display);PLAN_TABLE_OUTPUT----------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost |----------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | || 1 | NESTED LOOPS | | | | ||* 2 | TABLE ACCESS FULL | EMP | | | || 3 | TABLE ACCESS BY INDEX ROWID| DEPT | | | ||* 4 | INDEX UNIQUE SCAN | PK_DEPT | | | |----------------------------------------------------------------------------Predicate Information (identified by operation id):---------------------------------------------------

2 - filter("E"."ENAME"='SMITH') 4 - access("E"."DEPTNO"="D"."DEPTNO")20 rows selected.

Predicate filters

9i v$sql_plan direct

Real plan !

col operation for a35SELECT LPAD(' ',depth)|| P.OPERATION||'_'|| P.OPTIONS||' '|| P.OBJECT_NAME operationFROM

V$SQL_PLAN PWHERE p.hash_value=&hash_valueorder by child_number, ID/

OPERATION-----------------------------------SELECT STATEMENT_ NESTED LOOPS_ TABLE ACCESS_FULL EMP TABLE ACCESS_BY INDEX ROWID DEPT INDEX_UNIQUE SCAN PK_DEPT

9i v$sql_plan via dbms_xplan

create or replace view liveplan as select sp.*, to_char(hash_value)|| '_' ||to_char(child_number) statement_id, sysdate timestamp

from v$sql_plan sp;

Idea from James Morle :

select * from table(dbms_xplan.DISPLAY('LIVEPLAN','1792773701_0 ' ));

PLAN_TABLE_OUTPUT----------------------------------------------------------------------------

---------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost |---------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 4 || 1 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 20 | 2 || 2 | NESTED LOOPS | | 1 | 57 | 4 ||* 3 | TABLE ACCESS FULL | EMP | 1 | 37 | 2 ||* 4 | INDEX RANGE SCAN | PK_DEPT | 1 | | 1 |---------------------------------------------------------------------------

9i v$sql_plan via dbms_xplan

How do you get the hash_value of last execution?

Session 1Select sid from v$mystat where rownum=1;21

SELECT *FROM emp e, dept dWHERE e.deptno = d.deptnoAND e.ename = 'SMITH';

select * from table(dbms_xplan.DISPLAY('LIVEPLAN','3760741946_0' ));

Session 2

Select sql_hash_value from v$session where sid=21;3760741946

Can’t get child_number in 9i but can in 10g

Select prev_hash_value from v$session where sid = (Select sid from v$mystat where rownum=1);

Select prev_sql_id from v$session where sid = (Select sid from v$mystat where rownum=1);10g

9i

Yes

NoWorkaround

10g dbms_xplan.display_cursor()

10g introduces

• dbms_xplan.display_cursor()

Grants (as sys)grant select on v_$session to scott;grant select on v_$SQL_PLAN_STATISTICS_ALL to scott;grant select on v_$sql to scott;grant select on v_$sql_plan to scott;

Options dbms_xplan.display_cursor(); -- last executed cursor

dbms_xplan.display_cursor(‘sql_id’, child_number, ‘options’)

Real plan!Easy FormattingEasy access


select count(*) from scott.dept where deptno=10;select * from table(dbms_xplan.display_cursor());

PLAN_TABLE_OUTPUT--------------------------------------------------------------------------------

SQL_ID 46upz85274d4g, child number 0-------------------------------------select count(*) from scott.dept where deptno=10

Plan hash value: 2236899148

------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 1 (100)| || 1 | SORT AGGREGATE | | 1 | 3 | | ||* 2 | INDEX UNIQUE SCAN| PK_DEPT | 1 | 3 | 1 (0)| 00:00:01 |------------------------------------------------------------------------------

Predicate Information (identified by operation id):--------------------------------------------------- 2 - access("DEPTNO"=10)

Real Plan

Estimations


Format

select * from table(dbms_xplan.display_cursor(‘sql_id’,child_number,’arguments’));

Examples:

select * from table( dbms_xplan.display_cursor());

select * from table ( dbms_xplan.display_cursor (null,null, 'ADVANCED'));

select * from table ( dbms_xplan.display_cursor ('811a0zb26fw0x',0, 'BASIC'));

Arguments• ' ADVANCED'

• ' –PREDICATE'

• ' –PREDICATE +OUTLINE'


display_cursor(‘sql_id’,child_number,’arguments’));

predicate info note

Query Block Name

Column projection info outlines

binds variables

BASIC null X XTYPICAL X XSERIAL X XALL X X X XADVANCED X X X X X XPREDICATES XNOTE XALIAS XPROJECTION XOUTLINES XPEEK_BINDS X

+ include- filter out

10g dbms_xplan.display_cursorvariable x varchar2(10);select 'X' into :x from dual;select * from dual where dummy=:x;select * from table ( dbms_xplan.display_cursor (null,null,

'ADVANCED -OUTLINE -NOTE'));

2304/21/23

SQL_ID 3gfhcbpynm1wj, child number 0

select * from dual where dummy=:x

Plan hash value: 272002086 .| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time || 0 | SELECT STATEMENT | | | | 2 (100)| ||* 1 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 |

Query Block Name / Object Alias (identified by operation id):

1 - SEL$1 / DUAL@SEL$1

Peeked Binds (identified by position):1 - :DUM (VARCHAR2(30), CSID=178): 'X'

Predicate Information (identified by operation id):

1 - filter("DUMMY"=:X)

Column Projection Information (identified by operation id):

1 - "DUMMY"[VARCHAR2,1]

ALIASPEEK_BINDSPREDICATESPROJECTIONOUTLINESNOTE

10g dbms_xplan.display_cursor

Outline Data------------- /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.1') ALL_ROWS OUTLINE_LEAF(@"SEL$1") FULL(@"SEL$1" "DUAL"@"SEL$1") END_OUTLINE_DATA */

Note-------------- Warning: basic plan statistics not available. These are only collected when: * hint 'gather_plan_statistics' is used for the statement or * parameter 'statistics_level' is set to 'ALL', at session or system level

2404/21/23

select * from table ( dbms_xplan.display_cursor (null,null, 'BASIC +OUTLINE +NOTE'));

Usage of: Outlines Profiles SQL Baselines

ALIASPEEK_BINDSPREDICATESPROJECTIONOUTLINESNOTE


2504/21/23

predicate Information (identified by operation id):--------------------------------------------------

2 - filter(("B"."EFFDT"= AND "B"."EFFSEQ"=)) 3 - access("E"."OFF_CYCLE"="A"."PAY_OFF_CYCLE_CAL" 5 - access("B"."COMPANY"="A"."COMPANY" AND "B"."PAYGROUP"="A"."PAYGROUP") 7 - access("A"."RUN_ID"='PD2' AND "A"."PAY_CONFIRM_RUN"='N') 8 - access("C"."EMPLID"="B"."EMPLID" AND "C"."EMPL_RCD#"="B"."EMPL_RCD#") 9 - access("D"."RETROPAY_SEQ_NO"="C"."RETROPAY_SEQ_NO") 11 - filter(("C"."RETROPAY_PRCS_FLAG"='C' AND "C"."RETROPAY_LOAD_SW"='Y'))

Access - uses structures (index, hash table etc)Filters – filters a return set


• http://oracle-randolf.blogspot.com/2009/07/planhashvalue-how-equal-and-stable-are_26.html

look for diffs even though the sql_id and plan_hash are the same

2604/21/23

HASH_VALUE PLAN_HASH_VALUE CHILD_NUMBER THE_HASH ARE_H---------- --------------- ------------ ---------- ----- 138930541 3776869225 0 3686240584 166324347 1231101765 1 2381182910 166324347 1231101765 2 2381182910 174856728 4804429 0 1186229766 DIFF! 174856728 4804429 1 2540836549

Filter Predicate CPU cost------------------------------------------------------------ ------------TO_NUMBER("V1")=1 AND "N2"=18 AND "N1"=998 1,070,604

Filter Predicate CPU cost------------------------------------------------------------ ------------"N1"=998 AND "N2"=18 AND TO_NUMBER("V1")=1 762,786

Jonathan Lewis CBO p 22-25

http://oracle-randolf.blogspot.com/2009/07/planhashvalue-how-equal-and-stable-are_26.html

Explain Plan Summary

2704/21/23

Version Method

8i or lower sql_trace

9i v$sql_plan


11g “”

For accurate explain plans

ERSS

ERSS – Extended Row Source Statistics

Starting in Oracle 9i statistics on Rows

CPUPhysical IOLogical IOElapsed time

became available on each step of the execution plan of an Oracle statement in

V$SQL_PLAN_STATISTICS_ALL

NOTE: only when collection is enabled

Real Statistics !!

ERSS across versions

•statistics_level=all•/*+ gather_plan_statistics */•sql_trace=true

•_rowsource_execution_statisticsset to true•Or sql_trace 9.2.0.2 to 9.2.0.5

9i ERSS

ERSS in

V$SQL_PLAN_STATISTICS(_ALL)

Enable

Or by setting SQL_TRACE in 9.2.0.2 through to 9.2.0.5 (or 10g)Alter session set "_rowsource_execution_statistics"=true;

9i ERSS Pitfalls

• _rowsource_execution_statistics

• Can be expensive

• sql_trace

• Turns on rows source stats

• Versions 9.2.0.2 to 9.2.0.5

• This issue is fixed in 9.2.0.5 (Server Patch Set) (set back on

in 10g with less sampling by default)

9i – v$sql_plan

Real plancol operation for a25 SELECT LPAD(' ',depth)||P.OPERATION||'_'||P.OPTIONS||' '||P.OBJECT_NAME operation , p.last_output_rows nrows -- , p.starts starts , LAST_CR_BUFFER_GETS bgets , LAST_DISK_READS pread , LAST_DISK_WRITES pwrites , LAST_ELAPSED_TIME elapsed FROM V$SQL_PLAN_statistics_all P WHERE p.hash_value=&hash_value order by child_number/

OPERATION NROWS BGETS PREAD PWRITES ELAPSED------------------------- ---------- ---------- ---------- ---------- ----------HASH JOIN_ 1 7 0 0 924 TABLE ACCESS_FULL EMP 1 3 0 0 84 TABLE ACCESS_FULL DEPT 4 4 0 0 51

Microseconds

10g ERSS

ERSS – Extended Row Source Statistics

1. enable ERSS (any one of the following)

a) alter session set statistics_level=all;– Attention “_rowsource_execution_stats”=false disables it

b) Select /*+ gather_plan_statistics */ … from …;c) Alter session set “_rowsource_execution_stats”=true;d) setting sql_trace

2. Get Plan Execution Statisticsselect * from table(dbms_xplan.display_cursor(null,null, 'ALLSTATS LAST'));

10g ERSS

alter session set statistics_level=all;select count(*) from scott.dept where deptno=10;select * from table(dbms_xplan.display_cursor(null,null, 'ALLSTATS LAST'));

PLAN_TABLE_OUTPUT----------------------------------------------------------------------------------------SQL_ID ckq08mgb67bp2, child number 1------------------------------------- select count(*) from scott.dept where deptno=10Plan hash value: 2236899148

----------------------------------------------------------------------------------------| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |----------------------------------------------------------------------------------------| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01 | 1 ||* 2 | INDEX UNIQUE SCAN| PK_DEPT | 1 | 1 | 1 |00:00:00.01 | 1 |----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):---------------------------------------------------

2 - access("DEPTNO"=10)

Estimated rows

Actual rows

ERSS Pitfalls

•alter session set statistics_level=all;

• sets _rowsource_statistics_sampfreq =1;

sometimes more expensive, but more accurate

value on 9i with sql_trace=true

•Select /*+ gather_plan_statistics */

• sets _rowsource_statistics_sampfreq =128;

Less expensive less accurate

Timings can be incorrect

http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/

ERSS summary

•Starting in 9i, Oracle records Row source statistics•Rows

•CPU

•IO

•Elapsed_time

•Have to enable with

• Statistics_level = all (more accurate, more expensive, 10g +)

• /*+ gather_plan_statistics */ (less accurate, less expensive, 10g+)

• Sql_trace = true (expensive accurate v9, expensive less accurate 10g)

3604/21/23

TCF : Intro

• When is a SQL execution plan optimal?• Only sure way: find one that is more efficient

• Better questions probably:

• fast enough

• Depends on your users and application

• resource usage acceptable

• Depends on your machine resources

• How would you check if you could

•=> TCF

3704/21/23

TCF

•Tuning by Cardinality Feedback

• Compare Estimated Rows vs Actual Rows

• Find discrepancies

• Large discrepancies could indicate wrong plan

Wolfgang Breitling http://www.centrexcc.com/Tuning%20by%20Cardinality%20Feedback.pdf

Greg Rahnhttp://structureddata.org/2007/11/21/troubleshooting-bad-execution-plans

TCF Key StatsEstimated: (explain plan)

• CARDINALITY - rows per iteration

Actual: (ERSS)• STARTS – iterations

• OUTPUT_ROWS - total rows

Thus these “should” be equal

cardinality output_rows/starts

starts*cardinality output_rows

Estimated Rows Actual Rows

TCF dbms_xplan.display_cursor()

Arguments:

-ROWS-BYTES-COST

Estimates ActualName Rows Bytes TempSpc

cost(% CPU) Time E-Rows starts A-Rows Buffers Reads Writes A-Time 0Mem 1MEM

0/1/M

BASIC X null X X X X XTYPICAL X X X X X XSERIAL X X X X X XALL X X X X XADVANCED X X X X XMEMSTATS X X X X X X X XALLSTATS X X X X X X X X X X XRUNSTATS_LAST X X X X X X X XRUNSTATS_TOT X X X X X X X XIOSTATS X X X X X X X X

Cumulative

10g TCF dbms_xplan.display_cursor()

0Mem 1MEM 0/1/M Used-Mem Used-Tmp Max-Tmp MEMSTATS X X TOT LAST LAST TOTALLSTATS X X TOT LAST LAST TOT

By default statistics are total but can add “LAST”Example:

Other:TQ IN-OUT PQ Distrib pstart pstop Instance

PARTITION X X XPARALLEL X XREMOTE X

select * from table ( dbms_xplan.display_cursor (null,null,'MEMSTATS LAST'));

Memory:

10g TCF dbms_xplan.display_cursor()

4204/21/23

----------------------------------------------------------------------------------------------------------|Operation |Starts|E-Rows|A-Rows| A-Time |Buffers|Reads|Writes|OMem|1Mem |UsedMem|UsedTmp|-----------------------------------------------------------------------------------------------------------|HASH GROUP BY | 1 | 1 | 1 |0:04.13 | 8153 | 721 | 721 | | | | || FILTER | 1 | | 1909 |0:04.12 | 8153 | 721 | 721 | | | | || HASH JOIN | 1 | 406 | 3413 |0:03.95 | 4725 | 721 | 721 |855K| 855K|578K(0)| | | TABLE ACCESS FULL | 1 | 15 | 15 |0:00.01 | 7 | 0 | 0 | | | | | | HASH JOIN | 1 | 812 | 3413 |0:03.90 | 4718 | 721 | 721 |830K| 830K|131K(0)| | | TABLE ACCESS BY INDEX R| 1 | 5 | 1 |0:00.01 | 3 | 0 | 0 | | | | | | INDEX RANGE SCAN | 1 | 5 | 1 |0:00.01 | 2 | 0 | 0 | | | | | | HASH JOIN | 1 |28213 | 111K|0:03.12 | 4715 | 721 | 721 |815K|2165K|909K(1)| 6144 | | HASH JOIN | 1 |27456 | 115K|0:01.58 | 3206 | 0 | 0 |035K|1035K|830K(0)| | | TABLE ACCESS FULL | 1 |13679 |13679 |0:00.03 | 184 | 0 | 0 | | | | | | TABLE ACCESS FULL | 1 |27456 | 122K|0:00.37 | 3022 | 0 | 0 | | | | | | TABLE ACCESS FULL | 1 |40000 |40000 |0:00.12 | 1509 | 0 | 0 | | | | | | SORT AGGREGATE | 1831 | 1 | 1831 |0:00.07 | 1833 | 0 | 0 | | | | | | FIRST ROW | 1831 | 1 | 1617 |0:00.04 | 1833 | 0 | 0 | | | | | | INDEX RANGE SCAN (MIN/M| 1831 | 1 | 1617 |0:00.02 | 1833 | 0 | 0 | | | | | | SORT AGGREGATE | 1593 | 1 | 1593 |0:00.06 | 1595 | 0 | 0 | | | | | | FIRST ROW | 1593 | 1 | 1593 |0:00.04 | 1595 | 0 | 0 | | | | | | INDEX RANGE SCAN (MI| 1593 | 1 | 1593 |0:00.02 | 1595 | 0 | 0 | | | | | ----------------------------------------------------------------------------------------------------------

Cumulative

dbms_xplan.display_cursor(null,null,’ALLSTATS’)

TCF : Discrepancies

4304/21/23

TCF: Less Discrepancy

4404/21/23

Cumlative Statistics


Customers try to find the slowest part of the query

Note, by default costs include cost of child steps. For graphical bar we subtract out the child steps, makes identifying the actual step that was most costly

TCF – skew reasonsPossible reasons for cardinality discrepancies

• Incorrect statistics• Data out of range issues

• Incorrect selectivity• Skew

• Histograms

• Data correlation • extended statistics,

• profiles, outlines, sql plan baselines

• dynamic_sampling=4

• Cardinality hint

• Functions in predicate • extended statistics

• Incorrect algorithm in CBO (ie bug)

Joins are much harder to calculate than Filters

TCF CARDINALITY Hint• select /*+ cardinality(a 100) */ * from dual a;

--------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |--------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 100 | 200 | 2 (0)| 00:00:01 || 1 | TABLE ACCESS FULL| DUAL | 100 | 200 | 2 (0)| 00:00:01 |-------------------------------------------------------------------------- unsupported ?

• /*+ dynamic_sampling(4) */

• Samples 32 blocks for all tables that have 2 or more columns referenced in the where clause

• /*+ dynamic_sampling(table 4) */ •Specific table in query

•Extended Statistics 11g (top p131)dbms_stats.create_extended_stats(ownname=> ‘owner’, tabname => ‘table’, extension => ‘(field1,field2)’)

TCF

• TCF => optimal execution plan path

• How about “Is the access path optimal ?

ie indexes, partitions, constraints

Christian Antognini p341 TOP

• < 5 lio per row

• 10-15 lio ok

• > 10-15 potentially sub-optimal

10g TCF summary

•Compare actual rows to estimated rows

•Use dbms_xplan.display_cursor

• Argument : RUNSTATS_TOT or RUNSTATS_LAST

• Memory and Sorting: ALLSTATS or ALLSTATS LAST

•Enable ERSS collection with

• Statistics_level = all

• /*+ gather_plan_statistics */

• sql_trace=true

4904/21/23

On 9i use v$sql_plan_statistics_all directly

VST

•VST = Visual SQL Tuning

5004/21/23

VST

5104/21/23

1. Tables and JoinsSELECT C.Phone_Number, C.Honorific, C.First_Name, C.Last_Name,

C.Suffix, C.Address_ID, A.Address_ID, A.Street_Address_Line1,

A.Street_Address_Line2, A.City_Name, A.State_Abbreviation,

A.ZIP_Code, OD.Deferred_Shipment_Date, OD.Item_Count,

ODT.Text, OT.Text, P.Product_Description, S.Shipment_Date

FROM Orders O, Order_Details OD, Products P, Customers C, Shipments S,

Addresses A, Code_Translations ODT, Code_Translations OT

WHERE UPPER(C.Last_Name) LIKE :Last_Name||'%'

AND UPPER(C.First_Name) LIKE :First_Name||'%'

AND OD.Order_ID = O.Order_ID

AND O.Customer_ID = C.Customer_ID

AND OD.Product_ID = P.Product_ID(+)

AND OD.Shipment_ID = S.Shipment_ID(+)

AND S.Address_ID = A.Address_ID(+)

AND O.Status_Code = OT.Code

AND OT.Code_Type = 'ORDER_STATUS'

AND OD.Status_Code = ODT.Code

AND ODT.Code_Type = 'ORDER_DETAIL_STATUS'

AND O.Order_Date > :Now - 366

ORDER BY C.Customer_ID, O.Order_ID DESC, S.Shipment_ID, OD.Order_Detail_ID;


SELECT …

FROM

Orders O,

Order_Details OD,

Products P,

Customers C,

Shipments S,

Addresses A,

Code_Translations ODT,

Code_Translations OT

WHERE

AND OD.Order_ID = O.Order_ID

AND O.Customer_ID = C.Customer_ID

AND OD.Product_ID = P.Product_ID(+)

AND OD.Shipment_ID = S.Shipment_ID(+)

AND S.Address_ID = A.Address_ID(+)

AND O.Status_Code = OT.Code

AND OT.Code_Type = 'ORDER_STATUS'

AND OD.Status_Code = ODT.Code

Tables

Orders O,

Order_Details OD,

Products P,

Customers C,

Shipments S,

Addresses A,



Joins

OD.Order_ID = O.Order_ID

O.Customer_ID = C.Customer_ID

OD.Product_ID = P.Product_ID(+)

OD.Shipment_ID = S.Shipment_ID(+)

S.Address_ID = A.Address_ID(+)

O.Status_Code = OT.Code

OD.Status_Code = ODT.Code

Dan Tow – SQL TUNING

2. Layout tables and connections


Tables

Orders O,

Order_Details OD,

Products P,

Customers C,

Shipments S,

Addresses A,



ODT

OD

P

C

A

O S

OTJoins








2. Layout tables and connections


Tables

Orders O,

Order_Details OD,

Products P,

Customers C,

Shipments S,

Addresses A,



ODT

OD

P

C

A

O S

OTJoins








Messy

2. Unstructured


ODT

OD

P

C

A

O S

OTJoins








NeaterNeeds some balancing algorithm

3. Parents and Children


Joins








ODT

OD

P

CA

OS

OT

Primary Key (unique index)

No index or non-unique

Master

Detail

Structurethe tree

3. Structured

Copyright 2006 Kyle

Hailey

ODT

OD

P

CA

OS

OT

Joins








Parent

Child

Good: A row from a Child only joins to one Parent

Bad: A row from a Parent can join to multiple rows in a Child

Parent

Child

Concept: join down first, before joining upwards

4. Join Diagram Validation


ODT

OD

P

CA

OS

OT

ODT

OD

P

C

A

OS

OT

ODT

OD

P

C

A

OS

OT

Cartesian Joins Problems Highlighted

4. Join Diagram Validation

Copyright 2006 Kyle

Hailey

ODT

OD

P

CA

OS

OT

ODT

OD

P

CA

OS

OTODT

OD

P

C

A

O

S

OT

OTODT

OD

P C

A

O

S

Well Defined in Schema

Missing Unique index – possible many to many

Unique key on both ends – one to one

Explain Plan


-----------------------------------------------------------------------| Id | Operation | Name | Cost |------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 278K|| 1 | TABLE ACCESS BY GLOBAL INDEX ROWID | ORDER_ITEMS | 3 || 2 | NESTED LOOPS | | 278K|| 3 | NESTED LOOPS | | 69829 || 4 | PARTITION HASH ALL | | 131 ||* 5 | TABLE ACCESS FULL | ORDERS | 131 || 6 | TABLE ACCESS BY GLOBAL INDEX ROWID| CUSTOMERS | 1 ||* 7 | INDEX UNIQUE SCAN | CUSTOMERS_PK | 0 ||* 8 | INDEX RANGE SCAN | ORDER_ITEMS_PK | 2 |------------------------------------------------------------------------

SELECT …FROM orders o ,

order_items oi, customers c WHERE o.order_id = oi.order_id and o.customer_id = c.customer_id and o.order_status <= 4;

---------------------------------------------------| Id | Operation | Name | Cost |---------------------------------------------------| 0 | SELECT STATEMENT | | 1058||* 1 | HASH JOIN | | 1058|| 2 | PARTITION HASH ALL | | 140|| 3 | TABLE ACCESS FULL | CUSTOMERS | 140|| 4 | PARTITION HASH ALL | | 439| |* 5 | HASH JOIN | | 439| |* 6 | TABLE ACCESS FULL| ORDERS | 130| | 7 | TABLE ACCESS FULL| ORDER_ITEMS | 293| ---------------------------------------------------

One Query, two plans, how are they different?

Comparing Plans

•Difficult Comparison (from Quest)


Graphical Explain Plan

Graphical Compare Still Difficult

Graphics


O CNested Loops

OINested Loops

O CHash Join

OIHash Join

Join Topology


Layout stays the same, overlays change

Easy to Compare1. Order Execution2. Type of Access

Choose a Layout


SELECT …FROM orders o ,

order_items oi, customers c WHERE o.order_id = oi.order_id and o.customer_id = c.customer_id and o.order_status <= 4;

Lets take a query and look at ways to lay the query out

VST: layouts


OI

C OSimplest diagram : replace table names with alias and draw lines for joins

If possible, put detail tables above master tables (important to find best join order)

VST: layouts


0.0020.8

3M7

If possible, include join ratios and filter ratios

filter ratio: Display next to table name.Ratio of Rows returned where table.field=value

join ratios:Display on join line next to driven table. Avg rows returned from driven table per single row from driving table where table1.field=table2.field

OI

C O

VST: layouts


0.0020.8

3M7

Order_Items

Customers Orders


0.002

0.8

3007

Orders

order_id

Order_Items

order_id

customer_id

Customers

customer_id

Cust_status Order_status

VST – Visual SQL Tuning

•Layout tables Graphically

• Details tables above Masters

• One to one relations side by side

• Many to many any which way

VST – best execution orderGiven 3 tables, what’s the best join Order?

Predicate Filter

VST – best execution order

Keep result to the smallest fraction as long as possible

Result set stays same size or smaller

Result generally get’s bigger

1. Start at most selective filter

2. Join towards masters

3. Join towards the most selective filters

Detail

master

SQL Tuning p136


Predicate Filter1

2

3

B -> C -> A


Start here

go to A or C?

Now what?

VST – What does Oracle do?

defaultordered

defaultordered

VST – one to one

One to One

VST – one to many

z

VST – cartesian

VST – implied cartesian

z

Something is wrongClient has *a* broker A client_transaction has *a* broker


z

Client transaction has a brokerSomething still wrong


8204/21/23

A client only has one broker at a time but might have many over time so we can take out the connection client to broker

VST – complicated

z

VST : by hand

F=.8

1

2

3

2280

40000

164733

15

13679

F=.001

VST : Oracle default

F=.001

F=.8

1

2

3

VST : default

A -> F -> A -> G -> B -> C-> D-> E

VST : by hand

B -> A -> C -> D -> F -> G

VST - results

8804/21/23

VST Summary

• Layout Details above Masters

• Should only be one top node

•Find Filter ratios

• Start at most selective

• Join downwards until have to join up

• Except in rare case that upward join is highly selective

8904/21/23

Real Time SQL Monitoringhttp://askdba.org/weblog/2009/09/11gr2-monitoring-real-time-sql-plan-execution-from-oracle-enterprise-manager/

http://askdba.org/weblog/2009/09/11gr2-monitoring-real-time-sql-plan-execution-from-oracle-enterprise-manager/


11g ASH extrasSQL ElapsedSQL Elapsed SQL_EXEC_ID SQL_EXEC_START

IN_CONNECTION_MGMT IN_PARSE IN_HARD_PARSE IN_SQL_EXECUTION IN_PLSQL_EXECUTION IN_PLSQL_RPC IN_PLSQL_COMPILATION IN_JAVA_EXECUTION IN_BIND IN_CURSOR_CLOSE

SQL_PLAN_LINE_ID SQL_PLAN_OPERATION SQL_PLAN_OPTIONS

CURRENT_ROW# EVENT# QC_SESSION_SERIAL# CONSUMER_GROUP_ID FLAGS

ETCETC

CPU Analysis – non TimedCPU Analysis – non Timed

SQL Row Source SQL Row Source

REMOTE_INSTANCE#RAC – remote transfersRAC – remote transfers

TOP_LEVEL_SQL_ID

TOP_LEVEL_SQL_OPCODE

Recursive SQLRecursive SQL

ASH

9204/21/23

10.1 10.2.0 10.2.0.3 11.1.0 11.2.0 SAMPLE_ID SAMPLE_ID SAMPLE_ID SAMPLE_ID SAMPLE_IDSAMPLE_TIME SAMPLE_TIME SAMPLE_TIME SAMPLE_TIME SAMPLE_TIME

IS_AWR_SAMPLE

SESSION_ID SESSION_ID SESSION_ID SESSION_ID SESSION_ID

SESSION_SERIAL# SESSION_SERIAL# SESSION_SERIAL# SESSION_SERIAL# SESSION_SERIAL#SESSION_TYPE SESSION_TYPE SESSION_TYPE SESSION_TYPE SESSION_TYPE

FLAGS FLAGSUSER_ID USER_ID USER_ID USER_ID USER_IDSQL_ID SQL_ID SQL_ID SQL_ID SQL_ID

IS_SQLID_CURRENTSQL_CHILD_NUMBER SQL_CHILD_NUMBER SQL_CHILD_NUMBER SQL_CHILD_NUMBER SQL_CHILD_NUMBERSQL_OPCODE SQL_OPCODE SQL_OPCODE SQL_OPCODE SQL_OPCODE

SQL_OPNAMEFORCE_MATCHING_SIGNATURE FORCE_MATCHING_SIGNATURE FORCE_MATCHING_SIGNATURE FORCE_MATCHING_SIGNATURE

TOP_LEVEL_SQL_ID TOP_LEVEL_SQL_IDTOP_LEVEL_SQL_OPCODE TOP_LEVEL_SQL_OPCODE

SQL_PLAN_HASH_VALUE SQL_PLAN_HASH_VALUE SQL_PLAN_HASH_VALUE SQL_PLAN_HASH_VALUE SQL_PLAN_HASH_VALUESQL_PLAN_LINE_ID SQL_PLAN_LINE_IDSQL_PLAN_OPERATION SQL_PLAN_OPERATIONSQL_PLAN_OPTIONS SQL_PLAN_OPTIONSSQL_EXEC_ID SQL_EXEC_IDSQL_EXEC_START SQL_EXEC_START

PLSQL_ENTRY_OBJECT_ID PLSQL_ENTRY_OBJECT_ID PLSQL_ENTRY_OBJECT_IDPLSQL_ENTRY_SUBPROGRAM_ID PLSQL_ENTRY_SUBPROGRAM_ID PLSQL_ENTRY_SUBPROGRAM_IDPLSQL_OBJECT_ID PLSQL_OBJECT_ID PLSQL_OBJECT_IDPLSQL_SUBPROGRAM_ID PLSQL_SUBPROGRAM_ID PLSQL_SUBPROGRAM_ID

QC_SESSION_ID QC_INSTANCE_ID QC_INSTANCE_ID QC_INSTANCE_ID QC_INSTANCE_IDQC_INSTANCE_ID QC_SESSION_ID QC_SESSION_ID QC_SESSION_ID QC_SESSION_ID

QC_SESSION_SERIAL# QC_SESSION_SERIAL#EVENT EVENT EVENT EVENT EVENTEVENT_ID EVENT_ID EVENT_ID EVENT_ID EVENT_IDEVENT# EVENT# EVENT# EVENT# EVENT#SEQ# SEQ# SEQ# SEQ# SEQ#

P1TEXT P1TEXT P1TEXT P1TEXTP1 P1 P1 P1 P1



WAIT_CLASS WAIT_CLASS WAIT_CLASS WAIT_CLASSWAIT_CLASS_ID WAIT_CLASS_ID WAIT_CLASS_ID WAIT_CLASS_ID

ASH

9304/21/23

10.1 10.2.0 10.2.0.3 11.1.0 11.2.0 WAIT_TIME WAIT_TIME WAIT_TIME WAIT_TIME WAIT_TIMESESSION_STATE SESSION_STATE SESSION_STATE SESSION_STATE SESSION_STATETIME_WAITED TIME_WAITED TIME_WAITED TIME_WAITED TIME_WAITED

BLOCKING_SESSION BLOCKING_SESSION BLOCKING_SESSION_STATUS BLOCKING_SESSION_STATUSBLOCKING_SESSION_STATUS BLOCKING_SESSION_STATUS BLOCKING_SESSION BLOCKING_SESSIONBLOCKING_SESSION_SERIAL# BLOCKING_SESSION_SERIAL# BLOCKING_SESSION_SERIAL# BLOCKING_SESSION_SERIAL#

BLOCKING_INST_IDBLOCKING_HANGCHAIN_INFO

CURRENT_OBJ# CURRENT_OBJ# CURRENT_OBJ# CURRENT_OBJ# CURRENT_OBJ#CURRENT_FILE# CURRENT_FILE# CURRENT_FILE# CURRENT_FILE# CURRENT_FILE#CURRENT_BLOCK# CURRENT_BLOCK# CURRENT_BLOCK# CURRENT_BLOCK# CURRENT_BLOCK#

CURRENT_ROW# CURRENT_ROW#TOP_LEVEL_CALL#TOP_LEVEL_CALL_NAME

CONSUMER_GROUP_ID CONSUMER_GROUP_IDXID XID XID XID

REMOTE_INSTANCE# REMOTE_INSTANCE#TIME_MODEL

IN_CONNECTION_MGMT IN_CONNECTION_MGMTIN_PARSE IN_PARSEIN_HARD_PARSE IN_HARD_PARSEIN_SQL_EXECUTION IN_SQL_EXECUTION

IN_PLSQL_EXECUTION IN_PLSQL_EXECUTIONIN_PLSQL_RPC IN_PLSQL_RPCIN_PLSQL_COMPILATION IN_PLSQL_COMPILATIONIN_JAVA_EXECUTION IN_JAVA_EXECUTIONIN_BIND IN_BINDIN_CURSOR_CLOSE IN_CURSOR_CLOSE

IN_SEQUENCE_LOADCAPTURE_OVERHEADREPLAY_OVERHEADIS_CAPTUREDIS_REPLAYED

SERVICE_HASH SERVICE_HASH SERVICE_HASH SERVICE_HASH SERVICE_HASHPROGRAM PROGRAM PROGRAM PROGRAM PROGRAMMODULE MODULE MODULE MODULE MODULEACTION ACTION ACTION ACTION ACTIONCLIENT_ID CLIENT_ID CLIENT_ID CLIENT_ID CLIENT_ID

ASH

9404/21/23

10.1 10.2.0 10.2.0.3 11.1.0 11.2.0 MACHINEPORTECIDTM_DELTA_TIMETM_DELTA_CPU_TIMETM_DELTA_DB_TIMEDELTA_TIMEDELTA_READ_IO_REQUESTSDELTA_WRITE_IO_REQUESTSDELTA_READ_IO_BYTESDELTA_WRITE_IO_BYTESDELTA_INTERCONNECT_IO_BYTESPGA_ALLOCATEDTEMP_SPACE_ALLOCATE

TM_DELTA_TIME Time interval (in microseconds) over which TM_DELTA_CPU_TIME and TM_DELTA_DB_TIME are accumulated

TM_DELTA_CPU_TIME Amount of time this session spent on CPU over the last TM_DELTA_TIME microseconds

TM_DELTA_DB_TIME Amount of time spent by this session in database calls over the last TM_DELTA_TIMEmicroseconds

DELTA_TIME Time interval (in microseconds) since the last time this session was sampled or created, over which the next five statistics are accumulated

DELTA_READ_IO_REQUESTS Number of read I/O requests made by this session over the last DELTA_TIME microseconds

DELTA_WRITE_IO_REQUESTS Number of write I/O requests made by this session over the last DELTA_TIME microseconds

DELTA_READ_IO_BYTES Number of I/O bytes read by this session over the last DELTA_TIME microseconds

DELTA_WRITE_IO_BYTES Number of I/O bytes written by this session over the last DELTA_TIME microseconds

DELTA_INTERCONNECT_IO_BYTES Number of I/O bytes sent over the I/O interconnect over the last DELTA_TIME microseconds

PGA_ALLOCATED Amount of PGA memory (in bytes) consumed by this session at the time this sample was taken

TEMP_SPACE_ALLOCATED Amount of TEMP memory (in bytes) consumed by this session at the time this sample was taken

http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/dynviews_1007.htm

http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/dynviews_1007.htm

Outlines, Profiles, Baselines

• Outlines 8i

• Profiles 10g

• Baselines 11

9504/21/23

Outline tables

ol$ OL_NAME SQL_TEXT TEXTLEN SIGNATURE HASH_VALUE HASH_VALUE2 CATEGORY VERSION CREATOR TIMESTAMP FLAGS HINTCOUNT SPARE1 SPARE2

9604/21/23

ol$hint OL_NAME HINT# CATEGORY HINT_TYPE HINT_TEXT STAGE# NODE# TABLE_NAME TABLE_TIN TABLE_POS REF_ID USER_TABLE_NAME

COST CARDINALITY BYTES HINT_TEXTOFF HINT_TEXTLEN JOIN_PRED SPARE1 SPARE2 HINT_STRING

ol$nodes OL_NAME

CATEGORY

NODE_ID

PARENT_ID

NODE_TYPE

NODE_TEXTLEN

NODE_TEXTOFF

NODE_NAME

If you drop the hints in ol$hint for a name then rename another set of hints with the old name then the sql text in ol$ will get the new hints

Outlines, Profiles, Baselines

•Outlines are way outdated in 11g, they still take precedence over Baselines

•Baselines can be switched between statements even easier than outlines

•http://kerryosborne.oracle-guy.com/category/oracle/plan-stability/

http://kerryosborne.oracle-guy.com/category/oracle/plan-stability/

http://kerryosborne.oracle-guy.com/category/oracle/plan-stability/

SQL Plan Management

http://68.142.116.68/docs/cd/B28359_01/license.111/b28287/options.htm

The Tuning Pack includes the following features:

• SQL Access Advisor

• SQL Tuning Advisor

• Automatic SQL Tuning

• SQL Tuning Sets

• Automatic Plan Evolution of SQL Plan Management

• SQL Monitoring

• Reorganize objects

In order to use the features listed above, you must purchase licenses for the Tuning Pack, with one exception: SQL Tuning

Sets can be used if you have licensed either the Tuning Pack or Oracle Real Application Testing. A new initialization

parameter, CONTROL_MANAGEMENT_PACK_ACCESS, is introduced to control access to the Diagnostic Pack and

Tuning Pack in the database server. This parameter can be set to one of three values:

• DIAGNOSTIC+TUNING: Diagnostic Pack and Tuning Pack functionally is enabled in the database server.

• DIAGNOSTIC: Only Diagnostic Pack functionality is enabled in the server.

• NONE: Diagnostic Pack and Tuning pack functionally is disabled in the database server.

The Tuning Pack functionality can be accessed by the Enterprise Manager links as well as through the database server

command-line APIs. The use of either interface requires licensing of the Tuning Pack

9804/21/23

http://68.142.116.68/docs/cd/B28359_01/license.111/b28287/options.htm

Table Statistics

•Collected automatically in 10g

•Backups kept for 30 days

•Can revert to to older

•Can compare current to another day

•Can collect without posting

9904/21/23

1 10/17/2015 sql tuning kyle hailey explain plans, erss, tcf, vst,rtsm

Documents