Oracle 19c RU Release Update 19.19 nice little enhancement: DBA_HIST_SQL_PLAN ACCESS_PREDICATES and FILTER_PREDICATES columns populated

I've recently found out by coincidence a nice little enhancement that apparently was introduced with the 19.19 Release Update - a backport of the fix that was originally introduced with Oracle 20c / 21c populating the ACCESS_PREDICATES and FILTER_PREDICATES columns in DBA_HIST_SQL_PLAN.

This fix is truly a long awaited one - in fact the problem originally came from an ORA-600 error / bug in Oracle 9i (!) when populating execution plans in STATSPACK if I remember correctly, the workaround back then was setting the parameter "_cursor_plan_unparse_enabled" to FALSE which resulted among other things in those columns not being populated. This had been carried forward to AWR when it was  originally implemented in Oracle 10g.

The original bug / root cause was fixed a very long time ago (although there is for example bug ORA-600 [qksxaCompactToXml:2] When Generating An Execution Plan (Doc ID 1626499.1) which applies to Oracle 11.2 fixed in 12.1) but in all that time Oracle never managed to enhance the AWR code to include those columns again when populating DBA_HIST_SQL_PLAN.

When Oracle 20c / 21c came out Oracle finally included the enhancement populating those columns in DBA_HIST_SQL_PLAN.

And now - although it is not part of the official documentation listing the new features added to 19c Release Updates (which also misses at least the backport of Automatic SQL Tuning Sets to Oracle 19.7 RU) - according to MyOracleSupport document Missing FILTER_PREDICATES And ACCESS_PREDICATES In DBA-HIST_SQL_PLAN (Doc ID 2900189.1) this has been backported to the 19.19 RU.

