행위

옵티마이져

DB CAFE

thumb_up 추천메뉴 바로가기


1 오라클 옵티마이져[편집]

  • 옵티마이져는 단순한 SQL이 아니라면 모든 실행 계획들을 평가하지 않는다.
  • 휴리스틱 선택을 기반으로 가장 유리한 실행 계획 부터 시작 하여 다른 실행 계획을 평가하는데 가장 좋은비용의 실행 계획을 찾거나 대안 실행 계획이 너무 많다고 판단될 경우 평가를 종료한다.

1.1 옵티마이져 비용 추정 요소[편집]

1.1.1 시스템 통계[편집]

  1. DB엔진이 실행되는 장비의 스토리지 의 성능 수치 저장
  2. V$SYSSTAT

1.1.2 오브젝트 통계[편집]

  1. 테이블,인덱스,컬럼 통계등의 데이터 딕셔너리 정보

1.1.3 제약 조건[편집]

  1. NOT NULL , Unique Key , Primary Key ,Foreign Key ,Check 제약 조건 등.
  2. 쿼리 변환 적용 여부와 타당성 평가시 핵심적인 역활 수행

1.1.4 물리 설계[편집]

  1. 힙 오거나이즈드 테이블 (일반 테이블)
  2. 인덱스 오거나이즈드 테이블 (IOT)
  3. 외부 테이블 (External Table)
  4. 인덱스 클러스터
  5. 해시 클러스터
  • 전략적으로 여러가지 엑세스 패스 사용됨

1.1.5 SQL 제어[편집]

  1. 스토어드 아웃라인
  2. SQL 프로파일
  3. SQL 플랜 베이스 라인

1.1.6 실행 환경[편집]

  1. 초기화 파라미터 (init.ora)
  2. 서버 파라미터 (spfile)

1.1.7 바인드 변수[편집]

  1. 바인드 변수 값
  2. 바인드 변수 데이터 타입

1.1.8 동적 샘플링[편집]

  1. 오브젝트 통계 정보 이외에 추가적인 통계요소를 동적으로 수집하여 평가

1.1.9 카디널리티 피드백[편집]

  1. 조건절이 복잡하거나 입력정보가 충분하지 않을 경우 정확한 추정이 불가함.
  2. SQL 구문에 대한 비용 추정이 품질에 좋지 않다고 판단되면 생성된 실행 계획에 특정한 표시를 하고 , SQL실행이 끝난후 추정이 얼마 였는지 정확히 확인한다.
  3. 이 SQL이 다시 실행시 강제로 재최적화가 이루어진다

1.2 아키텍처[편집]

ec8aa4ed81aceba6b0ec83b7-2023-11-28-ec98a4ed9b84-9.34.16.png

1.2.1 파서[편집]

  1. 파서 목적은 실행할 SQL구문을 파싱된 형태로 쿼리 옵티마이져에게 전달하는것

1.2.2 논리 옵티마이져[편집]

  1. 이단계에서 여러가지 쿼리 변환 기술을 이용하여 의미상 동일한 SQL 구문을 생성한다

1.2.3 물리 옵티마이져[편집]

  1. 각각 생성된 SQL구문에 대한 여러가지 실행 계획이 생성된다.
  2. 생성된 실행 계획을 비용추정기로 전달하여 비용을 게산한다
  3. 마지막으로 가장 낮은 비용의 실행 계획을 선택한다.

1.2.4 비용 추정기[편집]

  1. 여러가지 입력요소들을 기반으로 실행계획에 대한 비용을 계산한다.

1.2.5 로우 소스 생성기[편집]

  1. 쿼리 옵티마이져가 생성한 실행 계획을 실행 엔진이 바로 실행할수 없다
  2. 실행 계획은 로우 소스 오퍼레이션 트리로 변환 되어 라이브러리 캐시에 저장되어야 한다.

1.2.6 실행 엔진[편집]

  1. 로우 소스 생성기가 생성한 로우소스 오퍼레이션 실행
  2. 카디널리티 피드백을 위한 모니터링이 활성화 된 경우 , 실행엔진은 실행 후에 실제값과 추정값이 현저하게 차이나는지 확인하고 올바른값에 대한 정보가 공유SQL영역에 저장되고 다음 재수행시 다시 재최적화를 수행한다.