Nigel Bayliss has posted a note about a frequently requested feature that has now appeared in Oracle 19c – a mechanism to help people understand what has happened to their hints. It’s very easy to use, it’s just another format option to the “display_xxx()” calls in dbms_xplan; so I thought I’d run up a little demonstration (using an example I first generated 18 years and 11 versions ago) to make three points: first, to show the sort of report you get, second to show you that the report may tell you what has happened, but that doesn’t necessarily tell you why it has happened, and third to remind you that you should have stopped using the /*+ ordered */ hint 18 years ago.
I’ve run the following code on livesql:
rem
rem Script: c_ignorehint.sql
rem Author: Jonathan Lewis
rem Dated: March 2001
rem
drop table ignore_1;
drop table ignore_2;
create table ignore_1
nologging
as
select
rownum id,
rownum val,
rpad('x',500) padding
from all_objects
where rownum <= 3000
;
create table ignore_2
nologging
as
select
rownum id,
rownum val,
rpad('x',500) padding
from all_objects
where rownum <= 500
;
alter table ignore_2
add constraint ig2_pk primary key (id);
explain plan for
update
(
select
/*+
ordered
use_nl(i2)
index(i2,ig2_pk)
*/
i1.val val1,
i2.val val2
from
ignore_1 i1,
ignore_2 i2
where
i2.id = i1.id
and i1.val <= 10
)
set val1 = val2
;
select * from table(dbms_xplan.display(null,null,'hint_report'));
explain plan for
update
(
select
/*+
use_nl(i2)
index(i2,ig2_pk)
*/
i1.val val1,
i2.val val2
from
ignore_1 i1,
ignore_2 i2
where
i2.id = i1.id
and i1.val <= 10
)
set val1 = val2
;
select * from table(dbms_xplan.display(null,null,'hint_report'));
As you can see I’ve simply added the format option “hint_report” to the call to dbms_xplan.display(). Before showing you the output I’ll just say a few words about the plans we might expect from the two versions of the update statement.
Given the /*+ ordered */ hint in the first statement we might expect Oracle to do a full tablescan of ignore_1 then do a nested loop into ignore_2 (obeying the use_nl() hint) using the (hinted) ig2_pk index. In the second version of the statement, and in the absence of the ordered hint, it’s possible that the optimizer will still use the same path but, in principle, it might find some other path.
So what do we get ? In order here are the two execution plans:
Plan hash value: 3679612214
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | 10 | 160 | 111 (0)| 00:00:01 |
| 1 | UPDATE | IGNORE_1 | | | | |
|* 2 | HASH JOIN | | 10 | 160 | 111 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID BATCHED| IGNORE_2 | 500 | 4000 | 37 (0)| 00:00:01 |
| 4 | INDEX FULL SCAN | IG2_PK | 500 | | 1 (0)| 00:00:01 |
|* 5 | TABLE ACCESS STORAGE FULL | IGNORE_1 | 10 | 80 | 74 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("I2"."ID"="I1"."ID")
5 - storage("I1"."VAL"<=10)
filter("I1"."VAL"<=10)
Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: 3 (U - Unused (1))
---------------------------------------------------------------------------
1 - SEL$DA9F4B51
- ordered
3 - SEL$DA9F4B51 / I2@SEL$1
U - use_nl(i2)
- index(i2,ig2_pk)
Plan hash value: 1232653668
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | 10 | 160 | 76 (0)| 00:00:01 |
| 1 | UPDATE | IGNORE_1 | | | | |
| 2 | NESTED LOOPS | | 10 | 160 | 76 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 10 | 160 | 76 (0)| 00:00:01 |
|* 4 | TABLE ACCESS STORAGE FULL | IGNORE_1 | 10 | 80 | 74 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | IG2_PK | 1 | | 0 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| IGNORE_2 | 1 | 8 | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - storage("I1"."VAL"<=10)
filter("I1"."VAL"<=10)
5 - access("I2"."ID"="I1"."ID")
Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: 2
---------------------------------------------------------------------------
5 - SEL$DA9F4B51 / I2@SEL$1
- index(i2,ig2_pk)
- use_nl(i2)
As you can see, the “Hint Report” shows us how many hints have been seen in the SQL text, then the body of the report shows us which query block, operation and table (where relevant) each hint has been associated with, and whether it has been used or not.
The second query has followed exactly the plan I predicted for the first query and the report has shown us that Oracle noted, and used, the use_nl() and index() hints to access table ignore2, deciding for itself to visit the tables in the order ignore_1 -> ignore_2, and doing a full tablescan on ignore_1.
The first query reports three hints, but flags the use_nl() hint as unused. (There is (at least) one other flag that could appear against a hint – “E” for error (probably syntax error), so we can assume that this hint is not being ignored because there’s something wrong with it.) Strangely the report tells us that the optimizer has used the ordered hint but we can see from the plan that the tables appear to be in the opposite order to the order we specified in the from clause, and the chosen order has forced the optimizer into using an index full scan on ig2_pk because it had to obey our index() hint. Bottom line – the optimizer has managed to find a more costly plan by “using but apparently ignoring” a hint that described the cheaper plan that we would have got if we hadn’t used the hint.
Explanation
Query transformation can really mess things up and you shouldn’t be using the ordered hint.
I’ve explained many times over the years that the optimizer evaluates the cost of an update statement by calculating the cost of selecting the rowids of the rows to be updated. In this case, which uses an updatable join view, the steps taken to follow this mechanism this are slightly more complex. Here are two small but critical extracts from the 10053 trace file (taken from an 18c instance):
CVM: Merging SPJ view SEL$1 (#0) into UPD$1 (#0)
Registered qb: SEL$DA9F4B51 0x9c9966e8 (VIEW MERGE UPD$1; SEL$1; UPD$1)
...
SQE: Trying SQ elimination.
Query after View Removal
******* UNPARSED QUERY IS *******
SELECT
/*+ ORDERED INDEX ("I2" "IG2_PK") USE_NL ("I2") */
0
FROM "TEST_USER"."IGNORE_2" "I2",
"TEST_USER"."IGNORE_1" "I1"
WHERE "I2"."ID"="I1"."ID"
AND "I1"."VAL"<=10
The optimizer has merged the UPDATE query block with the SELECT query block to produce a select statement that will produce the necessary plan (I had thought that i1.rowid would appear in the select list, but the ‘0’ will do for costing purposes). Notice that the hints have been preserved as the update and select were merged but, unfortunately, the merge mechanism has reversed the order of the tables in the from clause. So the optimizer has messed up our select statement, then obeyed the original ordered hint!
Bottom line – the hint report is likely to be very helpful in most cases but you will still have to think about what it is telling you, and you may still have to look at the occasional 10053 to understand why the report is showing you puzzling results. You should also stop using a hint that was replaced by a far superior hint more than 18 years ago – the ordered hint in my example should have been changed to /*+ leading(i1 i2) */ in Oracle 9i.