데이터베이스 실행계획의 유형

 실행계획의 유형

 실행계획은 테이블에서 데이터를 추출해서 쿼리가 원하는 결과를 생성해 가는 경로이며 기본적인 형태는 물리적인 데이터를 찾아서 엑세스하는 것이다. 이를 스캔(Scan)이라고 한다. 

 하나 이상의 테이블에서 스캔을 하여 서로 연결하는 처리를 조인이라고 하며 찾은 데이터는 각종 연산에 의해 가공처리를 한다.

 실행계획의 유형은 네 가지로 구분한다.

 1. 스캔을 위한 실행계획

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

 3. 각종 연산을 위한 실행계획

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

 

스캔(Scan)의 기본유형

 물리적으로 저장되어 있는 테이블에서 로우를 찾아 엑세스하는 방법은 거의 모든 실행계획의 가장 안쪽 깊은 곳에 있기 마련이다. 

 실행계획에서 수행속도에 가장 많은 영향을 미치는 부분이기도 하다. 또한 대부분의 실행계획에서 수행속도에 가장 많은 영향을 미치는 부분이기도 하다.

 스캔의 기본 유형은 아래와 같다.

 1. 전체테이블 스캔(Full Table Scans)

 2. 로우식별자 스캔(Rowid Scans)

 3. 인덱스 스캔(Index Scans)

 4. 클러스터 엑세스(Cluster Access)

 5. 해쉬 액세스(Hash Access)

 6. 표본 테이블 스캔(Sample Table Scans)

 

전체테이블 스캔

 테이블에 있는 모든 로우들을 읽어내는 방법이다. 액세스를 하면서 WHERE 절에 기술된 조건들을 확인하여 골라내는 과장을 거친다. 스캔하는 동안에 테이블에 표시된 최고 수위선내에 있는 모든 블록들을 스캔한다.

 최고 수위선이란 사용된 저장공간의 총합계나 데이터를 넣기 위해 포맷된 영역을 표시하는 것이다.

 전체테이블 스캔은 특히 대용량의 테이블에서 진가를 발휘한다. 소량의 테이블일 때 인덱스 스캔과의 손익분기점이 15%였다면 테이블이 매우 커졌을 떄는 5%이하가 될 수도 있다.

 즉, 인덱스로 1% 액세스하는 것보다 전체 테이블을 스캔하는 것이 유리할 수도 있다는 것이다.

이러한 상황이 발생하는 이유는 발전하고 있는 디스크 장비도 한 몫을 하고 있다. 

 옵티마이져가 전체테이블 스캔을 선택하게 되는 경우는 아래와 같다.

 1. 인덱스의 부재 : 어 테이블에 적절한 인덱스가 없거나, 쿼리에서 인덱스를 사용하지 않도록 명시적으로 지정한 경우에 적용된다. 함수기반 인덱스를 사용하면 인덱스 사용이 가능하다. 선두 컬럼은 없지만 인덱스 스킵 스캔(Index Skip Scan)이 적용되면 인덱스 사용이 가능하다.

 2. 넓은 범위의 데이터 액세스 : 옵티마이져는 비록 적용 가능한 인덱스가 존재하더라도 처리 범위가 넓어서 전체테이블 스캔이 보다 적은 비용이 든다면 인덱스 스캔을 포기할 수 있다.

 3. 소량의 테이블 액세스 : 최고수위 표시 내에 있는 블록이 DB_FILE_MULTIBLOCK_READ_COUNT 이내에 있다면 전체 테이블 스캔이 일어날 수 있다. 이 파라메터 내의 블록을 가지고 있다고 하더라도 항상 인덱스를 사용하지 않는 것은 결코 아니다.

 4. 병렬처리 액세스 : 병렬처리는 전체테이블 스캔을 더욱 효과적으로 수행하게 되므로 옵티마이져는 병렬처리로 수행되는 실행계획을 수립할 때는 항상 전체 테이블 스캔을 선택한다. 만약 너무 높은 병렬단계를 지정하면 인덱스 스캔을 하지 않는 방향으로 왜곡될 수 있으므로 주의한다.

 5. FULL 힌트를 적용했을 때 : 쿼리 내에서 FULL(table_alias) 힌트를 사용하면 옵티마이져는 전체 테이블 스캔으로 실행계획을 생성할 수 있다. 물론 적절하지 않은 힌트는 무시되므로 이러한 힌트를 사용했다고 해서 언제나 전체 테이블을 스캔하는 것은 아니다.

 

ROWID 스캔

 ROWID는 그 로우를 포함하고 있는 데이터파일과 데이터 블록, 그리고 블록 내에서의 위치를 가지고 있다.단 하나의 로우를 테이블에서 추출하는 가장 빠른 방법이다. 

 이 스캔을 위해서는 먼저 ROWID를 확보하고 있어야 한다. 

 이 방법은 주로 배치처리 애플리케이션에서 많이 사용하고 있다. 먼저 DECALARE CURSOR로 선언된 쿼리에 대해 FETCH를 하면서 같이 저장해 두었다가 여러 가지 추가적인 가공을 한 결과를 갱신해 넣는 경우에 주로 적용한다.