새로쓴 대용량 데이터베이스 솔루션 - 제 1부 액세스 영향요소의 이해3-2

3.2 실행계획의 유형

 

 

3.2.1 스캔의 기본유형

 

3.2.1.1 전체 테이블 스캔

- 옵티마이저가 전체 테이블 스캔을 사용하는 경우

  * 적용가능 인덱스의 부재 : 쿼리가 존재하는 인덱스를 전혀 사용할 수 없을 때. 경우에 따라 인덱스 스킵 스캔이 적용되면 인덱스 사용가능

  * 넓은 범위의 데이터 액세스 : 처리 범위가 넓어서 전체 테이블 스캔이 보다 적은 비용이 든다면 인덱스 스캔을 포기할 수 있음

  * 소량의 테이블 액세스 : 최고수위 표시 내 블록이 DB_FILE_MULTIBLOCK_READ_COUNT 내에 있다면 발생 가능

  * 병렬처리 액세스 : 병렬처리로 수행되는 실행계획을 수립할 때는 항상 전체 테이블 스캔을 선택

  * ‘FULL’ 힌트를 적용했을 때 : 쿼리 내에서 ‘FULL(table_alias)’ 힌트를 사용하면 전체 테이블 스캔으로 실행계획을 생성할 수 있음

 

 

3.2.1.2 ROWID 스캔

- 인덱스를 경유하여 테이블을 액세스 하는 과정에서 주로 발생

- 단 하나의 로우를 추출하는 가장 빠른 방법

 

 

3.2.1.3 인덱스 스캔

가) 인덱스 유일 스캔

 - 단 하나의 데이터를 추출함

 - 인덱스가 기본키가 유일 인덱스로 생성되어 구성된 모든 컬럼들이 조건절에서 ‘=’로 비교되어야함

 

나) 인덱스 범위 스캔

 - 가장 보편적인 데이터 액세스 형태

 - 브랜치 블록을 경유하여 시작 리프블록을 찾은 후, 다음 리프블록을 스캔하다가 종료점을 만나면 멈춘다

 - 유일 인덱스나 비유일 인덱스 모두에서 발생할 수 있다.

 

다) 인덱스 역순 범위 스캔

 - 역순으로 데이터를 액세스 하는 것 외에는 인덱스 범위 스캔과 동일

 

라) 인덱스 스킵 스캔

 - 서브 인덱스의 종류가 많지 않고 뒤에 오는 컬럼은 종류가 많을 때 가장 좋은 결과를 냄

 - 선행 컬럼이 아니더라도 인덱스 스킵 스캔을 유도할 수는 있지만 카디널리티가 높아지면 현저하게 수행속도가 저하될 수 있음

 

마) 인덱스 전체 스캔

 - 조건절에서 그 인덱스의 컬럼이 적어도 하나이상 사용되었을 때 적용 가능

 - 쿼리 내에 사용된 어떤 테이블들의 모든 컬럼들이 그 인덱스에 모두 존재하고, 인덱스 컬럼 중 최소한 NOT NULL인 컬럼이 하나는 존재할 때 적용

 

바) 인덱스 고속 전체 스캔

 - 전체 테이블 스캔의 대안으로 사용될 수 있음

 - NOT NULL 제약조건이 정의된 컬럼이 인덱스에 반드시 하나 이상 존재해야 함

 - 인덱스만을 스캔하고 테이블을 액세스 하지 않음.

 - 인덱스 전체 스캔과는 다르게 마치 테이블 액세스처럼 한번의 I/O에 다중 블록을 액세스 함. 따라서 비트맵 인덱스에서는 적용할 수 없음

 

 

3.2.1.4 B-Tree Cluster access

- 클러스터링 테이블 형태

 * 대량의 범위처리의 효율화를 목적으로 한 단일 테이블 클러스터링

 * 조인의 효율적인 연결을 위해 두 개 이상의 테이블을 하나의 클러스터에 저장

 

 

3.2.1.5 해쉬 클러스터 인덱스

- 해쉬 함수에 의해 만들어진 해쉬값을 이용하여 클러스터링을 하는 방법

- 동일 해쉬값을 가진 데이터를 동일 블록 내에 저장하여 클러스터링 팩터를 높임

- 테이블의 크기가 작아서 메모리 적중률이 높다면 유일 인덱스 스캔이 조금 더 유리

- 적중률이 낮은 대용량 테이블의 랜덤 액세스에는 약 30%의 개선효과 발생

