사용자 도구

사이트 도구


study:oracle:datadb:2week_1:chap3

제 3장 SQL의 실행계획 - 옵티마이져의 최적화 절차

  1. 최초에 사용자가 실행한 SQL은 Data Dictionary를 참조하여 Parsing을 수행한다.
  2. Optimizer는 파싱결과를 이용해 논리적으로 적용 가능한 실행계획 형태를 선택하고
    힌트를 감안하여 일차적으로 잠정적인 실행계획들을 생성한다
  3. Data Dictionary의 통계정보(데이타 분포도,테이블 저장구조, 인덱스 구조, 파티션 행태, 비교연산자 등)을 감안하여
    각 실행계획의 비용을 계산한다.
  4. Optimizer는 비용이 산출된 실행계획들을 비교하여 가장 최소의 비용을 가진 실행계획을 선택한다

개요

최적화 절차 비용 산정기 실행계획 생성기
View Merging 선택도(selectivity) 적응적 기법
조건절 진입 카디널리티(Cardinality) 경험적 기법
서브쿼리 비내포화 비용(Cost)
M-View의 쿼리 재생성
OR 조건의 전개
Peeking

질의 변환기

정의

  • 보다 양호한 실행계획을 얻을 수 있도록
    적절한 형태로 SQL의 모양을 변환하는 것

뷰병합(View Merging)

  1. 뷰 정의 시에 지정한 쿼리(뷰쿼리)를 액세스가 수행되는 쿼리(액세스쿼리)에 병합(Merge)
  2. <color blue>수행시킨 쿼리를 기준으로 뷰에 지정한 부분만 보정하므로 뷰로 발생되는 불이익이 크게 감소</color>
  3. 액세스 쿼리의 조건들이 제 역할을 할 수 있고, 뷰 쿼리의 조건까지 추가
  4. 몇 가지 제한요소가 있어 이를 준수하지 않으면 뷰병합은 불가능

조건절 진입(Predicate Pushing)

  1. <color blue>뷰병합을 할 수 없는 경우를 대상으로 뷰쿼리 내부에 액세스쿼리의 조건절을 진입시키는 질의 변환</color>
  2. 액세스쿼리를 뷰쿼리로 진입시키는 방법
  3. 이렇게 가능한 모든 방법을 동원해서 부여 조건을 뷰쿼리 내에 최대한 반영시켜 보다 양호한 실행계획을 유도

서브쿼리 비내포화(Subquery Unnesting)

  1. <color blue>서브쿼리를 사용하는 쿼리는 종종 내포관계 해제나 조인형식으로 대체하여 보다 양호한 수행속도를 얻음</color>
  2. 실제로 대부분의 서브쿼리는 이러한 변환을 거침
  3. 서브쿼리 비내포화가 불가능하면 서브쿼리를 먼저 수행하거나 나중에 수행하는 실행계획 수립
  4. 서브쿼리가 수행되는 순서에 따라 수행속도에는 매우 큰 차이가 나타날 수 있음

Meterialized View(실체뷰)의 쿼리 재생성(Query rewrite)

  1. <color blue>M-View는 테이블과 밀접한 논리적 관계를 가진 물리적 집합이므로 최적의 집합을 처리하도록 쿼리를 재생성</color>
  2. 일종의 확장된 뷰병합 기능
  3. 상황에 따라 어떤 물리적 집합을 액세스할 것인지 고민할 필요가 없으므로 매우 유용한 기능
  4. M-View의 쿼리 재생성(Query Rewrite)은 비용기준에 의해 결정
    (테이블 액세스가 적은 비용을 가지면 쿼리 재생성 하지 않음)

OR 조건의 전개(expansion)

  1. <color blue>OR 조건이 처리주관 조건이 되면 여러 개의 단위 쿼리로 분기하고 UNION ALL로 연결하는 질의로 변환</color>
  2. 단지 체크 조건으로만 사용되는 경우에 이와 같은 전개가 발생하면 오히려 큰 비효율이 발생
  3. 옵티마이져는 비용기준에 의해 전개여부를 결정

사용자 정의바인드 변수 엿보기(Peeking)

  1. Optimizer는 쿼리 내에 사용자가 조건절에 지정한 바인드 변수가 있을 때 실제로 그 변수에 어떤 값이 들어올지 알 수 없기 때문에 통계정보를 제대로 참조할 수 없음
  2. 이런 문제를 보안하기 위해서 <color blue>최초에 수행될 때 적용되었던 값을 이용해 실행계획을 수립하고, 다음 수행부터는 공유하는 방법</color>을 이용한다.
  3. 마치 커닝과 유사한 개념
  4. 그냥 변수인 채로 실행계획을 수립하는 것보다는 유리할 수 있는 판단에서 나온 궁여지책
  5. 실제 적용상의 입장에서 보면 상당히 중요한 의미를 가짐

