In response to a recent lamentation from Richard Foote about the degree of ignorance regarding the clustering_factor of indexes I commented on the similar level of understanding of a specific hint syntax, namely use_nl(a b) pointing out that this does not mean “do a nested loop from a to b”. My comment was underscored by a fairly prompt response asking what the hint did mean.
Surprisingly, although I’ve explained it many times over the last couple of decades (here’s one from 10 years ago), I couldn’t find an explanation on my blog though I did find a blog note where I’d made a passing comment about the equivalent misunderstanding of the use_hash(a b) syntax.
The misunderstanding is not entirely surprising since for many years the Oracle manuals seemed to suggest (in their examples) that the hint did have a multi-table meaning and it wasn’t until 10g that the manual gave an explicit statement of the single-table nature of the hint. The hint /*+ use_nl(a b) */ is a short-hand for the pair of hints /*+ use_nl(a) use_nl(b) */ it doesn’t say anything about whether a and b should be joined, or in what order. If you want to guarantee that a and b will be joined in that order by a nested loop you will have to work a lot harder with your hints – and almost certainly need to make use of the /+ leading() */ hint.
Consider the following query (I’ll put the table creation code at the end of the article if you want to experiment):
select /*+ use_nl(a b) */ a.v1, b.v1, c.v1, d.v1 from a, b, c, d where d.n100 = 0 and a.n100 = d.id and b.n100= a.n2 and c.id = a.id ;
Only one of the tables a and b can be the first table in the final execution plan so one of them will be “the next table in the join order” at some point, so this hint will guarantee that one of the tables will be the inner table of a nested loop join. Here’s the plan I happened to get with my data, indexing, version (11.2.0.4), etc.:
--------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 1347K| 30125 (1)| 00:00:02 | | 1 | HASH JOIN | | 20000 | 1347K| 30125 (1)| 00:00:02 | | 2 | TABLE ACCESS FULL | C | 10000 | 146K| 26 (4)| 00:00:01 | | 3 | HASH JOIN | | 20000 | 1054K| 30098 (1)| 00:00:02 | | 4 | TABLE ACCESS FULL | D | 100 | 1800 | 26 (4)| 00:00:01 | | 5 | NESTED LOOPS | | 20000 | 703K| 30072 (1)| 00:00:02 | | 6 | NESTED LOOPS | | 20000 | 703K| 30072 (1)| 00:00:02 | | 7 | TABLE ACCESS FULL | B | 10000 | 136K| 26 (4)| 00:00:01 | | 8 | INDEX RANGE SCAN | A_I2 | 2 | | 1 (0)| 00:00:01 | | 9 | TABLE ACCESS BY INDEX ROWID| A | 2 | 44 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------------
In this case it’s table a that ends up in a position to be the inner table of a nested loop join.
You may be wondering why there seems to be a hash join into b when we’ve hinted a nested loop join – but the join order that Oracle is using is B -> A -> D -> C with a swap_join_inputs(d) swap_join_inputs(d), so b is never “the next table in the join order”.
If you want an even more confusing (at first sight) plan here’s the plan I got if I changed the one hint to /*+ use_nl(a) */
----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 1347K| 105 (5)| 00:00:01 | | 1 | HASH JOIN | | 20000 | 1347K| 105 (5)| 00:00:01 | | 2 | TABLE ACCESS FULL | B | 10000 | 136K| 26 (4)| 00:00:01 | | 3 | HASH JOIN | | 10000 | 537K| 78 (4)| 00:00:01 | | 4 | TABLE ACCESS FULL | C | 10000 | 146K| 26 (4)| 00:00:01 | | 5 | HASH JOIN | | 10000 | 390K| 52 (4)| 00:00:01 | | 6 | TABLE ACCESS FULL| D | 100 | 1800 | 26 (4)| 00:00:01 | | 7 | TABLE ACCESS FULL| A | 10000 | 214K| 26 (4)| 00:00:01 | -----------------------------------------------------------------------------
This plan really looks as if Oracle should have done a nested loop into a but didn’t. Again appearanced are deceptive thanks to the effects of swap_join_inputs(): the join order here is A -> D -> C -> B (note that we don’t have a use_nl(b) hint in this example).
If you want a plan where the optimizer produces a nested loop join between a and b you’ll need to put in a leading() hint which places b immediately after a somewhere in the list of tables with just use_nl(b) being sufficient to enforce the join method. Here, for example, is the plan with hints /*+ leading(d a b c) use_nl(b) */ for my data set:
---------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 1347K| 30164 (1)| 00:00:02 | | 1 | HASH JOIN | | 20000 | 1347K| 30164 (1)| 00:00:02 | | 2 | TABLE ACCESS FULL | C | 10000 | 146K| 26 (4)| 00:00:01 | | 3 | NESTED LOOPS | | 20000 | 1054K| 30137 (1)| 00:00:02 | | 4 | NESTED LOOPS | | 1000K| 1054K| 30137 (1)| 00:00:02 | | 5 | HASH JOIN | | 10000 | 390K| 52 (4)| 00:00:01 | | 6 | TABLE ACCESS FULL | D | 100 | 1800 | 26 (4)| 00:00:01 | | 7 | TABLE ACCESS FULL | A | 10000 | 214K| 26 (4)| 00:00:01 | | 8 | INDEX RANGE SCAN | B_I100 | 100 | | 1 (0)| 00:00:01 | | 9 | TABLE ACCESS BY INDEX ROWID| B | 2 | 28 | 101 (0)| 00:00:01 | ----------------------------------------------------------------------------------------
Notice, yet again, Oracle has done hash join to c with a swap_join_inputs().
Creation Script:
create table a
nologging
as
with generator as (
select
rownum id
from dual
connect by
level <= 1e4
)
select
rownum id,
mod(rownum,5000) n2,
mod(rownum,100) n100,
lpad(rownum,10,'0') v1,
lpad('x',100,'x') padding
from
generator v1
;
create table b nologging as select * from a;
create table c nologging as select * from a;
create table d nologging as select * from a;
alter table a add constraint a_pk primary key(id);
alter table b add constraint b_pk primary key(id);
alter table c add constraint c_pk primary key(id);
alter table d add constraint d_pk primary key(id);
create index a_i2 on a(n2) nologging;
create index b_i2 on b(n2) nologging;
create index c_i2 on c(n2) nologging;
create index d_i2 on d(n2) nologging;
create index a_i100 on a(n100) nologging;
create index b_i100 on b(n100) nologging;
create index c_i100 on c(n100) nologging;
create index d_i100 on d(n100) nologging;
begin dbms_stats.gather_table_stats( ownname => user, tabname =>'A', method_opt => 'for all columns size 1' ); dbms_stats.gather_table_stats( ownname => user, tabname =>'B', method_opt => 'for all columns size 1' ); dbms_stats.gather_table_stats( ownname => user, tabname =>'C', method_opt => 'for all columns size 1' ); dbms_stats.gather_table_stats( ownname => user, tabname =>'D', method_opt => 'for all columns size 1' ); end; /