- 우편번호 테이블, 시스템 사용자 정보처럼 로우 길이의 편차가 심하지 않고 크기에 대한 예측 가능한 테이블에 아주 빈번한 랜덤 액세스가 발생하면 해쉬 클러스터링을 적용

- 만약 하나이상의 컬럼으로 구성된 결합 해쉬 인덱스를 지정한 경우에는 항상 2개의 조건으로 조회를 실시

 

 

3.2.1.6 표본 테이블 액세스

- 데이터마이닝 활용

 * 잠재적으로 유효하고 새롭고 타당성 있으면서 궁극적으로 데이터에서 이해할 수 있는 패턴을 찾아내는 단순하지 않은 프로세스

 * 숨겨진 패턴과 관계를 찾아내어 의미있는 정보를 발견해 내는 데이터마이닝의 특징은 주로 마케팅에 유용하게 활용됨

 * 따라서 데이터마이닝의 필수 요소는 우선 신뢰도가 높은 충분한 자료

 

- 정제를 위해 데이터의 오류 패턴을 찾아내는데 활용

 * 오류 유형도 일종의 데이터가 발생하는 패턴

 * 잘 엄선된 표본을 생성하기 위해 반드시 전체집합을 대상으로 하지 않아도 됨.

 

3.2.2 데이터 연결을 위한 실행계획

 

3.2.2.1 내포 조인(Nested loops Join)

- 먼저 처리되는 어떤 범위의 집합(Outer)의 각 로우에 대하여 연결고리를 통해 반복적으로 다른 집합(Inner)의 대응되는 로우를 탐침한다

- 먼저 수행되는 집합의 처리범위가 전체 일량을 좌우하며,

- 나중에 반복 수행되는 연결작업이 랜덤 액세스로 발생하므로 소량의 범위 연결은 유용하나 대량의 범위는 커다란 부하를 가져올 수 있음

- 수행 단계

 (1) 먼저 수행될 외측 집합 결정(선행(Driving)집합)처리. 선행집합의 처리범위에 있는 각 로우에 대해 내측 집합을 연결

 (2) 선행집합이 액세스되면 모든 컬럼은 상수값을 가지며 이미 존재하던 상수값을 가진 조건까지 감안해 나머지 집합 중 다음 내측집합을 선택

 (3) 조인될 집합이 더 있다면 위 방법으로 나머지 순서도 결정. 결정에는 연결고리의 인덱스 구조가 중요한 영향 미침

 (4) 실제 조인이 수행될 때는 외측 집합 각 로우에 대해 내측 집합의 대응되는 모든 로우가 액세스 됨

- 내포된 진보 조인(Advanced Nested loops Join)

  * 클러스터링 팩터가 양호하다면 보다 많은 부분을 한 번의 블록 액세스에서 연결할 수 있기 때문에 물리적, 논리적 블록액세스 양 감소, 효율성 ↑

 

 

3.2.2.2 정렬 병합 조인(Sort Merge Join)

- 조인의 대상 범위가 넓을 때 발생하는 랜덤 액세스를 줄이기 위한 경우나 연결고리에 마땅한 인덱스가 존재하지 않을 때를 해결하기 위한 대안

- 연결을 위해 랜덤 액세스를 하지 않고 스캔을 하면서 수행. 이를 위해서는 반드시 두 개의 집합이 연결을 할 수 있는 구조로 정렬되어야함

- 연결작업은 효과적으로 수행되나 먼저 정렬을 해야 한다는 부담

- 메모리에서 수행되므로 정렬을 위한 영역에 따라 효율 차이가 큼

- 어느 한계를 넘으면 NL보다 더 나쁜 수행속도를 가져올 수 있음

- 연결고리의 비교연산자가 ‘=’ 이 아닌 경우(LIKE,BETWEEN,>,<)일 때 NL조인보다 유리한 경우가 많음

- NL과 달리 선행집합의 개념이 없이 독립적인 처리

- ‘USE_MERGE(table1,table2)’ Hint 사용

 

 

3.2.2.3 해쉬 조인(Hash Join)

- 해쉬함수 기법을 활용하여 조인 수행

  : 해쉬함수 -> 컬럼의 값을 받아서 이 함수를 경유하면 row의 저장위치를 return

- NL의 랜덤액세스로 연결하는 부하를 해결하기 위한 Sort Merge Join이나 정렬에 대한 부담이 큼 -> 대용량의 경우에 부적합하여 해결대안으로 등장

- 해쉬 함수는 연결될 대상을 특정지역에 모아두는 역할만을 담당

