728x90
반응형
옵티마이저

 

옵티마이저(Optimizer)는 사용자가 질의한 SQL문에 대해 최적의 실행 방법을 결정하는 역할을 수행한다.

이러한 최적의 실행 방법을 실행계획(Execution Plan)이라고 한다.

관계형 데이터베이스는 궁극적으로 SQL문을 통해서만 데이터를 처리할 수 있다.

JAVA, C등과 같은 프로그램 언어와는 달리 SQL은 사용자의 요구사항만 기술할 뿐 처리과정에 대한 기술을 하지 않는다.

그러므로 사용자의 요구사항을 만족하는 결과를 추출 할 수 있는 다양한 실행 방법이 존재할 수 있다.

다양한 실행 방법들 중에서 최적의 실행 방법을 결정하는 것이 바로 옵티마이저의 역할이다.

관계형 데이터베이스는 옵티마이저가 결정한 실행 방법대로 실행 엔진이 데이터를 처리하여 결과 데이터를

사용자에게 전달할 뿐 이다. 옵티마이저가 선택한 실행 방법의 적절성 여부는 질의의 수행 속도에 가장 큰 영향을 미치게 된다. 이런 의미에서 관계형 데이터베이스에서 진정한 프로그래머는 옵티마이저라고 할 수 있다.

최적의 실행 방법 결정이라는 것은 어떤 방법으로 처리하는 것이 최소 일량으로 동일한 일을 처리할 수 있을 지 결정하는 것이다. 그러나 이러한 결정을 옵티마이저는 실제로 SQL문을 처리해보지 않은 상태에서 결정해야 하는 어려움이 있다.

옵티마이저가 최적의 실행 방법을 결정하는 방식에 따라 규칙기반 옵티마이저비용기반 옵티마이저로 구분할 수 있다.

현재 대부분의 관계형 데이터베이스는 비용기반 옵티마이저만을 제공한다.

비록 규칙기반 옵티마이저를 제공하더라도 신규 기능들에 대해서는 더 이상 지원하지 않는다.

다만 하위버전 호환성을 위해서만 규칙기반 옵티마이저가 남아 있을 뿐이다.

그렇지만 규칙기반 옵티마이저의 규칙은 보편 타당성에 근거한 것들이다.

이러한 규칙을 알고 있는 것은 옵티마이저의 최적화 작업을 이해하는데 도움이 된다.


규칙기반 옵티마이저

 

규칙기반 옵티마이저는 규칙(우선 순위)를 가지고 실행계획을 생성한다.

실행계획을 생성하는 규칙을 이해하면 누구나 실행계획을 비교적 쉽게 예측할 수 있다.

 

규칙기반 옵티마이저가 실행계획을 생성할 때 참조하는 정보에는

SQL문을 실행하기 위해서 이용 가능한

인덱스 유무와 (유일, 비유일, 단일, 복합 인덱스) 종류, 

SQL 문에서 사용하는 연산자 (=, <, <>, LIKE, BETWEEN 등)의 종류 그리고

SQL 문에서 참조하는 객체(힙, 테이블, 클러스터 테이블 등)의 종류 등이 있다.

 

이러한 정보에 따라 우선 순위(규칙)가 정해져 있고, 이 우선 순위를 기반으로 실행계획을 생성한다.

결과적으로 규칙기반 옵티마이저는 우선 순위가 높은 규칙이 적은 일량으로 해당 작업을 수행하는 방법이라고 판단하는 것이다. 옵티마이저의 15가지 규칙 중에 순위의 숫자가 낮을 수록 우선 순위이다.

 

 

Single row by rowid:

ROWID를 통해서 테이블에서 하나의 행을 액세스 하는 방식이다.

ROWID행이 포함된 데이터 파일, 블록 등의 정보를 가지고 있기 때문에 다른 정보를 참조하지 않고도

바로 원하는 행을 액세스 할 수 있다. 하나의 행을 액세스하는 가장 빠른 방법이다.

 

Single by unique or primary key:

유일 인덱스(Unique Index)를 통해서 하나의 행을 액세스하는 방식이다.

이 방식은 인덱스를 먼저 액세스하고 인덱스에 존재하는 ROWID를 추출하여 테이블의 행을 액세스한다.

 

Composite index:

복합 인덱스에 동등('=' 연산자) 조건으로 검색하는 경우이다.

 

Full table scan:

전체 테이블을 액세스하면서 조건절에 주어진 조건을 만족하는 행만을 결과로 추출한다.

 

규칙기반 옵티마이저인덱스를 이용한 액세스 방식전체 테이블 액세스 방식(Full table scan)보다 우선 순위가 높다.

따라서 규칙기반 옵티마이저는 해당 SQL문에서 이용 가능한 인덱스가 존재한다면 전체 테이블 액세스 방식보다

항상 인덱스를 사용하는 실행계획을 생성한다.

 

 