I currently only have access to the 19.20 RU, so I can't confirm that it's already there in 19.19 but in 19.20 definitely those columns in DBA_HIST_SQL_PLAN are populated (and in 19.16 they definitely don't get populated) - so this is very good news for those that regularly deal with execution plan details. 

Without the ACCESS_PREDICATES and FILTER_PREDICATES it's not possible to fully understand the meaning of an execution plan - for example you might miss the fact that there is a datatype issue that introduces an implicit datatype conversion (like a TO_NUMBER function - 23c adds the "SQL Analysis" part to the execution plan notes), you can't tell how efficient an index access path is (are there FILTER predicates on index access operation level in addition to the ACCESS predicates indicating a suboptimal usage of the index), you might not be able to tell if a HASH JOIN includes additional FILTER predicates (potentially eating up a lot of CPU), you might not be able to fully understand the shape of an execution plan because you don't see what actually happens as part of a FILTER operation to name just a few cases where those columns are crucial for understanding / assessing properly an execution plan.

Addendum / clarification: Not only these columns are now populated in DBA_HIST_SQL_PLAN, but DBMS_XPLAN.DISPLAY_AWR (now deprecated  - you should use DBMS_XPLAN.DISPLAY_WORKLOAD_REPOSITORY instead in a CDB/PDB configuration) shows now happily a "Predicate Information" section when retrieving execution plans from AWR.

Time Model Bug

Tasks that are performed via jobs in the database will be double accounted in the system time model that has been introduced with Oracle 10g.

So if you execute significant workload via DBMS_JOB or DBMS_SCHEDULER any system time model related statistic like DB Time, DB CPU etc. that gets recorded for that workload gets double accounted.

This bug is not particularly relevant since your top workloads will still be the same top workloads, because all other statistics (like Elapsed Time, CPU, Buffer Gets etc.) are not affected by the bug.

I mention it only here since the bug (see below for details) as of the time of writing can't yet be found on My Oracle Support in the bug database but I recently came across several AWR reports where the majority of workload was generated via job processes and therefore the time model statistics were effectively doubled.

It might help as a viable explanation if you sometimes wonder why an AWR or Statspack report only captures 50% or less of the recorded total DB Time or DB CPU and where this unaccounted time has gone. If a significant part of the workload during the reporting period has been performed by sessions controlled via DBMS_JOB or DBMS_SCHEDULER then probably most of the unaccounted time is actually not unaccounted but the time model statistics are wrong.

So if you have such an otherwise unexplainable unaccounted DB Time / DB CPU etc. you might want to check if significant workload during the reporting period was executed via the job system. Note that I don't say that this is the only possible explanation of such unaccounted time - there might be other reasons like uninstrumented waits, other bugs etc.

Of course all the percentages that are shown in the AWR / ADDM / Statspack reports that refer to "Percentage of DB Time" or "Percentage of DB CPU" will be too small in such cases.

If the majority of workload during the reporting period has been generated by jobs then you can safely assume that the time model statistics have to be divided by 2 (and the percentages have to be doubled). If you have a mixture of jobs and regular foreground sessions then it will be harder to derive the correct time model statistics.

Note that the "Active Session History" (ASH) is not affected by the bug - the ASH reports always were consistent in my tests regarding the DB Time (respectively the number of samples) and CPU time information.

The following simple test case can be used to reproduce the issue at will. Ideally you should have exclusive access to the test system since any other concurrent activity will affect the test results.

You might want to check the 1000000000 iterations of the simple PL/SQL loop on your particular CPU - on my test system this takes approx. 46 seconds to complete.

The first version assumes that a PERFSTAT user with an installed STATSPACK is present in the database since STATSPACK doesn't require an additional license. An AWR variant follows below.

alter session set nls_language = american nls_territory = america;

store set .settings replace

set echo on timing on define on

define iter="1000000000"

variable snap1 number

exec :snap1 := statspack.snap

declare
n_cnt binary_integer;
begin
n_cnt := 0;
for i in 1..&iter loop
n_cnt := n_cnt + 1;
end loop;
end;
/

variable snap2 number

exec :snap2 := statspack.snap

/* Uncomment this if you want to test via DBMS_JOB
variable job_id number

begin
dbms_job.submit(:job_id, '
declare
n_cnt binary_integer;
n_status integer;
begin
n_cnt := 0;
for i in 1..&iter loop
n_cnt := n_cnt + 1;
end loop;
n_status := dbms_pipe.send_message(''bg_job_complete'');
end;
');
end;
/

commit;
*/

/* Uncomment this if you want to test via DBMS_SCHEDULER */
begin
dbms_scheduler.create_job(
job_name => dbms_scheduler.generate_job_name
, job_type => 'PLSQL_BLOCK'
, job_action => '
declare
n_cnt binary_integer;
n_status integer;
begin
n_cnt := 0;
for i in 1..&iter loop
n_cnt := n_cnt + 1;
end loop;
n_status := dbms_pipe.send_message(''bg_job_complete'');
end;
' , enabled => true);
end;
/

declare
pipe_status integer;
begin
pipe_status := dbms_pipe.receive_message('bg_job_complete');
end;
/

declare
pipe_id integer;
begin
pipe_id := dbms_pipe.remove_pipe('bg_job_complete');
end;
/

variable snap3 number

exec :snap3 := statspack.snap

rem set heading off pagesize 0 feedback off linesize 500 trimspool on termout off echo off verify off

prompt Enter PERFSTAT password

connect perfstat

column dbid new_value dbid noprint

select dbid from v$database;

column instance_number new_value inst_num noprint

select instance_number from v$instance;

column b_id new_value begin_snap noprint
column e_id new_value end_snap noprint

select :snap1 as b_id, :snap2 as e_id from dual;
define report_name=sp_foreground.txt

@?/rdbms/admin/sprepins

column dbid new_value dbid noprint

select dbid from v$database;

column instance_number new_value inst_num noprint

select instance_number from v$instance;

column b_id new_value begin_snap noprint
column e_id new_value end_snap noprint

select :snap2 as b_id, :snap3 as e_id from dual;
define report_name=sp_background.txt

@?/rdbms/admin/sprepins

undefine iter

@.settings

set termout on

Here is the same test case but with AWR reports (requires additional diagnostic license)

alter session set nls_language = american nls_territory = america;

store set .settings replace

set echo on timing on define on

define iter="1000000000"

column snap1 new_value awr_snap1 noprint

select dbms_workload_repository.create_snapshot as snap1 from dual;

declare
n_cnt binary_integer;
begin
n_cnt := 0;
for i in 1..&iter loop
n_cnt := n_cnt + 1;
end loop;
end;
/

column snap2 new_value awr_snap2 noprint

select dbms_workload_repository.create_snapshot as snap2 from dual;

/* Uncomment this if you want to test via DBMS_JOB
variable job_id number

begin
dbms_job.submit(:job_id, '
declare
n_cnt binary_integer;
n_status integer;
begin
n_cnt := 0;
for i in 1..&iter loop
n_cnt := n_cnt + 1;
end loop;
n_status := dbms_pipe.send_message(''bg_job_complete'');
end;
');
end;
/

commit;
*/

/* Uncomment this if you want to test via DBMS_SCHEDULER */
begin
dbms_scheduler.create_job(
job_name => dbms_scheduler.generate_job_name
, job_type => 'PLSQL_BLOCK'
, job_action => '
declare
n_cnt binary_integer;
n_status integer;
begin
n_cnt := 0;
for i in 1..&iter loop
n_cnt := n_cnt + 1;
end loop;
n_status := dbms_pipe.send_message(''bg_job_complete'');
end;
' , enabled => true);
end;
/

declare
pipe_status integer;
begin
pipe_status := dbms_pipe.receive_message('bg_job_complete');
end;
/

declare
pipe_id integer;
begin
pipe_id := dbms_pipe.remove_pipe('bg_job_complete');
end;
/

column snap3 new_value awr_snap3 noprint

select dbms_workload_repository.create_snapshot as snap3 from dual;

set heading off pagesize 0 feedback off linesize 500 trimspool on termout off echo off verify off

spool awr_foreground.html

select
output
from
table(
sys.dbms_workload_repository.awr_report_html(
(select dbid from v$database)
, (select instance_number from v$instance)
, &awr_snap1
, &awr_snap2
)
);

spool off

spool awr_background.html

select
output
from
table(
sys.dbms_workload_repository.awr_report_html(
(select dbid from v$database)
, (select instance_number from v$instance)
, &awr_snap2
, &awr_snap3
)
);

spool off

spool awr_diff.html

select
output
from
table(
sys.dbms_workload_repository.awr_diff_report_html(
(select dbid from v$database)
, (select instance_number from v$instance)
, &awr_snap1
, &awr_snap2
, (select dbid from v$database)
, (select instance_number from v$instance)
, &awr_snap2
, &awr_snap3
)
);

spool off

undefine awr_snap1
undefine awr_snap2
undefine awr_snap3

undefine iter

column snap1 clear
column snap2 clear
column snap3 clear

@.settings

set termout on

And here is a sample snippet from a generated Statspack report on a single CPU system with nothing else running on the system:

Normal foreground execution:

STATSPACK report for

Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
orcl112 1 05-Aug-10 08:21 11.2.0.1.0 NO

Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
XXXX Microsoft Windows IA ( 1 0 0 2.0

Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------
Begin Snap: 13 05-Aug-10 08:34:17 25 1.2
End Snap: 14 05-Aug-10 08:35:05 25 1.2
Elapsed: 0.80 (mins) Av Act Sess: 1.1
DB time: 0.87 (mins) DB CPU: 0.80 (mins)

Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 104M Std Block Size: 8K
Shared Pool: 128M Log Buffer: 6,076K

Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ------------------ ----------------- ----------- -----------
DB time(s): 1.1 2.4 0.09 3.99
DB CPU(s): 1.0 2.2 0.08 3.68

Execution via Job/Scheduler:

STATSPACK report for

Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
orcl112 1 05-Aug-10 08:21 11.2.0.1.0 NO

Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
XXXX Microsoft Windows IA ( 1 0 0 2.0

Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------
Begin Snap: 14 05-Aug-10 08:35:05 25 1.2
End Snap: 15 05-Aug-10 08:35:53 24 1.3
Elapsed: 0.80 (mins) Av Act Sess: 1.9
DB time: 1.55 (mins) DB CPU: 1.54 (mins)

Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 104M Std Block Size: 8K
Shared Pool: 128M Log Buffer: 6,076K

Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ------------------ ----------------- ----------- -----------
DB time(s): 1.9 92.8 0.79 7.74
DB CPU(s): 1.9 92.1 0.78 7.68

As you might have guessed my single CPU test system has not been added a second CPU when performing the same task via DBMS_SCHEDULER / DBMS_JOB yet the time model reports (almost) 2 DB Time / DB CPU seconds and active sessions per second in that case.

I have reproduced the bug on versions 10.2.0.4, 11.1.0.7 and 11.2.0.1 but very likely all versions supporting the time model are affected.

A (non-public) bug "9882245 - DOUBLE ACCOUNTING OF SYS MODEL TIMINGS FOR WORKLOAD RUN THROUGH JOBS" has been filed for it, but the fix is not available yet therefore as far as I know it is not yet part of any available patch set / PSU.

Note that there seems to a different issue with the DB CPU time model component: If you have a system that reports more CPUs than sockets (for example a Power5, Power6 or Power7 based IBM server that reports 16 sockets / 32 CPUs) then the DB CPU component gets reduced by approximately 50%, which means it is divided by 2.

This means in combination with above bug that you end up with a doubled DB Time component for tasks executed via jobs, but the DB CPU time model component is in the right ballpark since the doubled DB CPU time gets divided by 2.

I don't know if the bug fix also covers this issue, so you might want to keep this in mind when checking any time model based information.

Plan stability in 10g - using existing cursors to create Stored Outlines and SQL profiles

Update Jan 2011: Since this post is still among the most popular ones of this blog although being almost two years old it is probably worth an update.

- The most important information that you need to be aware of if you plan to use SQL Profiles is that you need an Enterprise Edition + Diagnostic Pack + Tuning Pack license. If you don't have these licenses you are not allowed to use SQL Profiles, or the other way around Oracle can claim you need to pay these licenses if you're going to use SQL Profiles.

Therefore if you're already on Oracle 11g you might want to use SQL Baselines instead for the same purpose - they seem to be available in all Editions and don't require any further licenses.

Update August 2012: SQL Baselines are only available with Enterprise Edition.

Jonathan Lewis for example recently wrote a short note on how to apply a baseline from a hinted statement to a non-hinted, which is what you usually want to achieve when dealing with third-party applications where you can't modify the source code.

More details about SQL Baselines can be found in the documentation, Kerry Osborne for example has some more examples and quirks he found summarized in his post about SQL Baselines.

If you're not yet on 11g and therefore can't use SQL Baselines you can still use Stored Outlines instead of SQL Profiles if you don't have the licences mentioned - as shown below the DBMS_OUTLN.CREATE_OUTLINE procedure unfortunately doesn't always work as expected. Therefore you can try to "hack" a Stored Outline as for example demonstrated by Charles Hooper here. His post also contains references to other sources on My Oracle Support and by Jonathan Lewis that describe that technique in more detail.

- I'm a bit puzzled that this post is such popular. I spend a significant amount of my time on performance related issues but I rarely resort to the techniques described here and the other mentioned posts about "Plan Stability". So I'm a bit curious and would like to encourage readers to leave a comment here why they think they need to use "Plan Stability" - there are usually a lot of others options I would evaluate first before thinking about using some kind of Plan Stability.

Original post: If you have the need for plan stability - that is telling the database to use a particular execution plan no matter what the optimizer thinks otherwise - then you might be in the situation that the "good" execution plan is already available in the shared pool or in the AWR, so it would be handy if you could simply tell Oracle to use that particular execution plan to create a Stored Outline.

Note that in 11g this is all possible using the new SQL Plan Management framework (SPM), but that is not available in 10g, so we need to think differently.

In 10g the DBMS_OUTLN package has been enhanced with the CREATE_OUTLINE procedure to create an outline from an existing child cursor in the shared pool.

Please note that in releases prior to 10.2.0.4 there was a severe bug that caused your session to crash when using DBMS_OUTLN.CREATE_OUTLINE (Bug 5454975 which has been fixed in 10.2.0.4). The workaround is to enable the creation of stored outlines by issuing "alter session set create_stored_outlines = true;" before using DBMS_OUTLN.CREATE_OUTLINE. For more information see the Metalink Notes 463288.1 and 445126.1.

Note that from 10g on the hints required to create an outline are stored as part of the plan table in the OTHER_XML column as part of the XML detail information.

You can use the ADVANCED or OUTLINE option of the DBMS_XPLAN.DISPLAY* functions to display that OUTLINE information. For more information see e.g. here.

So let's try DBMS_OUTLN.CREATE_OUTLINE in 10.2.0.4:

SQL> SQL> drop table t_fetch_first_rows purge; Table dropped. SQL> SQL> create table t_fetch_first_rows ( 2 id number not null, 3 name varchar2(30) not null, 4 type varchar2(30) not null, 5 measure number 6 ); Table created. SQL> SQL> create index idx_fetch_first_rows on t_fetch_first_rows (type, id); Index created. SQL> SQL> -- create an empty table SQL> -- and gather statistics on it SQL> exec dbms_stats.gather_table_stats(null, 't_fetch_first_rows', no_invalidate=>true) PL/SQL procedure successfully completed. SQL> SQL> -- now put in some data SQL> insert /*+ append */ into t_fetch_first_rows ( 2 id, 3 name, 4 type, 5 measure) 6 select object_id, object_name, object_type, object_id as measure 7 from all_objects, (select level as id from dual connect by level <= 1000) dup 8 where object_type in ('VIEW', 'SCHEDULE') 9 and rownum <= 1000; 1000 rows created. SQL> SQL> commit; Commit complete. SQL> SQL> -- This is going to use SQL> -- the wrong plan SQL> -- that we - only for demonstration purposes - SQL> -- attempt to keep now SQL> select sum(measure), count(*) from ( 2 select * from t_fetch_first_rows 3 where type = 'VIEW' 4 order by id 5 ); SUM(MEASURE) COUNT(*) ------------ ---------- 900000 1000 SQL> SQL> -- uses index SQL> select * from table(dbms_xplan.display_cursor(null, null, 'OUTLINE')); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- SQL_ID c2trqja6wh561, child number 0 ------------------------------------- select sum(measure), count(*) from ( select * from t_fetch_first_rows where type = 'VIEW' order by id ) Plan hash value: 1903859112 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 1 (100)| | 1 | SORT AGGREGATE | | 1 | 43 | | | 2 | TABLE ACCESS BY INDEX ROWID| T_FETCH_FIRST_ROWS | 1 | 43 | 0 (0)| |* 3 | INDEX RANGE SCAN | IDX_FETCH_FIRST_ROWS | 1 | | 0 (0)| ------------------------------------------------------------------------------------------ Outline Data ------------- /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRST_ROWS"."ID")) END_OUTLINE_DATA */ Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("TYPE"='VIEW') 41 rows selected. SQL> SQL> -- now gather statistics again SQL> -- on table with data SQL> exec dbms_stats.gather_table_stats(null, 't_fetch_first_rows', no_invalidate=>true) PL/SQL procedure successfully completed. SQL> SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> -- now the EXPLAIN PLAN tells us SQL> -- full table scan SQL> select * from table(dbms_xplan.display(null, null, 'OUTLINE')); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 2125410158 ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | |* 2 | TABLE ACCESS FULL| T_FETCH_FIRST_ROWS | 1000 | 11000 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------- Outline Data ------------- /*+ BEGIN_OUTLINE_DATA FULL(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2") OUTLINE(@"SEL$2") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$73523A42") OUTLINE(@"SEL$1") MERGE(@"SEL$73523A42") OUTLINE_LEAF(@"SEL$51F12574") ALL_ROWS OPT_PARAM('query_rewrite_enabled' 'false') OPTIMIZER_FEATURES_ENABLE('10.2.0.4') IGNORE_OPTIM_EMBEDDED_HINTS END_OUTLINE_DATA */ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("TYPE"='VIEW') 33 rows selected. SQL> SQL> -- These are the hints SQL> -- stored in the child cursor SQL> -- in the shared pool SQL> -- It clearly shows an index access SQL> select 2 substr(extractvalue(value(d), '/hint'), 1, 100) as outline_hints 3 from 4 xmltable('/*/outline_data/hint' 5 passing ( 6 select 7 xmltype(other_xml) as xmlval 8 from 9 v$sql_plan 10 where 11 hash_value = 2378699969 12 and child_number = 0 13 and other_xml is not null 14 ) 15 ) d; OUTLINE_HINTS ---------------------------------------------------------------------------------------------------- IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRS 11 rows selected. SQL> SQL> -- Create the outline based on that cursor SQL> exec dbms_outln.create_outline(2378699969, 0, 'TEST') PL/SQL procedure successfully completed. SQL> SQL> -- Oops, where is my index scan gone? SQL> select substr(hint, 1, 100) as hint from user_outline_hints; HINT -------------------------------------------------------------------------------- FULL(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2") OUTLINE(@"SEL$2") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$73523A42") OUTLINE(@"SEL$1") MERGE(@"SEL$73523A42") OUTLINE_LEAF(@"SEL$51F12574") ALL_ROWS OPT_PARAM('query_rewrite_enabled' 'false') OPTIMIZER_FEATURES_ENABLE('10.2.0.4') IGNORE_OPTIM_EMBEDDED_HINTS 11 rows selected. SQL> SQL> -- Use the outline SQL> alter session set use_stored_outlines = TEST; Session altered. SQL> SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> -- Uses outline (see Note section) SQL> -- but full table scan SQL> -- So that didn't work as expected SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 2125410158 ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | |* 2 | TABLE ACCESS FULL| T_FETCH_FIRST_ROWS | 1000 | 11000 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("TYPE"='VIEW') Note ----- - outline "SYS_OUTLINE_09032900314557403" used for this statement 18 rows selected. SQL> SQL> alter session set use_stored_outlines = false; Session altered. SQL> SQL> -- drop the outline SQL> declare 2 outline_name varchar2(30); 3 begin 4 select 5 name 6 into 7 outline_name 8 from 9 user_outlines 10 where 11 category = 'TEST'; 12 13 execute immediate 'drop outline ' || outline_name; 14 end; 15 / PL/SQL procedure successfully completed. SQL> SQL> -- This is the plan SQL> -- we get based on the present statistics SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 2125410158 ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | |* 2 | TABLE ACCESS FULL| T_FETCH_FIRST_ROWS | 1000 | 11000 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("TYPE"='VIEW') 14 rows selected. SQL> SQL> spool off

So that didn't work as expected. Although we were able to create an outline from the child cursor, it obviously didn't use the plan associated with the child cursor. Tracing the session didn't reveal why the CREATE_OUTLINE didn't use the outline information available from the shared pool.

Running the same test case in a slightly different order so that the outline is created before the statistics change corroborates the theory that the DBMS_OUTLN.CREATE_OUTLINE procedure might take the SQL from the cursor and internally execute an CREATE OUTLINE ... ON ..., and for whatever reason doesn't use the already available outline information.

SQL> SQL> drop table t_fetch_first_rows purge; Table dropped. SQL> SQL> create table t_fetch_first_rows ( 2 id number not null, 3 name varchar2(30) not null, 4 type varchar2(30) not null, 5 measure number 6 ); Table created. SQL> SQL> create index idx_fetch_first_rows on t_fetch_first_rows (type, id); Index created. SQL> SQL> -- create an empty table SQL> -- and gather statistics on it SQL> exec dbms_stats.gather_table_stats(null, 't_fetch_first_rows', no_invalidate=>true) PL/SQL procedure successfully completed. SQL> SQL> -- now put in some data SQL> insert /*+ append */ into t_fetch_first_rows ( 2 id, 3 name, 4 type, 5 measure) 6 select object_id, object_name, object_type, object_id as measure 7 from all_objects, (select level as id from dual connect by level <= 1000) dup 8 where object_type in ('VIEW', 'SCHEDULE') 9 and rownum <= 1000; 1000 rows created. SQL> SQL> commit; Commit complete. SQL> SQL> -- This is going to use SQL> -- the wrong plan SQL> -- that we - only for demonstration purposes - SQL> -- attempt to keep now SQL> select sum(measure), count(*) from ( 2 select * from t_fetch_first_rows 3 where type = 'VIEW' 4 order by id 5 ); SUM(MEASURE) COUNT(*) ------------ ---------- 900000 1000 SQL> SQL> -- uses index SQL> select * from table(dbms_xplan.display_cursor(null, null, 'OUTLINE')); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- SQL_ID c2trqja6wh561, child number 0 ------------------------------------- select sum(measure), count(*) from ( select * from t_fetch_first_rows where type = 'VIEW' order by id ) Plan hash value: 1903859112 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 1 (100)| | 1 | SORT AGGREGATE | | 1 | 43 | | | 2 | TABLE ACCESS BY INDEX ROWID| T_FETCH_FIRST_ROWS | 1 | 43 | 0 (0)| |* 3 | INDEX RANGE SCAN | IDX_FETCH_FIRST_ROWS | 1 | | 0 (0)| ------------------------------------------------------------------------------------------ Outline Data ------------- /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRST_ROWS"."ID")) END_OUTLINE_DATA */ Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("TYPE"='VIEW') 41 rows selected. SQL> SQL> -- Create the outline based on that cursor SQL> exec dbms_outln.create_outline(2378699969, 0, 'TEST') PL/SQL procedure successfully completed. SQL> SQL> -- Now we have the index scan in the outline SQL> select substr(hint, 1, 100) as hint from user_outline_hints; HINT -------------------------------------------------------------------------------- INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS". OUTLINE(@"SEL$2") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$73523A42") OUTLINE(@"SEL$1") MERGE(@"SEL$73523A42") OUTLINE_LEAF(@"SEL$51F12574") ALL_ROWS OPT_PARAM('query_rewrite_enabled' 'false') OPTIMIZER_FEATURES_ENABLE('10.2.0.4') IGNORE_OPTIM_EMBEDDED_HINTS 11 rows selected. SQL> SQL> -- now gather statistics again SQL> -- on table with data SQL> exec dbms_stats.gather_table_stats(null, 't_fetch_first_rows', no_invalidate=>true) PL/SQL procedure successfully completed. SQL> SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> -- now the EXPLAIN PLAN tells us SQL> -- full table scan SQL> select * from table(dbms_xplan.display(null, null, 'OUTLINE')); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 2125410158 ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | |* 2 | TABLE ACCESS FULL| T_FETCH_FIRST_ROWS | 1000 | 11000 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------- Outline Data ------------- /*+ BEGIN_OUTLINE_DATA FULL(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2") OUTLINE(@"SEL$2") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$73523A42") OUTLINE(@"SEL$1") MERGE(@"SEL$73523A42") OUTLINE_LEAF(@"SEL$51F12574") ALL_ROWS OPT_PARAM('query_rewrite_enabled' 'false') OPTIMIZER_FEATURES_ENABLE('10.2.0.4') IGNORE_OPTIM_EMBEDDED_HINTS END_OUTLINE_DATA */ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("TYPE"='VIEW') 33 rows selected. SQL> SQL> -- These are the hints SQL> -- stored in the child cursor SQL> -- in the shared pool SQL> -- It clearly shows an index access SQL> select 2 substr(extractvalue(value(d), '/hint'), 1, 100) as outline_hints 3 from 4 xmltable('/*/outline_data/hint' 5 passing ( 6 select 7 xmltype(other_xml) as xmlval 8 from 9 v$sql_plan 10 where 11 hash_value = 2378699969 12 and child_number = 0 13 and other_xml is not null 14 ) 15 ) d; OUTLINE_HINTS ---------------------------------------------------------------------------------------------------- IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRS 11 rows selected. SQL> SQL> -- Use the outline SQL> alter session set use_stored_outlines = TEST; Session altered. SQL> SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> -- Uses outline (see Note section) SQL> -- this time correctly SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 1903859112 ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 9 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | | 2 | TABLE ACCESS BY INDEX ROWID| T_FETCH_FIRST_ROWS | 1000 | 11000 | 9 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN | IDX_FETCH_FIRST_ROWS | 1000 | | 4 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("TYPE"='VIEW') Note ----- - outline "SYS_OUTLINE_09032900320095604" used for this statement 19 rows selected. SQL> SQL> alter session set use_stored_outlines = false; Session altered. SQL> SQL> -- drop the outline SQL> declare 2 outline_name varchar2(30); 3 begin 4 select 5 name 6 into 7 outline_name 8 from 9 user_outlines 10 where 11 category = 'TEST'; 12 13 execute immediate 'drop outline ' || outline_name; 14 end; 15 / PL/SQL procedure successfully completed. SQL> SQL> -- This is the plan SQL> -- we get based on the present statistics SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 2125410158 ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | |* 2 | TABLE ACCESS FULL| T_FETCH_FIRST_ROWS | 1000 | 11000 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("TYPE"='VIEW') 14 rows selected. SQL> SQL> spool off

So that worked, but still the question remains why DBMS_OUTLN.CREATE_OUTLINE doesn't use the available outline information in the shared pool.

Now let's turn to a different approach to achieve the same. 10g introduced SQL profiles that are primarily used to amend information that is not available to the cost based optimizer, e.g. in case of correlated column values the SQL Tuning Advisor of 10g can suggest to accept a SQL profile that scales the cardinality estimate so that the cardinality estimate is in the right ballpark.

A good explanation of SQL profiles can be found in Christian Antognini's publications.

But since SQL profiles internally consist of a set of hints, it could be possible to use SQL profiles instead of Stored Outlines to achieve the same.

There are two interesting aspects regarding this approach:

- We could use different sources to get the outline, e.g. instead of the shared pool we could get the hints from the AWR tables.

- SQL profiles support a "FORCE_MATCH" option that works similar to the CURSOR_SHARING literal replacement logic, i.e. SQL profiles can be forced to apply to multiple SQL statements that differ only by the literals used (i.e. no usage of bind variables).

So we are faced with two challenges in this regard:

1. Get the outline information, i.e. the full set of hints to provide plan stability 2. Create a SQL profile that consists of these hints

Get the outline information

There are two ways how the outline information could be obtained:

a) Use the DBMS_XPLAN.DISPLAY* functions with the ADVANCED or OUTLINE option and parse the this output to get the set of hints

b) Directly query the underlying tables/views to get the XML stored in the OTHER_XML column and extract the hints from that XML