- Partition(파티션) : 동일한 해쉬값을 가진 데이터를 모아둔 공간

- Pair(짝) : 파티션 내 동일한 해쉬값을 가진 데이터들 중 서로 조인해야할 것들을 연결한 것

- 큰 파티션의 로우가 외측 루프가 되고 hash table access는 내측 루프가 되어 조인을 수행

- 조인의 한쪽이 해쉬영역보다 작아서 In-Memory Hash Join이 가능하게 되면 수행속도는 매우 빨라짐

- Hash Join의 연산자 제약

  * 동치 조인(Equi Join) 일때만 가능

  * 대량 범위에 대한 조인이나 테이블이 너무 많은 조각으로 산재 되어 있을 때 특히 유리

  * 인덱스를 가질 수 없는 가공된 집합과의 조인에서도 효과적

- ‘USE_HASH(table1,table2) Hint 사용

 

 

3.2.2.4 세미 조인(Semi Join)

- 다양한 연산자에 의해 서브쿼리가 메인쿼리와 연결되는 경우

  * 조인 : 조인되는 집합간 수행 순서에 관계없이 논리적으로는 수평적 관계

  * 서브쿼리 : 메인쿼리와 집합의 변형이 없는 수직적(종속적) 관계

- 메인 : 서브 관계 차수에 따른 실행계획

  * 메인 : 서브 = M : 1

    : 서브쿼리가 1쪽 집합이라면 조인과 동일한 방식으로 연결 가능

  * 메인 : 서브 = 1 : M

    : 서브쿼리를 1의 집합으로 만들기 위한 중간 처리 수행

  * 제공자 역할의 서브쿼리일 경우 : SORT(UNIQUE) 처리

  * 확인자 역할의 서브쿼리일 겨우 : FILTER 행 처리

- ORACLE 10g 이전 Hint => ‘MERGE_SJ, MERGE_AJ, HASH_SH, HASH_AJ’

- ORACLE 11g 이후 Hint => ‘USE_MERGE, USE_HASH’

 

 

3.2.2.5 카티젼 조인(Cartesian Join)

- 두 집합간 연결고리가 되는 조건이 전혀 없는 경우(넓은 의미의 M:M 조인)

- 실제 실행계획에서는 CARTESIAN JOIN은 Sort Merge Join 뿐이며, 다른 조인은 정상적인 조인과 동일

- 특별한 목적으로 고의로 만드는 경우, 3개 이상 집합 조인 시 연결고리가 빠져서 발생하는 경우

 

 

3.2.2.6 아우터조인(Outer Join)

- 어떤 대상집합을 기준으로 아우터 조인되는 집합에 대해 대응되는 Row가 없더라도 기준집합의 모든 Row를 리턴

- Nested loops Outer Join

  * 기준이 되는 집합이 바깥쪽 루프로, 먼저 수행되어야 하기 때문에 목적없이 함부로 아우터 조인을 시키면 조인의 방향이 고정되므로 주의

  * ‘USE_NL(table1, table2)’ Hint를 사용하며 실행계획은 동일

  * 표현법은 ‘NESTED LOOPS(OUTER)’ 로 다름

 

- Hash Outer Join

  * NL JOIN으로는 부담되는 대량의 데이터이거나 인덱스 등의 문제로 NL조인으로 수행에 문제가 있을 때 선택 가능

  * 기준집합은 반드시 빌드입력(Build Input)을 담당하며, 내측 조인집합이 해쉬테이블로 생성되어 연결작업 수행

  * 역할이 고정되더라도 NL JOIN에서와 같은 부담은 크게 발생하지 않음

  * 조인뷰 조인 인라인뷰, 아우터 조인 수행시 일반 조인과 같이 뷰병합이나 조건절 진입이 허용되지 않고 뷰 전체집합이 독립적으로 수행된 결과와 아우터 조인을 수행

    : 그러므로 경우에 따라서 뷰 내로 조건절이 파고들 수 없으므로 심각한 부하가 발생함

  * 내측테이블의 특정조건을 만족하는 집합과 아우터 조인을 시도해야한다면 조건을 담은 집합을 인라인뷰로 만든 후 아우터 조인을 하면 조건이 만족

  * 인라인뷰가 단일테이블로 구성된 경우는 조건절 진입(Pushing Predicates)가 가능하므로, 처리 범위 감소

  * But, 조인된 인라인 뷰는 조건절 진입이 불가능하므로 인라인 뷰 내에서 처리범위를 줄일 수 없다면, 아우터 조인으로 인한 심각한 수행속도 저하

 

