Tuesday, February 16, 2010

New Implementation for Nested Loop Joins (11g onwards)

Oracle Database 11g introduces a new implementation for nested loop joins to reduce overall latency for physical I/O. When an index or a table block is not in the buffer cache and is needed to process the join, a physical I/O is required. Oracle Database 11g can batch multiple physical I/O requests and process them using a vector I/O instead of processing them one at a time.

As part of the new implementation for nested loop joins, two NESTED LOOPS join row sources might appear in the execution plan where only one would have appeared in prior releases. In such cases, Oracle Database allocates one NESTED LOOPS join row source to join the values from the table on the outer side of the join with the index on the inner side. A second row source is allocated to join the result of the first join, which includes the rowids stored in the index, with the table on the inner side of the join.

There are cases where a second join row source is not allocated, and the execution plan looks the same as it did in prior releases. The following list describes such cases:

  • All of the columns needed from the inner side of the join are present in the index, and there is no table access required. In this case, Oracle Database allocates only one join row source.

  • The order of the rows returned might be different than it was in previous releases. Hence, when Oracle Database tries to preserve a specific ordering of the rows, for example to eliminate the need for an ORDER BY sort, Oracle Database might use the original implementation for nested loop joins.

  • The OPTIMIZER_FEATURES_ENABLE initialization parameter is set to a release before Oracle Database 11g. In this case, Oracle Database uses the original implementation for nested loop joins.


    SQL> alter session set optimizer_features_enable=xxx;
    ERROR:
    ORA-00096: invalid value XXX for parameter optimizer_features_enable, must be from among 11.2.0.1.1, 11.2.0.1, 11.1.0.7, 11.1.0.6, 10.2.0.5, 10.2.0.4, 10.2.0.3, 10.2.0.2, 10.2.0.1, 10.1.0.5,
    10.1.0.4, 10.1.0.3, 10.1.0, 9.2.0.8, 9.2.0, 9.0.1, 9.0.0, 8.1.7, 8.1.6, 8.1.5, 8.1.4, 8.1.3, 8.1.0, 8.0.7, 8.0.6, 8.0.5, 8.0.4, 8.0.3, 8.0.0


    SQL> alter session set optimizer_features_enable='10.2.0.4';

    Session altered.

    SQL> explain plan for
    2 SELECT e.first_name, e.last_name, e.salary, d.department_name
    3 FROM hr.employees e, hr.departments d
    4 WHERE d.department_name IN ('Marketing', 'Sales')
    5 AND e.department_id = d.department_id;

    Explained.

    SQL> @?/rdbms/admin/utlxpls

    PLAN_TABLE_OUTPUT
    -------------------------------------------------------------------------------------------------
    Plan hash value: 2912831499

    -------------------------------------------------------------------------------------------------
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    -------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | | 19 | 722 | 4 (0)| 00:00:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 10 | 220 | 1 (0)| 00:00:01 |
    | 2 | NESTED LOOPS | | 19 | 722 | 4 (0)| 00:00:01 |
    |* 3 | TABLE ACCESS FULL | DEPARTMENTS | 2 | 32 | 3 (0)| 00:00:01 |
    |* 4 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX | 10 | | 0 (0)| 00:00:01 |
    -------------------------------------------------------------------------------------------------

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

    3 - filter("D"."DEPARTMENT_NAME"='Marketing' OR "D"."DEPARTMENT_NAME"='Sales')
    4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

    17 rows selected.



    SQL> alter session set optimizer_features_enable='11.1.0.6';

    Session altered.

    SQL> explain plan for
    2 SELECT e.first_name, e.last_name, e.salary, d.department_name
    3 FROM hr.employees e, hr.departments d
    4 WHERE d.department_name IN ('Marketing', 'Sales')
    5 AND e.department_id = d.department_id;

    Explained.

    SQL> @?/rdbms/admin/utlxpls

    PLAN_TABLE_OUTPUT
    ----------------------------------------------------------------------------------------------------
    Plan hash value: 1021246405

    --------------------------------------------------------------------------------------------------
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    --------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | | 19 | 722 | 4 (0)| 00:00:01 |
    | 1 | NESTED LOOPS | | | | | |
    | 2 | NESTED LOOPS | | 19 | 722 | 4 (0)| 00:00:01 |
    |* 3 | TABLE ACCESS FULL | DEPARTMENTS | 2 | 32 | 3 (0)| 00:00:01 |
    |* 4 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX | 10 | | 0 (0)| 00:00:01 |
    | 5 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 10 | 220 | 1 (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------

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

    3 - filter("D"."DEPARTMENT_NAME"='Marketing' OR "D"."DEPARTMENT_NAME"='Sales')
    4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

    18 rows selected.
  • No comments:

    Post a Comment