A stored outline is a collection of hints associated with a specific SQL statement that allows a standard execution plan to be maintained, regardless of changes in the system environment or associated statistics. Plan stability is based on the preservation of execution plans at a point in time where the performance of a statement is considered acceptable. The outlines are stored in the OL$, OL$HINTS, and OL$NODES tables, but the [USER|ALL|DBA]_OUTLINES and [USER|ALL|DBA]_OUTLINE_HINTS views should be used to display information about existing outlines.
All of the caveats associated with optimizer hints apply equally to stored outlines. Under normal running the optimizer chooses the most suitable execution plan for the current circumstances. By using a stored outline you may be forcing the optimizer to choose a substandard execution plan, so you should monitor the affects of your stored outlines over time to make sure this isn’t happening. Remember, what works well today may not tomorrow.
Many times we are into the situation when the performance of a query regressing, or the optimizer is not able to choose the better execution plan.
In the next lines I will try to describe a scenario that needs the usage of a stored outline:
–we will identify the different plans that exists for our sql_id
SQL> select hash_value,child_number,sql_id,executions from v$sql where sql_id='574gkc8gn7u0h'; HASH_VALUE CHILD_NUMBER SQL_ID EXECUTIONS ---------- ------------ ------------- ---------- 524544016 0 574gkc8gn7u0h 4 576321033 1 574gkc8gn7u0h 5
Between the two different plans, we know that the best one is that with the cost 15 and the hash_value : 4013416232, but which is not all the time choosed by the optimizer, causing peak of performance
SQL> select * from table(dbms_xplan.display_cursor(‘574gkc8gn7u0h’,0));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID 574gkc8gn7u0h, child number 0
-------------------------------------
Select m.msg_message_id, m.VersionId, m.Knoten_id,
m.Poly_User_Id, m.State, 'U' as MutationsCode from
........................................................
Plan hash value: 4013416232
-------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 15 (100)| |
| 1 | UNION-ALL | | | | | |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1 | 76 | 7 (15)| 00:00:01 |
| 5 | MERGE JOIN CARTESIAN | | 1 | 52 | 5 (20)| 00:00:01 |
| 6 | SORT UNIQUE | | 1 | 26 | 2 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | TMPINTLIST | 1 | 26 | 2 (0)| 00:00:01 |
| 8 | BUFFER SORT | | 1 | 26 | 3 (34)| 00:00:01 |
| 9 | SORT UNIQUE | | 1 | 26 | 2 (0)| 00:00:01 |
|* 10 | TABLE ACCESS FULL | TMPINTLIST | 1 | 26 | 2 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | XAK2_MSG_MESSAGE_ENTRY | 1 | | 1 (0)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID| MSG_MESSAGE_ENTRY | 1 | 24 | 2 (0)| 00:00:01 |
|* 13 | FILTER | | | | | |
| 14 | NESTED LOOPS | | | | | |
| 15 | NESTED LOOPS | | 1 | 76 | 8 (13)| 00:00:01 |
| 16 | MERGE JOIN CARTESIAN | | 1 | 52 | 5 (20)| 00:00:01 |
| 17 | SORT UNIQUE | | 1 | 26 | 2 (0)| 00:00:01 |
|* 18 | TABLE ACCESS FULL | TMPINTLIST | 1 | 26 | 2 (0)| 00:00:01 |
| 19 | BUFFER SORT | | 1 | 26 | 3 (34)| 00:00:01 |
| 20 | SORT UNIQUE | | 1 | 26 | 2 (0)| 00:00:01 |
|* 21 | TABLE ACCESS FULL | TMPINTLIST | 1 | 26 | 2 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | XAK3_MSG_MESSAGE_ENTRY_DEL | 1 | | 2 (0)| 00:00:01 |
| 23 | TABLE ACCESS BY INDEX ROWID| MSG_MESSAGE_ENTRY_DEL | 1 | 24 | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(:LASTTREATEDVERSIONID<=:MAXVERSIONID)
7 - filter("SERIAL#"=1999999999)
10 - filter("SERIAL#"=1999999998)
----------------------------------------------
In order to fix this , we will create and enable an outline, that should help the optimizer to choose always the best plan:
BEGIN
DBMS_OUTLN.create_outline(hash_value =>524544016,child_number => 0);
END;
/
PL/SQL procedure successfully completed.
SQL>
SQL> alter system set use_stored_outlines=TRUE;
System altered.
SQL> create or replace trigger trig_start_out after startup on database
2 begin
3 execute immediate 'alter system set use_stored_outlines=TRUE';
4 end;
5 /
Trigger created.
As the parameter “use_stored_outlines” is a ‘pseudo’ parameter, is not persistent over the reboot of the system, for that reason we had to create this trigger on startup database.
Now we can check , if the outline is used:
NAME OWNER CATEGORY USED ------------------------------ ------------------------------ ------------------------------ ------ SYS_OUTLINE_18092409295665701 TEST DEFAULT USED And also, to check that the execution is taking in account
SQL> select * from table(dbms_xplan.display_cursor('574gkc8gn7u0h',0));
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID 574gkc8gn7u0h, child number 0
-------------------------------------
Select m.msg_message_id, m.VersionId, m.Knoten_id,
m.Poly_User_Id, m.State, 'U' as MutationsCode from
msg_message_entry m where m.VersionId between :LastTreatedVersionId
...................
Plan hash value: 4013416232
-------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 15 (100)| |
| 1 | UNION-ALL | | | | | |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1 | 76 | 7 (15)| 00:00:01 |
| 5 | MERGE JOIN CARTESIAN | | 1 | 52 | 5 (20)| 00:00:01 |
| 6 | SORT UNIQUE | | 1 | 26 | 2 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | TMPINTLIST | 1 | 26 | 2 (0)| 00:00:01 |
| 8 | BUFFER SORT | | 1 | 26 | 3 (34)| 00:00:01 |
| 9 | SORT UNIQUE | | 1 | 26 | 2 (0)| 00:00:01 |
|* 10 | TABLE ACCESS FULL | TMPINTLIST | 1 | 26 | 2 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | XAK2_MSG_MESSAGE_ENTRY | 1 | | 1 (0)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID| MSG_MESSAGE_ENTRY | 1 | 24 | 2 (0)| 00:00:01 |
|* 13 | FILTER | | | | | |
| 14 | NESTED LOOPS | | | | | |
| 15 | NESTED LOOPS | | 1 | 76 | 8 (13)| 00:00:01 |
| 16 | MERGE JOIN CARTESIAN | | 1 | 52 | 5 (20)| 00:00:01 |
| 17 | SORT UNIQUE | | 1 | 26 | 2 (0)| 00:00:01 |
|* 18 | TABLE ACCESS FULL | TMPINTLIST | 1 | 26 | 2 (0)| 00:00:01 |
| 19 | BUFFER SORT | | 1 | 26 | 3 (34)| 00:00:01 |
| 20 | SORT UNIQUE | | 1 | 26 | 2 (0)| 00:00:01 |
|* 21 | TABLE ACCESS FULL | TMPINTLIST | 1 | 26 | 2 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | XAK3_MSG_MESSAGE_ENTRY_DEL | 1 | | 2 (0)| 00:00:01 |
| 23 | TABLE ACCESS BY INDEX ROWID| MSG_MESSAGE_ENTRY_DEL | 1 | 24 | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(:LASTTREATEDVERSIONID<=:MAXVERSIONID)
7 - filter("SERIAL#"=1999999999)
10 - filter("SERIAL#"=1999999998)
Note
-----
- outline "SYS_OUTLINE_18092409295665701" used for this statement
To use stored outlines when Oracle compiles a SQL statement we need to enable them by setting the system parameter USE_STORED_OUTLINES to TRUE or to a category name. This parameter can be also be set at the session level.
By setting this parameter to TRUE, the category by default on which the outlines are created is DEFAULT.
If you prefer to add a category on the procedure of outline creation, Oracle will used this outline category until you provide another category value or you disable the usage of the outlines by putting the parameter USE_STORED_OUTLINE to FALSE.
Cet article SQL Plan stability in 11G using stored outlines est apparu en premier sur Blog dbi services.