- Sort Merge Outer Join

  * NL Join으로는 부담이 되는 대량의 데이터이거나 인덱스 등의 문제로 NL조인으로 수행에 문제가 있을 때 선택 가능

  * 조건 연산자로 인해 해쉬조인이 불가능할 때나 이미 다른 처리에 의해 조인을 위한 정렬이 선행되어 있어서 더 유지해질 때 적용된다.

 

- Full Outer Join

  * 양쪽 집합이 모두 기준집합이면서 대응집합이 되는 아우터 조인

  * 한쪽을 기준으로 먼저 아우터 조인을 수행한 결과와 다른 쪽을 기준으로 부정형 조인을 한 결과를 결합하여 리턴

  * 설계상 문제, 데이터의 일관성에 대한 문제가 원인이 되는 경우가 많음

  * 다양한 대안들이 존재

    : 예시) UNION ALL 로 합집합을 만들고 GROUP BY를 이용해 소수공배수 집합을 만드는 방법/인라인뷰/사용자 지정 저항형 함수 등을 활용

 

 

3.2.2.7 인덱스 조인(Index Join)

- 어떤 쿼리에서 특정 테이블에서 사용된 모든 컬럼이 하나 이상의 인덱스들에 존재할 때, 인덱스를 결합하여 테이블을 액세스 하지않고 조인을 처리

- 인덱스 병합은 머지나 해쉬조인으로만 가능(인덱스를 경유해서 다른 인덱스를 액세스 하는 것은 불가능)

- 자주 같이 액세스 되며, 특정 컬럼 때문에 인덱스를 테이블을 액세스 하는 경우가 많이 발생한다면 인덱스 조인을 선택 가능

 

 

3.2.3 연산방식에 따른 실행계획

 

3.2.3.1 In-List 탐침(Iterator) 실행계획

- ‘IN’을 사용한 경우는 실행계획에 큰 영향을 미침

- ‘BETWEEN’은 선분을 의미하나 ‘IN’은 여러개의 점을 의미

- 선분 개념은 Range Scan을 하게 되나 점의 개념은 ‘=’을 사용할 수 있다

- 예시) 실행계획 ‘INLIST’ 아래 있는 처리를 ‘IN’ 조건에 나열된 각각의 비교값 만큼 반복수행한다. IN대신 OR을 사용해도 동일한데 그 이유는

옵티마이저가 ‘IN’연산을 OR형태로 변경한 후 실행계획을 수립하기 때문

- INDEX(table_alias index_name) Hint를 적용하여 IN조건을 사용한 컬럼이 속한 인덱스를 사용할 수 있으나, 적용여부는 옵티마이저가 결정

 

3.2.3.2 연쇄(Concatenation) 실행계획

- ‘OR’로 연결된 서로 다른 컬럼을 사용한 조건을 별도의 실행단위로 분리하여 각각의 최적 액세스 경로를 수립하여 이를 연결하는 실행계획

- 항상 이런 실행계획이 나타나는 것은 아니며, OR조건이 처리주관 조건의 역할을 하는 경우에만 실행됨. 아닌 경우 단순 체크 조건으로만 사용

- ‘USE_CONCAT’으로 유도가능, ‘NO_EXPAND’ 적용이 불가능하게 할 수 있음

- OR 조건은 주어진 상황에 따라 연결 실행계획이 유리할수도, 불리할수도 있으므로 가능하면 실행계획 확인 후 함부로 힌트 적용을 하지 않을 것

- 적용하지 않는 것이 바람직한 경우

  * 조인의 연결고리가 OR 조건을 가질 때 조인의 상대방이 넓은 처리범위를 가질 때

  * 동일 컬럼의 OR조건 ( In-List 탐침이 유리 )

  * 보다 효율적으로 처리범위를 줄일 수 있는 다른 액세스 경로가 존재할 때

  * OR 조건들 중 너무 넓은 처리범위를 가진 것들이 존재할 때

 

 

3.2.3.3 원격(Remote) 실행계획

- 다른 DB 테이블을 DC Link로 액세스하는 형태

- 원격 테이블의 상세 실행계획은 나타나지 않아 어떤 방법으로 액세스 했는지 알 수 없음

- 원격 테이블이 실행계획에 부담이 많은 내측루프에서 수행되면 부담이 큼. 원격테이블 액세스는 랜덤이 아닌 범위처리에는 부담이 적으므로 이 경우에는 Sort Merge나 Hash Join으로 나타나는 경우가 많음