비용기반 옵티마이저

 

규칙기반 옵티마이저는 조건절에서 '=' 연산자와 'BETWEEN' 연산자가 사용되면 규칙에 따라

'=' 칼럼의 인덱스를 사용하는 것이 보다 적은 일량, 즉, 보다 적은 처리 범위로 작업을 할 것이라고 판단한다.

그러나 실제로는 'BETWEEN' 칼럼을 사용한 인덱스가 보다 일량이 적을 수 있다.

단순한 몇 개의 규칙만으로 현실의 모든 사항을 정확히 예측할 수 없다.

비용기반 옵티마이저는 이러한 규칙기반 옵티마이저의 단점을 극복하기 위해서 출현하였다.

 

비용기반 옵티마이저는 SQL문을 처리하는데 필요한 비용이 가장 적은 실행계획을 선택하는 방식이다.

여기서 비용이란 SQL문을 처리하기 위해 예상되는 소요시간 또는 자원사용량을 의미한다.

비용기반 옵티마이저는 비용을 예측하기 위해서 규칙기반 옵티마이저가 사용하지 않는 테이블, 인덱스, 칼럼 등의

다양한 객체 통계 정보와 시스템 통계정보 등을 이용한다. 통계 정보가 없는 경우 비용기반 옵티마이저는 정확한

비용 예측이 불가능해져 비효율적인 실행계획을 생성할 수 있다. 그렇기 때문에 정확한 통계정보를 유지하는 것은

비용기반 최적화에서 중요한 요소이다.

 

 

비용기반 옵티마이저는 질의변환기, 대안 계획 생성기, 비용 예측기 등의 모듈로 구성되어 있다.

앞에서 규칙기반 옵티마이저는 항상 인덱스를 사용할 수 있다면 전체 테이블 스캔보다는 인덱스를 사용하는 실행계획을

생성한다고 했다. 그렇지만 비용기반 옵티마이저는 인덱스를 사용하는 비용이 전체 테이블 스캔 비용보다 크다고 판단되면 전체 테이블 스캔을 수행하는 방법으로 실행계획을 생성할 수 있다.

 

비용기반 옵티마이저는 통계정보, DBMS 버전, DBMS 설정 정ㄹ보 등의 차이로 인해 동일 SQL문도 서로 다른 실행계획이

생성될 수 있다. 또한 비용기반 옵티마이저의 다양한 한계들로 인해 실행계획의 예측 및 제어가 어렵다는 단점이 있다.

 

 

실행계획

 

실행계획(Execution Plan)이란 SQL에서 요구한 사항을 처리하기 위한 절차와 방법을 의미한다.

실행계획을 생성한다는 것은 SQL을 어떤 순서로 어떻게 실행할지를 결정하는 작업이다.

옵티마이저는 다양한 처리 방법들 중에서 가장 효율적인 방법을 찾아준다. (최적의 실행계획 생성)

 

실행계획을 구성하는 요소에는

조인 순서(Join Order), 조인 기법(Join Method), 액세스 기법(Access Method),

최적화 정보(Optimization Information), 연산(Operation) 등이 있다.

 

 


Summary

 

옵티마이징 = 최적화

옵티마이저 = 옵티마이징을 수행하는 것 → 성능을 가장 유리한 방향으로 이끄는 역할 수행

즉, 최적의 실행방법, 실행계획(Execution Plan)을 구성

동일 SQL문에 대해 실행 계획이 달라도 쿼리의 실행 결과는 항상 같아야함.

 

실행 계획 구성 요소.

조인순서, 조인기법, 액세스 기법, 최적화 정보, 연산, 질의 처리 예상비용

 

규칙기반 우선순위

행에 대한 고유주소 액세스 방식(Single row by rowid) 인덱스를 이요한 엑세스 방식

이용가능한 인덱스가 있으면 항상 인덱스를 사용하는 규칙 계획 생성

 


비용 기반 옵티마이저

비용 (예상되는 소요시간, 자원사용량)이 가장 적은 실행계획을 선택하는 방식

-> 비용에 따라 full scan이 유리하다고 판단할 수도 있음.

 


 

# Ref:

 

 

옵티마이저와 실행계획

1. 옵티마이저 옵티마이저(Optimizer)는 사용자가 질의한 SQL문에 대해 최적의 실행 방법을 결정하는 역할을 수행한다. 이러한 최적의 실행 방법을 실행계획(Execution Plan)이라고 한다. 관계형 데이터

dataonair.or.kr

728x90
반응형

'Language > RDBMS' 카테고리의 다른 글

인덱스 기본  (0) 2023.03.19
조인 수행원리  (0) 2023.03.19
계층형 질의  (0) 2023.03.16
[SQLD]Prev-Exam Solving (30st)  (0) 2023.03.15
[SQLD]Prev-Exam Solving (21st)  (0) 2023.03.15

+ Recent posts