a) Use the DBMS_XPLAN.DISPLAY* functions

Let me digress a little bit. Looking at the (already parsed a bit) output we get from the official DBMS_XPLAN function:

SQL> SQL> with a as ( 2 select 3 rownum as r_no 4 , a.* 5 from 6 table( 7 dbms_xplan.display_cursor( 8 'c2trqja6wh561' 9 , 0 10 , 'OUTLINE' 11 ) 12 ) a 13 ), 14 b as ( 15 select 16 min(r_no) as start_r_no 17 from 18 a 19 where 20 a.plan_table_output = 'Outline Data' 21 ), 22 c as ( 23 select 24 min(r_no) as end_r_no 25 from 26 a 27 , b 28 where 29 a.r_no > b.start_r_no 30 and a.plan_table_output = ' */' 31 ), 32 d as ( 33 select 34 instr(a.plan_table_output, 'BEGIN_OUTLINE_DATA') as start_col 35 from 36 a 37 , b 38 where 39 r_no = b.start_r_no + 4 40 ) 41 select 42 substr(a.plan_table_output, d.start_col) as outline_hints 43 from 44 a 45 , b 46 , c 47 , d 48 where 49 a.r_no >= b.start_r_no + 4 50 and a.r_no <= c.end_r_no - 1 51 order by 52 a.r_no; OUTLINE_HINTS -------------------------------------------------------------------------- BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRST_ROWS"."ID")) END_OUTLINE_DATA 14 rows selected. SQL>