- 논리적으로 가장 이상적인 방법은 원격에서 두 테이블을 조인하고 결과를 로컬에서 받는 방법.(원격에 미리 조인된 뷰를 만든다)

- 항상 실행계획을 확인하는 습관을 가질 것

 

3.2.3.4 정렬처리(Sort Operation) 실행계획

- 액세스된 데이터는 사용자의 요구 충족을 위해 다양한 가공을 하며 이러한 가공에는 정렬이 필요한 경우가 많음

- SORT(UNIQUE)

  : DISTINCT 함수를 사용할 때

  : 서브쿼리에서 제공자 역할을 할 때

- SORT(AGGREGATE)

   : GROUP BY를 하지 않은 상태에서 전체 대상에 대해 그룹함수로 계산할 때

- SORT(GROUP BY)

  : GROUP BY를 사용하여 여러개의 다른 그룹으로 집결을 수행할 때 발생되며, 그룹의 개수가 많을수록 부담 증가

  : 이러한 문제를 해결하기 위해, GROUP BY를 해쉬를 이용해서 처리할 수도 있다. (GROUP BY NOSORT)

 

 

3.2.3.5 집합처리(Set Operation) 실행계획

-  실행계획

  * UNION은 최소 공배수 집합을 구해야 하므로 추가로 SORT(UNIQUE)를 수행

  * UNION ALL은 정렬처리가 필요하지 X

 

- 교집합(Intersection) 실행계획

 * 양쪽 집합 모두에 속하는 공통집합을 의미하며 이를 구하기 위해서는 각 집합에서 유일한 집합을 구해야 함

 

- 차집합(Minus) 실행계획

 * 어느 한쪽 집합을 기준으로 다른 집합의 요소들을 제거

 * SubQuery, In-line View, DISTINCT 등을 사용하여 동일한 결과 보장 가능

 * SELECT-LIST에 나타난 모든 컬럼들의 유일 집합을 만들기 위해 MERGE 작업과 유사한 실행계획 출력

  : SORT(UNIQUE)

  : 단, 기본키 ‘=’(EQUAL) 액세스는 SORT(UNIQUE)가 발생하지 X

                         

 

3.2.3.6 COUNT(STOPKEY) 실행계획

- 조건절에 ROWNUM을 사용했을 경우 발생

- ROWNUM

  : 가상(PSEUDO) 컬럼 – 테이블에는 존재하지 않지만 DBMS가 제공한 컬럼

  : SYSDATE, USER, ROWID, LEVEL ( CONNECT BY 사용시 )

 

 

3.2.4 비트맵(Bitmap) 실행계획

 

3.2.4.1 조건 연산자별 비트맵 실행계획

가) 동치(EQUAL) 비교 실행계획

 - 하나의 컬럼을 ‘=’ 로 비교한 경우로 가장 단순한 형태의 실행계획

 - IN을 사용한 경우는 단지 ‘=’ 연산자를 여러개 사용한 것일 뿐임

나) 범위(RANGE) 비교 실행계획

 - BETWEEN, LIKE, >, <, 등의 범위 비교 연산자를 사용하면 여러개의 키 값에 대한 비트맵의 검색을 의미하는 RANGE SCAN이 나타남

 - NUMBER TYPE으로 정의된 컬럼에서는 인덱스를 FULL SCAN 하는 실행계획이 나타남

다) AND 조건 실행계획

 - 각 비트맵을 액세스하여 AND연산 수행

 - 비트맵을 범위스캔하는 경우 이들을 먼저 비트맵 머지를 수행하여 그 결과와 AND연산을 수행

라) OR 조건 실행계획

 - 각 컬럼에서 자신의 단위 액세스를 생성하고 결과의 비트맵으로 OR연산 실시

 - 부정형 조건 ( <>, NOT IN 등)이 OR로 사용되면 하나의 비트맵 인덱스만 사용

마) 부등식(NOT EQUAL) 비교 실행계획

 - 부등식이 사용되면 BITMAP MINUS 연산을 수행

 - NOT NULL 제약조건을 가진 경우/그렇지 않은경우의 처리는 달라짐

바) NULL 비교 실행계획

 

 

3.2.4.2 서브쿼리 실행계획

- 액세스한 팩트 테이블과 디멘전 테이블을 조인

- 서브쿼리를 통해 액세스한 비트맵을 결합하여 팩트 테이블 액세스