비용 산정기

  1. 옵티마이져의 비용산정은 크게 선택도(selectivity), 카디널러티(Cardinality),비용(Cost) 3가지로 측정한다.

선택도(Selectivity)

  1. <color blue>처리할 대상 집합에서 해당 조건을 만족하는 로우가 차지하는 비율</color>
  2. 선택도는 <color red>0.0 ~ 1.0</color> 값을 갖도록 생성된다.
    1. 0.0 : 대상 집합에서 전혀 존재하는 않음
    2. 1.0 : 모든 대상 집합이 모두 해당
    3. 컬럼에 있는 값의 종류가 10가지라면 선택도는 0.1(=1/10) 이다.

선택도의 값이 낮게 측정되었다 → <color blue>전체적으로 차지하는 비율이 낮다</color> → <color orange>변별력이 좋다</color> → <color red>좋은 선택도를 가진 것을 처리주관으로 결정하면 보다 적은 처리범위를 액세스 할 수 있다</color>

카디널러티(Cardinality)

  1. 실행계획에서 <color blue>Card</color>로 표시된 부분
  2. 판정 대상이 가진 결과 건수 혹은 다음 단계로 들어가는 중간결과건수 의미
  3. <color blue>선택도(Selectivity)</color> X <color red>전체 로우수(Num_rows)</color>
  4. 선택도가 있음에도 불구하고 카디널러티가 필요한 이유는 선택도는 단지 비율에 지나지 않기 때문이다
    1. 선택도는 단지 비율일 뿐임. 백만 건의 1%와 백 건의 1%는 비율은 같지만 절대량은 같지 않다.

비용(Cost)

  1. 실행계획에서 <color blue>Cost</color>로 표시된 부분
  2. 실행계획 상의 각 연산들을 수행할 때 소요되는 시간비용을 상대적으로 계산한 예측치
  3. 통계정보에 CPU와 메모리 상황, 디스크 I/O비용도 고려하여 계산

동일한 평가결과에서 우선순위 결정

규칙기준 로우 캐시(Row Cache)에 나타나는 순서대로 선택
비용기준 인덱스명의 ASCII 값에 근거해서 결정

신뢰성의 한계

  1. 비용산정 과정에서 수많은 가정들을 세우고 다양한 계산식을 적용
    그러나 가정들이 완벽할 수 없는 불완전한 가정이므로 때로는 잘못된 비용을 산정하게 되는 한계가 발생
  2. 이런 문제의 보완을 위해서 다양한 힌트들과 다양한 초기화 파라메터들이 계속 추가

실행계획 생성기

  1. 주어진 쿼리를 처리할 수 있는 적용 가능한 실행계획을 선별하고 비교검토를 거쳐 가장 최소의 비용을 가진 것을 선택
  2. 실행계획에 따른 처리되는 결과는 같다.
    1. 다양한 액세스 경로들의 조합
    2. 여러 유형의 조인 형태
    3. 조인 순서
  3. <color blue>그러나 실행계획에 따라 처리의 효율성은 엄청날 수 있다</color>

최적경로 탐색 기법

적응적 탐색
Adaptive search
* 쿼리수행의 총 예상수행시간에 대해 최적화를 하는 시간이 일정비율을 넘지 않도록 하는 탐색 전략
경험적 기법
Heuristic
* 탐색도중이더라도 최적이라고 판단되는 실행계획을 발견하면 더 이상 진행하지 않고 멈추는 것
* 최적이거나 최소한 아주 좋은 실행계획일 것이라고 판단되는 실행계획들의 일정량을 선별하고 정렬한 후에
그 중에서 가장 양호한 것을 선택
힌트
Hint
* 훨씬 기력이 높은 고수가 옆에서 훈수를 해주는 것과 같이 보다 쉽게 최적을 찾을 수 있다
<color blue> * 훈수는 결정적인 순간에만 하듯이 힌트는 특별한 경우에만 사용하는 것이 바람직함</color>
study/oracle/datadb/2week_1/chap3.txt · 마지막으로 수정됨: 2010/05/13 15:13 저자 starlits