You'll notice that the INDEX_RS_ASC hint is split across two lines, so we can't simply use that query output to construct the hints because these hints would be potentially illegal and therefore we need to merge/concatenate these split lines.

This is a variation of the well known "columns-to-rows" aka. STRAGG/CONCAT issue and there are multiple ways how to deal with that using plain SQL.

For more information about this particular issue, see e.g. the SQL snippets site.

Here are two ways how to achieve that concatenation using hierarchical queries or the SQL MODEL clause introduced in 10g:

SQL> SQL> with a as ( 2 select 3 rownum as r_no 4 , a.* 5 from 6 table( 7 dbms_xplan.display_cursor( 8 'c2trqja6wh561' 9 , 0 10 , 'OUTLINE' 11 ) 12 ) a 13 ), 14 b as ( 15 select 16 min(r_no) as start_r_no 17 from 18 a 19 where 20 a.plan_table_output = 'Outline Data' 21 ), 22 c as ( 23 select 24 min(r_no) as end_r_no 25 from 26 a 27 , b 28 where 29 a.r_no > b.start_r_no 30 and a.plan_table_output = ' */' 31 ), 32 d as ( 33 select 34 instr(a.plan_table_output, 'BEGIN_OUTLINE_DATA') as start_col 35 from 36 a 37 , b 38 where 39 r_no = b.start_r_no + 4 40 ), 41 e as ( 42 select a.r_no 43 , substr(a.plan_table_output, d.start_col) as outline_hints 44 from 45 a 46 , b 47 , c 48 , d 49 where 50 a.r_no >= b.start_r_no + 4 51 and a.r_no <= c.end_r_no - 1 52 order by 53 a.r_no 54 ), 55 f as ( 56 select 57 case substr(e.outline_hints, 1, 1) 58 when ' ' 59 then r_no - 1 60 else null 61 end as par_id, 62 e.* 63 from 64 e 65 ) 66 select 67 replace(aggr,'|', '') as aggr 68 from ( 69 select 70 par_id 71 , sys_connect_by_path(trim(outline_hints), '|') as aggr 72 , level as lvl 73 from 74 f 75 where 76 connect_by_isleaf = 1 77 start with 78 par_id is null 79 connect by 80 prior r_no = par_id 81 order siblings by 82 r_no 83 ); AGGR ------------------------------------------------------------------------------------------------------------- BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2"("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRST_ROWS"."ID")) END_OUTLINE_DATA 13 rows selected. SQL>