- ITEM 서브쿼리로 팩트 테이블의 비트맵을 액세스

- COUNTRY 서브쿼리로 팩트 테이블의 비트맵을 액세스

 

 

3.2.4.3 B-TREE 인덱스와의 연합(CONBINE)실행계획

- 비트맵을 ROWID로 전환할 수 있고 다시 ROWID를 비트맵으로 전환할 수 있는 특성을 이용해 B-TREE 인덱스를 비트맵으로 전환하여 연산 수행

- 비트맵 인덱스가 전혀 없는 경우 INDEX_COMBINE 힌트를 적용하면 비트맵 액세스 가능

 

3.2.5 기타 특수한 목적을 처리하는 실행계획

 

 

3.2.5.1 순환(Recursice) 전개 실행계획

- 순환구조를 가진 테이블에서 어떤 점을 시작점으로 해서 하위의 구조를 전개하는 순전개나 역전개를 할 때 발생하는 실행계획

- CONNECT BY .... START WITH 구문 사용시

- 순환전개에 의한 추출 결과는 구조적인 모습으로 함부로 ORDER BY를 사용하면 구조가 깨어질 수 있음 => ORDER SIBLINGS BY 사용

  : SIBLINGS => 특정 컬럼에 대한 ORDER BY 실행(조회된 데이터에 대해)

- 순환구조의 처리에서는 WHERE 절은 단순 결과를 체크하는 기능만 함

 

 

3.2.5.2 UPDATE 서브쿼리 실행계획

- SET, WHERE절에 서브쿼리 사용 가능(SET절에 사용된 서브쿼리 => Scalar Subquery)

- 서브쿼리를 먼저 실행하여 메인쿼리에 결과를 제공

- 실패(fail) : 정상적으로 실행된 결과가 존재하지 않는 것(null 값을 결과로 리턴)

- 에러(error) : 쿼리가 정상적으로 실행되지 않은 것

- 그룹함수(SUM, MIN, MAX, COUNT, AVG 등)가 들어가 있으면 언제나 실패가 발생 X

  : SELECT-List에 ‘NVL, NVL2, COALESCE’ 등을 사용하여 NULL값으로 리턴되는 것을 방지

  : 스칼라 서브쿼리가 많은 실패를 발생시킨다면 불필요한 UPDATE가 증가하므로 WHERE절에 다시 한번 서브쿼리를 사용하여 갱신대상 축소

  : 위 방법은 동일 쿼리가 두 번 수행되어야 하므로 ‘수정가능 조인뷰(Modifiable Join View)’를 사용하여 방지

 

3.2.5.3 특이한 형태의 실행계획

가) 서브쿼리 팩토리 실행계획

 - 서브쿼리 팩토링 : WITH절을 사용하여 생성한 복잡한 쿼리문을 임시 테이블에 실제 저장 해두었다가 거의 테이블과 동일하게 사용할 수 있는 기능

 - 임시 테이블을 생성하기 위해 WITH절의 쿼리를 내부적으로 실행하여 자동으로 명칭을 부여 => 임시테이블을 선행 테이블로 조인 실시

 - 넓은 범위 처리를 해서 소량의 결과를 얻는다면 인라인뷰와 차이가 매우 큼

 - 쿼리 변형이 불가능하다

   : 임시 테이블은 인덱스를 가질 수 없으므로 처리 결과가 소량이 아니라면 비효율이 발생할 가능성

   : 복잡한 가공을 한 결과를 하나의 쿼리에서 여러번 사용해야 할 때 유리

나) 특이한 DELETE문 서브쿼리 실행계획

다) 다중 테이블 입력(Multi-table Insert) 서브쿼리

 - 다중 테이블 입력 : 하나의 쿼리에서 액세스한 로우를 여러개의 테이블에 동시에 입력할 수 있는 기능

 - 실행계획에서 한번 액세스한 결과를 여러 테이블에 제공함

 - 다양한 방법의 조인이 가능함

   : 파일시스템으로 구성된 과거 시스템 데이터를 관계형 데이터베이스 구조로 이행할 때 유용

   : 데이터 웨어하우스를 구축할 때 적용

라) HAVING절 서브쿼리 실행계획

마) ROLLUP, CUBE, GROUPING SETS 처리 실행계획

 - ROLLUP과 CUBE는 기존의 실행계획과 큰 차이가 없음

 - 단계별로 ROLLUP을 수행시키면 옵티마이저는 임시 테이블을 생성하고 이를 이용해 결과를 생성

바) MERGE문 실행계획