Implementation plan: what does it mean "2 - access("DEPARTMENT_ID"=:B1)"?

Hello

I'm looking on the execution plan for a query that doesn't use bind variable or a predicate that uses a literal, and yet what follows
   2 - access("DEPARTMENT_ID"=:B1)
lands in the execution plan, which suggests a variable binding (or maybe just a variable... I don't know). Can anyone tell me please what this line means? What is ": B1?" The complete plan is below.
Thank you very much
Jason
2DAYPLUS@ORCL> l
  1  SELECT d.DEPARTMENT_ID,
  2      d.DEPARTMENT_NAME,
  3      (select count(*)from oehr_employees where department_id = d.department_id)  "Number of Employees",
  4      substr(e.first_name,1,1)||'.'||e.last_name "Manager Name",
  5      c.COUNTRY_NAME "Location"
  6  FROM OEHR_DEPARTMENTS d,
  7     OEHR_EMPLOYEES e,
  8     OEHR_LOCATIONS l,
  9     OEHR_COUNTRIES c
 10  WHERE d.LOCATION_ID=l.LOCATION_ID
 11      AND l.COUNTRY_ID=c.COUNTRY_ID
 12      AND d.DEPARTMENT_ID=e.department_id
 13*     AND d.manager_id=e.employee_id
2DAYPLUS@ORCL> set autotrace traceonly
2DAYPLUS@ORCL> /

11 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1307235721

----------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name                   | Rows  | Bytes | Cost (%CPU)| Time  |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                        |    27 |  4077 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                 |                        |     1 |    13 |            |       |
|*  2 |   INDEX RANGE SCAN              | OEHR_EMP_DEPARTMENT_IX |     1 |    13 |     1   (0)| 00:00:01 |
|   3 |  NESTED LOOPS                   |                        |       |       |            |       |
|   4 |   NESTED LOOPS                  |                        |    27 |  4077 |     2   (0)| 00:00:01 |
|   5 |    NESTED LOOPS                 |                        |    27 |  2673 |     2   (0)| 00:00:01 |
|   6 |     NESTED LOOPS                |                        |    23 |   989 |     2   (0)| 00:00:01 |
|   7 |      INDEX FAST FULL SCAN       | OEHR_COUNTRY_C_ID_PK   |    25 |   650 |     2   (0)| 00:00:01 |
|   8 |      TABLE ACCESS BY INDEX ROWID| OEHR_LOCATIONS         |     1 |    17 |     0   (0)| 00:00:01 |
|*  9 |       INDEX RANGE SCAN          | OEHR_LOC_COUNTRY_IX    |     1 |       |     0   (0)| 00:00:01 |
|  10 |     TABLE ACCESS BY INDEX ROWID | OEHR_DEPARTMENTS       |     1 |    56 |     0   (0)| 00:00:01 |
|* 11 |      INDEX RANGE SCAN           | OEHR_DEPT_LOCATION_IX  |     4 |       |     0   (0)| 00:00:01 |
|* 12 |    INDEX RANGE SCAN             | OEHR_EMP_DEPARTMENT_IX |     8 |       |     0   (0)| 00:00:01 |
|* 13 |   TABLE ACCESS BY INDEX ROWID   | OEHR_EMPLOYEES         |     1 |    52 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("DEPARTMENT_ID"=:B1)
   9 - access("L"."COUNTRY_ID"="C"."COUNTRY_ID")
  11 - access("D"."LOCATION_ID"="L"."LOCATION_ID")
  12 - access("D"."DEPARTMENT_ID"="E"."DEPARTMENT_ID")
  13 - filter("D"."MANAGER_ID"="E"."EMPLOYEE_ID")

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         33  consistent gets
          0  physical reads
          0  redo size
       1265  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         11  rows processed

2DAYPLUS@ORCL>

I'm looking on the execution plan for a query that doesn't use bind variable or a predicate that uses a literal, and yet what follows

2 - access("DEPARTMENT_ID"=:B1)

It is the access to the scalar subquery predicate correlated in the SELECT clause:

 (select count(*)from oehr_employees where department_id = d.department_id)

In this case, Oracle cannot merge the subquery in the main query, so it runs for each row in the result set by forcing the department_id against the main request:

select count(*) from oehr_employees where department_id = :B1

Tags: Database

Similar Questions

Maybe you are looking for