And here using the MODEL clause:

SQL> SQL> with a as ( 2 select 3 rownum as r_no 4 , a.* 5 from 6 table( 7 dbms_xplan.display_cursor( 8 'c2trqja6wh561' 9 , 0 10 , 'OUTLINE' 11 ) 12 ) a 13 ), 14 b as ( 15 select 16 min(r_no) as start_r_no 17 from 18 a 19 where 20 a.plan_table_output = 'Outline Data' 21 ), 22 c as ( 23 select 24 min(r_no) as end_r_no 25 from 26 a 27 , b 28 where 29 a.r_no > b.start_r_no 30 and a.plan_table_output = ' */' 31 ), 32 d as ( 33 select 34 instr(a.plan_table_output, 'BEGIN_OUTLINE_DATA') as start_col 35 from 36 a 37 , b 38 where 39 r_no = b.start_r_no + 4 40 ), 41 e as ( 42 select 43 a.r_no 44 , substr(a.plan_table_output, d.start_col) as outline_hints 45 from 46 a 47 , b 48 , c 49 , d 50 where 51 a.r_no >= b.start_r_no + 4 52 and a.r_no <= c.end_r_no - 1 53 ), 54 f as ( 55 select 56 case substr(e.outline_hints, 1, 1) 57 when ' ' 58 then null 59 else r_no 60 end as grp_id 61 , e.* 62 from 63 e 64 ), 65 g as ( 66 select 67 case 68 when grp_id is null 69 then last_value(grp_id ignore nulls) over (order by r_no) 70 else null 71 end as par_id 72 , f.* 73 from 74 f 75 ) 76 select 77 aggr 78 from 79 g 80 model 81 return updated rows 82 partition by ( 83 nvl(grp_id, par_id) as grp 84 ) 85 dimension by ( 86 row_number() over ( 87 partition by 88 nvl(grp_id, par_id) 89 order by 90 r_no 91 ) as rn 92 ) 93 measures ( 94 cast(outline_hints as varchar2(4000)) as aggr 95 , r_no 96 ) 97 rules 98 iterate (1000) 99 until presentv(aggr[ITERATION_NUMBER+3],1,2)=2 ( 100 aggr[1] = aggr[1] || 101 trim(aggr[ITERATION_NUMBER+2]) 102 ) 103 order by r_no 104 ; AGGR ---------------------------------------------------------------------------------------------------------------------------------- BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRST_ROWS"."ID")) END_OUTLINE_DATA 13 rows selected. SQL>

