How to walk through an explain plan

Question

Hi Experts,
I am on Oracle 11.2.0.2 on Linux, I have a query with an query plan as below. I am trying to understand the sequence in which the steps are executed, can you please help on it:
variable v_client_oid varchar2(16);
variable SYS_B_0 varchar2(16);
variable SYS_B_1 NUMBER;
variable SYS_B_2 varchar2(16);
--0Y0WJ354NKR00E6J
exec :v_client_oid:= '0G34308B12X006XJ';
exec :SYS_B_0:= 'Y';
exec :SYS_B_1:= 1;
exec :SYS_B_2:= 'N';
UPDATE acc_usr_RL_cross a
   SET included = :"SYS_B_0"
WHERE     clnt_oid = :v_clnt_oid
       AND EXISTS
              (SELECT :"SYS_B_1"
                 FROM    acc_usr_RL_cross x
                      JOIN
                         acc_RL r
                      ON (x.RL_oid = r.oid)
                WHERE     x.included = :"SYS_B_2"
                      AND a.RL_oid = r.parent_RL_oid
                      AND a.usr_id = x.usr_id)
| Id  | Operation                     | Name                     | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem |  O/1/M   |
|   1 |  UPDATE                       | ACC_USR_RL_XREF          |      1 |        |            |      0 |00:01:48.80 |     240K|    240K|       |       |          |
|*  2 |   HASH JOIN SEMI              |                          |      1 |      1 | 60220   (1)|      1 |00:01:48.79 |     240K|    240K|  1448K|  1053K|     1/0/0|
|   3 |    TABLE ACCESS BY INDEX ROWID| ACC_USR_RL_XREF         |      1 |  22262 |  7522   (1)|   8515 |00:00:00.46 |     277 |    174 |       |       |          |
|*  4 |     INDEX RANGE SCAN          | ACC_USR_RL_XREF_IDX08   |      1 |  22262 |   165   (0)|   8515 |00:00:00.02 |      65 |      0 |       |       |          |
|   5 |    VIEW                       | VW_SQ_1                  |      1 |   5454K| 52669   (1)|   5701K|00:01:31.57 |     240K|    240K|       |       |          |
|*  6 |     HASH JOIN                 |                          |      1 |   5454K| 52669   (1)|   5701K|00:01:25.87 |     240K|    240K|  1853K|  1647K|     1/0/0|
|   7 |      TABLE ACCESS FULL        | ACC_RL                   |      1 |  28560 |   111   (1)|  28561 |00:00:00.19 |     443 |    439 |       |       |          |
|*  8 |      INDEX FAST FULL SCAN     | ACC_USR_RL_XREF_IDX08   |      1 |   5454K| 52530   (1)|   5701K|00:01:08.48 |     239K|    239K|       |       |          |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   2 - access("A"."RL_OID"="PARENT_RL_OID" AND "A"."USR_ID"="USR_ID")
   4 - access("CLNT_OID"=:V_CLNT_OID)
   6 - access("X"."RL_OID"="R"."OID")
   8 - filter("X"."INCLUDED"=:SYS_B_2)
Here my question is how does the execution happen - What does HASH JOIN SEMI mean here? I was expecting that subquery will get executed several times as there is exists but everywhere the STARTS is just 1.  I am not clear on what is HASH JOIN SEMI and also why even though there is EXISTS, still the STARTS are only 1 (I was expecting several of them).
Will be thankful for help on this.
OrauserN

Answer 1

A SEMI JOIN can stop as soon as it finds one matching row.
So for your EXISTS, we don't need to join all the matches between the rowsources, we can stop as soon as we find the first match.
The general approach to reading an execution plan - and which is true nearly all (but not all) of the time -  is to find the first operation without a child - this is the starting step.
Preservation of spacing makes reading execution plans much easier.
The first step of your plan is at step 4 - the INDEX RANGE SCAN of ACC_USR_RL_XREF_IDX08 with access predicate:
CLNT_OID = :V_CLNT_OID
The rowids from this index lookup are used to do a table lookup at step 3.
These rows are then hashed into memory for the HASH JOIN SEMI at step 2 where you join with your EXISTS subquery.
The VIEW operation at line 5 indicates that this is a non-mergeable view and it's a HASH JOIN of a full table scan of ACC_RL and an index FFS of ACC_USR_RL_XREF_IDX08.
A HASH JOIN will have starts of 1 because, broadly speaking, you take the driving rowsource and hash on the join colums then you then take the inner rowsource and do the same hash which gives you the matching rows.
A nested loop is more like a for loop - for each row in the driving rowsource, probe the inner rowsource. Therefore for each row returned by the driving rowsource, you get a "start" on the inner rowsource.
Message was edited by: Dom Brooks