그럼 이제 Logical Optimizer가 재작성한 SQL을 보자.

SELECT d.department_id, d.department_name, d.location_id
  FROM department d
 WHERE NOT EXISTS (SELECT 0            
                     FROM employee e
                    WHERE e.department_id IS NULL) --NULL 을 체크하는 서브쿼리
   AND NOT EXISTS (SELECT 0            
                     FROM employee e
                    WHERE e.department_id  = d.department_id)                     
   AND d.location_id = 1700 ;
 

SQL을 보면 NOT IN 서브쿼리가 NOT EXIST 서브쿼리로 바뀌었고 NULL을 체크하는 서브쿼리가 
추가되었다. 또한 NULL을 체크하는 서브쿼리의 결과가 한 건이라도 존재하면 SQL은 더 이상 
실행되지 않는다는 것을 알 수 있다. NESTED LOOPS ANTI SNA의 비밀이 풀리는 순간이다. 
ORACLE 9i와 10g 에서도 위와 같이 SQL을 작성하면 NESTED LOOPS ANTI SNA의 효과를 볼 수 
있다. 하지만 위의 SQL처럼 수동으로 작성하는경우 NULL 한건을 체크 하는데 오래 걸리며 
부하가 있다면 이렇게 사용하면 안 된다. 이제 Plan을 보자.

-------------------------------------------------------------------------------------------
| Id  | Operation                     | Name              | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                   |      0 |00:00:00.01 |       4 |
|*  1 |  FILTER                       |                   |      0 |00:00:00.01 |       4 |
|   2 |   NESTED LOOPS ANTI           |                   |      0 |00:00:00.01 |       0 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DEPARTMENT        |      0 |00:00:00.01 |       0 |
|*  4 |     INDEX RANGE SCAN          | DEPT_LOCATION_IX  |      0 |00:00:00.01 |       0 |
|*  5 |    INDEX RANGE SCAN           | EMP_DEPARTMENT_IX |      0 |00:00:00.01 |       0 |
|*  6 |   TABLE ACCESS FULL           | EMPLOYEE          |      1 |00:00:00.01 |       4 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter( IS NULL)
   4 - access("D"."LOCATION_ID"=1700)
   5 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
   6 - filter("E"."DEPARTMENT_ID" IS NULL)
 
Operation의 순서에 유의하라(굵은 글씨체)
위의 Plan을 과 원본 Plan을 비교해보면 원본이 ANTI SNA라는 것만 제외하면 실행계획과 일량까지 
같음을 알 수 있다. 헷갈리지 말아야 할 것은 ID 기준으로 6번(NULL 체크 서브쿼리)이 가장 먼저 
실행된다는 것이다. 왜냐하면 서브쿼리 내부에 메인쿼리와 조인조건이 없기 때문에 서브쿼리가 
먼저 실행될 수 있기 때문이다. 반대로 Filter 서브쿼리내부에 메인쿼리와 조인 조건이 있다면 
메인쿼리의 컬럼이 먼저 상수화 되기 때문에 항상 서브쿼리쪽 집합이 후행이 된다. 이런 사실을 
모르고 보면 PLAN상으로만 보면 NULL 체크 서브쿼리가 가장 마지막에 실행되는 것으로 착각 할 수 있다.