b) Directly query the underlying tables/views to get the XML

The other option would be to query the respective tables/views directly to obtain the hints from the XML stored in the OTHER_XML column of execution plans.

Here we can use the powerful XML functions of Oracle 10g:

SQL> SQL> select 2 extractvalue(value(d), '/hint') as outline_hints 3 from 4 xmltable('/*/outline_data/hint' 5 passing ( 6 select 7 xmltype(other_xml) as xmlval 8 from 9 v$sql_plan 10 where 11 sql_id = 'c2trqja6wh561' 12 and child_number = 0 13 and other_xml is not null 14 ) 15 ) d; OUTLINE_HINTS ------------------------------------------------------------------------------------------------------------- IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRST_ROWS"."ID")) 11 rows selected. SQL>

Instead of V$SQL_PLAN/V$SQL we could e.g. use DBA_HIST_SQL_PLAN/DBA_HIST_SQLTEXT to obtain the outline information from the AWR.

Create a SQL profile that consists of these hints

Now the second challenge is how to generate a SQL profile once we have identified the hints to use.

Here comes the DBMS_SQLTUNE package into the picture. It offers an (not officially documented) procedure IMPORT_SQL_PROFILE that is obviously used by the import facilities to create SQL profiles.

-- NAME: import_sql_profile - import a SQL profile -- PURPOSE: This procedure is only used by import. -- INPUTS: (see accept_sql_profile) -- REQUIRES: "CREATE ANY SQL PROFILE" privilege -- PROCEDURE import_sql_profile( sql_text IN CLOB, profile IN sqlprof_attr, name IN VARCHAR2 := NULL, description IN VARCHAR2 := NULL, category IN VARCHAR2 := NULL, validate IN BOOLEAN := TRUE, replace IN BOOLEAN := FALSE, force_match IN BOOLEAN := FALSE);

It simply takes a collection of varchar2(500) strings that make up the profile.

So we can combine the two things into a procedure that generates us a SQL profile from either the shared pool or the AWR. Here's one for the shared pool. It takes four parameters: The SQL_ID, the child_number, the SQL profile category and whether to force a match or not.

declare ar_profile_hints sys.sqlprof_attr; cl_sql_text clob; begin select extractvalue(value(d), '/hint') as outline_hints bulk collect into ar_profile_hints from xmltable('/*/outline_data/hint' passing ( select xmltype(other_xml) as xmlval from v$sql_plan where sql_id = '&&1' and child_number = &&2 and other_xml is not null ) ) d; select sql_fulltext into cl_sql_text from v$sql where sql_id = '&&1' and child_number = &&2; dbms_sqltune.import_sql_profile( sql_text => cl_sql_text , profile => ar_profile_hints , category => '&&3' , name => 'PROFILE_&&1' -- use force_match => true -- to use CURSOR_SHARING=SIMILAR -- behaviour, i.e. match even with -- differing literals , force_match => &&4 ); end; /

Here's the one for the AWR. It takes as parameter the SQL_ID, the PLAN_HASH_VALUE and like the first one the SQL profile category and the FORCE_MATCH option.

declare ar_profile_hints sys.sqlprof_attr; cl_sql_text clob; begin select extractvalue(value(d), '/hint') as outline_hints bulk collect into ar_profile_hints from xmltable('/*/outline_data/hint' passing ( select xmltype(other_xml) as xmlval from dba_hist_sql_plan where sql_id = '&&1' and plan_hash_value = &&2 and other_xml is not null ) ) d; select sql_text into cl_sql_text from dba_hist_sqltext where sql_id = '&&1'; dbms_sqltune.import_sql_profile( sql_text => cl_sql_text , profile => ar_profile_hints , category => '&&3' , name => 'PROFILE_&&1' -- use force_match => true -- to use CURSOR_SHARING=SIMILAR -- behaviour, i.e. match even with -- differing literals , force_match => &&4 ); end; /

So let's try all the stuff in one shot:

SQL> SQL> drop table t_fetch_first_rows purge; Table dropped. SQL> SQL> create table t_fetch_first_rows ( 2 id number not null, 3 name varchar2(30) not null, 4 type varchar2(30) not null, 5 measure number 6 ); Table created. SQL> SQL> create index idx_fetch_first_rows on t_fetch_first_rows (type, id); Index created. SQL> SQL> -- create an empty table SQL> -- and gather statistics on it SQL> exec dbms_stats.gather_table_stats(null, 't_fetch_first_rows', no_invalidate=>true) PL/SQL procedure successfully completed. SQL> SQL> -- now put in some data SQL> insert /*+ append */ into t_fetch_first_rows ( 2 id, 3 name, 4 type, 5 measure) 6 select object_id, object_name, object_type, object_id as measure 7 from all_objects, (select level as id from dual connect by level <= 1000) dup 8 where object_type in ('VIEW', 'SCHEDULE') 9 and rownum <= 1000; 1000 rows created. SQL> SQL> commit; Commit complete. SQL> SQL> -- This is going to use SQL> -- the wrong plan SQL> -- that we - only for demonstration purposes - SQL> -- attempt to keep now SQL> select sum(measure), count(*) from ( 2 select * from t_fetch_first_rows 3 where type = 'VIEW' 4 order by id 5 ); SUM(MEASURE) COUNT(*) ------------ ---------- 900000 1000 SQL> SQL> -- uses index SQL> select * from table(dbms_xplan.display_cursor(null, null, 'OUTLINE')); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- SQL_ID c2trqja6wh561, child number 0 ------------------------------------- select sum(measure), count(*) from ( select * from t_fetch_first_rows where type = 'VIEW' order by id ) Plan hash value: 1903859112 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 1 (100)| | 1 | SORT AGGREGATE | | 1 | 43 | | | 2 | TABLE ACCESS BY INDEX ROWID| T_FETCH_FIRST_ROWS | 1 | 43 | 0 (0)| |* 3 | INDEX RANGE SCAN | IDX_FETCH_FIRST_ROWS | 1 | | 0 (0)| ------------------------------------------------------------------------------------------ Outline Data ------------- /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRST_ROWS"."ID")) END_OUTLINE_DATA */ Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("TYPE"='VIEW') 41 rows selected. SQL> SQL> -- now gather statistics again SQL> -- on table with data SQL> exec dbms_stats.gather_table_stats(null, 't_fetch_first_rows', no_invalidate=>true) PL/SQL procedure successfully completed. SQL> SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> -- now the EXPLAIN PLAN tells us SQL> -- full table scan SQL> select * from table(dbms_xplan.display(null, null, 'OUTLINE')); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 2125410158 ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | |* 2 | TABLE ACCESS FULL| T_FETCH_FIRST_ROWS | 1000 | 11000 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------- Outline Data ------------- /*+ BEGIN_OUTLINE_DATA FULL(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2") OUTLINE(@"SEL$2") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$73523A42") OUTLINE(@"SEL$1") MERGE(@"SEL$73523A42") OUTLINE_LEAF(@"SEL$51F12574") ALL_ROWS OPT_PARAM('query_rewrite_enabled' 'false') OPTIMIZER_FEATURES_ENABLE('10.2.0.4') IGNORE_OPTIM_EMBEDDED_HINTS END_OUTLINE_DATA */ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("TYPE"='VIEW') 33 rows selected. SQL> SQL> -- These are the hints SQL> -- stored in the child cursor SQL> -- in the shared pool SQL> -- It clearly shows an index access SQL> select 2 substr(extractvalue(value(d), '/hint'), 1, 100) as outline_hints 3 from 4 xmltable('/*/outline_data/hint' 5 passing ( 6 select 7 xmltype(other_xml) as xmlval 8 from 9 v$sql_plan 10 where 11 sql_id = 'c2trqja6wh561' 12 and child_number = 0 13 and other_xml is not null 14 ) 15 ) d; OUTLINE_HINTS ---------------------------------------------------------------------------------------------------- IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.4') OPT_PARAM('query_rewrite_enabled' 'false') ALL_ROWS OUTLINE_LEAF(@"SEL$51F12574") MERGE(@"SEL$73523A42") OUTLINE(@"SEL$1") OUTLINE(@"SEL$73523A42") ELIMINATE_OBY(@"SEL$2") OUTLINE(@"SEL$2") INDEX_RS_ASC(@"SEL$51F12574" "T_FETCH_FIRST_ROWS"@"SEL$2" ("T_FETCH_FIRST_ROWS"."TYPE" "T_FETCH_FIRS 11 rows selected. SQL> SQL> -- Create the SQL profile based on that cursor SQL> @create_profile_from_shared_pool c2trqja6wh561 0 TEST true SQL> declare 2 ar_profile_hints sys.sqlprof_attr; 3 cl_sql_text clob; 4 begin 5 select 6 extractvalue(value(d), '/hint') as outline_hints 7 bulk collect 8 into 9 ar_profile_hints 10 from 11 xmltable('/*/outline_data/hint' 12 passing ( 13 select 14 xmltype(other_xml) as xmlval 15 from 16 v$sql_plan 17 where 18 sql_id = '&&1' 19 and child_number = &&2 20 and other_xml is not null 21 ) 22 ) d; 23 24 select 25 sql_text 26 into 27 cl_sql_text 28 from 29 -- replace with dba_hist_sqltext 30 -- if required for AWR based 31 -- execution 32 v$sql 33 -- sys.dba_hist_sqltext 34 where 35 sql_id = '&&1' 36 and child_number = &&2; 37 -- plan_hash_value = &&2; 38 39 dbms_sqltune.import_sql_profile( 40 sql_text => cl_sql_text 41 , profile => ar_profile_hints 42 , category => '&&3' 43 , name => 'PROFILE_&&1' 44 -- use force_match => true 45 -- to use CURSOR_SHARING=SIMILAR 46 -- behaviour, i.e. match even with 47 -- differing literals 48 , force_match => &&4 49 ); 50 end; 51 / old 18: sql_id = '&&1' new 18: sql_id = 'c2trqja6wh561' old 19: and child_number = &&2 new 19: and child_number = 0 old 35: sql_id = '&&1' new 35: sql_id = 'c2trqja6wh561' old 36: and child_number = &&2; new 36: and child_number = 0; old 37: -- plan_hash_value = &&2; new 37: -- plan_hash_value = 0; old 42: , category => '&&3' new 42: , category => 'TEST' old 43: , name => 'PROFILE_&&1' new 43: , name => 'PROFILE_c2trqja6wh561' old 48: , force_match => &&4 new 48: , force_match => true PL/SQL procedure successfully completed. SQL> SQL> alter session set sqltune_category = 'TEST'; Session altered. SQL> SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> -- Uses SQL profile (see Note section) SQL> -- and uses index SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 1903859112 ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 9 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | | 2 | TABLE ACCESS BY INDEX ROWID| T_FETCH_FIRST_ROWS | 1000 | 11000 | 9 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN | IDX_FETCH_FIRST_ROWS | 1000 | | 4 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("TYPE"='VIEW') Note ----- - SQL profile "PROFILE_c2trqja6wh561" used for this statement 19 rows selected. SQL> SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW2' 6 order by id 7 ); Explained. SQL> SQL> -- Very cool: Still uses SQL profile (see Note section) SQL> -- although no exact text match SQL> -- this is not possible using Stored Outlines SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 1903859112 ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | | 2 | TABLE ACCESS BY INDEX ROWID| T_FETCH_FIRST_ROWS | 1 | 11 | 3 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN | IDX_FETCH_FIRST_ROWS | 1 | | 2 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("TYPE"='VIEW2') Note ----- - SQL profile "PROFILE_c2trqja6wh561" used for this statement 19 rows selected. SQL> SQL> alter session set sqltune_category = 'DEFAULT'; Session altered. SQL> SQL> -- drop the SQL profile SQL> exec dbms_sqltune.drop_sql_profile('PROFILE_c2trqja6wh561') PL/SQL procedure successfully completed. SQL> SQL> -- This is the plan SQL> -- we get based on the present statistics SQL> explain plan 2 for 3 select sum(measure), count(*) from ( 4 select * from t_fetch_first_rows 5 where type = 'VIEW' 6 order by id 7 ); Explained. SQL> SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 2125410158 ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 11 | | | |* 2 | TABLE ACCESS FULL| T_FETCH_FIRST_ROWS | 1000 | 11000 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("TYPE"='VIEW') 14 rows selected. SQL>

You can see two things here:

1. The SQL profile created forces the plan we wanted, so it seems to work as expected
2. The FORCE_MATCH option of the SQL profiles allows to use this profile even for SQLs that are not an exact text match of the original statement. This is something that is as far as I know not possible using Stored Outlines.

So if you have the need to fix the execution plan, and you have that plan already in the shared pool or the AWR, using above procedures allow you to generate a SQL profile which seems to do exactly what we want.

Given the fact that the SQL profile even allows to share the plan for SQLs that differ only by literals I definitely favor the SQL profiles over the Stored Outlines approach.