Oracle Optimizer의 원리 이해 및 SQL & 애플리케이션의 튜닝(상):
옵티마이저의 원리와 특징
다수의 데이타베이스 튜닝과 SQL / 애플리케이션 튜닝을 통해 튜닝의 효과를 확신하는 필자가 유익한 튜닝 정보 를 제공한다.
여기에서 필자는 SQL 문장 개별 단위의 튜닝보다는 우선 옵티마이저의 원리를 이해하고, 전체 구조적인 문제, 유형문제 또한 옵티마이저 관련 파라미터의 설정이 먼저 최적으로 설정된 상황하에서 SQL 문 장의 단위 플랜에 대한 튜닝이 이루어져야 한다고 강조한다. 그런 취지에서 이 글에서는 옵티마이저의 원리에대한 이해를 기반으로 SQL 및 애플리케이션 튜닝에 필요한 기본지식을 개발자와 DBA가 쉽게 이해 할 수 있도록 2회에 걸쳐 소개할 예정 이다.
옵티마이저의 질의 처리 단계에 대한 이해
오라클에서 사용하는 옵티마이저(Optimizer)는 크게 RBO(Rule Base Optimizer)와 CBO(Cost Base Optimizer) 2개로 구분된다. 1992년 Oracle 7에서 처음 CBO가 지원된 이래 새로운 기능들이 적용되면서 CBO가 계속 향상되고 있는 데 반해, RBO는 오라클이 더 이상은 추구하지 않는 옵티마이저로서, 현재의 Oracle Database 10g에서도 명맥은 남아 있지만 향후는 더 이상 지원되지 않을 것이다.
옵티마이저의 질의 처리 단계에 대한 이해
오라클에서 사용하는 옵티마이저(Optimizer)는 크게 RBO(Rule Base Optimizer)와 CBO(Cost Base Optimizer) 2개로 구분된다. 1992년 Oracle 7에서 처음 CBO가 지원된 이래 새로운 기능들이 적용되면서 CBO가 계속 향상되고 있는 데 반해, RBO는 오라클이 더 이상은 추구하지 않는 옵티마이저로서, 현재의 Oracle Database 10g에서도 명맥은 남아 있지만 향후는 더 이상 지원되지 않을 것이다.
옵티마이저의 입장에서 질의(query) 처리는 5단계로 나눌 수 있는데, 옵티마이저는 서브질의와 뷰의 병합(merge) 등을 수행하는‘Query Rewrite’단계와‘Query Optimization’단계에 참여한다. 여기서 옵티마 이저는 ▲ 데이타를 어떠한 방법으로 액세스할 것이며 ▲ 올바른 결과를 어떻게 제공할 것이며 ▲ 데이타를 얼마나 효과적으로 액세스할 것인가를 결정한다. ‘QEP Generation’단계는‘Query Optimization’단계에서 제공된 정보를 이용해서 질의에 대한 최적의 실행계획(execution plan)을 만들어 내는 단계이다. CBO에서는 질의 실행계획(QEP)을 구하기 위하 여RBO보다 복잡한 단계를 거치게 된다<그림 1>, <표 1>.
소프트 파싱과 하드 파싱
SQL 문장이 옵티마이저에 의해 처리되고 그 결과물로서, SQL 문장이 어 떻게 실행될 것인지의 정보, 즉, QEP가 생기게 된다. 이들 정보는 한번 쓰 고 버리는 것이 아니라 오라클의 캐쉬(cache) 영역인 SGA의 공유 풀 (shared pool)에 이들 모든 정보를 캐쉬화해 관리한다. 다음 번에 같은 SQL 문장이 사용자에 의해서 실행되면, 이를 재활용하게 된다.
SQL 문장이 실행되면, 우선 SQL 문장 텍스트의 스트링을 해쉬 함수을 통과시켜 결과 값에 해당되는 버킷(어레이형 구조)에 매달린 체인 정보에서 같은 SQL 문장이 존재하는지 찾는 처 리절차를 수행하게 된다. 또한 같은 SQL 문장을 찾았어도 여러 버전이 존재할 수 있다. 여러 버전이란, 같은 SQL 문장(대/소문자, 화이트 스페이스 등이 모두 같아야 함)이지만 서로 다른 스키마의 테이블(예, scott의 emp, sys의 emp)이거나, 바인드 변수 를 사용한 경우는 바인드 변수의 타입, 길이 등에 의해서도 서로 다른 버전이 된다는 것이다. 이와 같이 같은 SQL 문장에 같은 버전을 찾았다면 이를 ‘소프트 파싱(soft parsing)’이라고 한다.
그렇지만, 체인을 다 찾았는데 같은 문장을 발견하지 못했다면, 해당 SQL 문장이 Parsing/Optimizing 단계를 거친 결과로 나온 정보를 저장하 기 위해 공유 풀로부터 메모리를 확보 받고, 기록한 정보를 체인에 매달게 된다. 이를‘하드 파싱(hard parsing)’이라고 한다. 당연히 하드 파싱의 작 업량이 소프트 파싱의 작업량에 비해 월등히 클 것이다<그림 2>.
이와 같은 소프트 파싱과 하드 파싱의 과정을 생각해 볼 때, 집중적인 SQL 문장이 실행되는 OLTP(초당 수천 ~ 수만 개 이상)에서 하드 파싱이 많다면 어떻게 될까? 한정된 메모리인 캐쉬에 새로운 메모리를 계속 할당 하고, LRU 알고리즘에 의해 제거하고, 체인에 매달고 끊는 등의 일들을 반 복해야 할 것이다. 또한 하드 파싱은 복잡한 처리과정을 거치므로 많은 자 원(CPU)을 사용하게 된다. 그러므로 OLTP 환경에서는 이와 같은 하드 파 싱을 가능한 줄이도록 해야 한다. 특히 SQL 실행 규모가 큰 OLTP 업무는 1% 미만을 권장한다.
애플리케이션을 개발할 때 이러한 하드 파싱을 줄이기 위한 방법으로 거의 대부분의 데이타베이스 접속 방식(JDBC, ODBC, ADO, PRO*C 등) 에서 자주 사용되는 SQL 문장들은 바인드 변수 기법들을 사용하여 개발하 는 방법들을 제공하고 있다. 또한 일부에서는 소프트 파싱 자체도 줄일 수 있는 기법들을 제공하고 있다. 실제 이러한 기법을 적용해서 튜닝한 결과, 시스템 CPU/메모리 측면에서 40~50% 이상 개선된 사례가 많이 있다. 혹 시 현재 운영중인 시스템이 사용자가 많아지면서CPU 리소스가 급격히 증 가해, 라이브러리 캐쉬, 공유 풀 경합 현상이 발생한다면, 이러한 점을 의심 해 볼 수 있다.
<표 4>는 SQL 문장을 바인드 변수를 사용한 공유 SQL과, 상수를 결 합한 형태로 SQL 문장을 만들어 실행시키는 비공유 SQL을 9,999회 실행 시켜 오라클의 공유 풀 메모리 사용현황과 파싱시CPU 사용시간을 테스트 한 것이다(단, 그 결과치는 실행 서버별로 차이가 있다).
결론적으로 보면, 비공유 SQL 방식의 사용 메모리와 CPU 사용률이 실행 규모에 비례해 증가하고, 실행된 SQL 문장이 기존에 캐쉬화되어 있 는 SQL 문장들을 밀어내는 역할을 한다는 것을 알 수 있다.
이와 같은 SQL 문장을 공유하기 위해서 오라클 입장에서 처리해주는 CURSOR_SHARING이라는 파라미터를 제공하기도 한다. 그러나, CURSOR_SHARING은 모든 상수를 다 바인드 변수로 바꿔버리기 때문에 개발자가 의도하지 않은 Literal까지도 바꾸게 되므로, 애플리케이션을 수 정할 수 있다면 가능한 애플리케이션 단에서 바인드 변수를 사용하는 것이 효과적이다.
하드 파싱을 줄이기 위해 모든 업무에 바인드 변수 사용방법을 적용하는 것은 잘못된 생각이다. 옵티마이저의 입장 에서 보면, 바인드 변수 기법 보다는 Literal을 사용한 비공유 SQL 방식을 좋아한다. Literal SQL 문장일 경우는 상수 값에 따라서 범위를 정확히 알 수 있기 때문에 효과적인 플랜 을 결정하는 주요 결정요소로 작용하기 때문이다. 즉 바인드 변수 기법은 옵티마이저의 판단에는 좋지 않지만 SQL 문장이 집중적으로 실행되는 OLTP 환경에서 하드 파싱의 비율을 줄이기 위한 방법인 것이다. 즉, 업무 의 특징에 따라서 다른 적용방식이 사용되어야 한다. 다음은 OLTP와DW 의 특징에 따라 다르게 고려되어야 할 사항이다.
• OLTP의특징
- 목표 : 신속한응답시간, 적은 데이타 처리량
- 파싱 타임을 최소화하고 SQL 등이 공유될 수 있도록 바인드 변수를 사용해야한다.
- 인덱스의 사용률이 높아야 한다.
- 정렬(sorting)을 최소화해야 한다.
- Nested Loop Join(FIRST_ROWS_n) 방식으로 많이 유도한다.
• DW의특징
- 목표 : 최고의 처리량, 방대한 데이타 처리량
- 인덱스의 참조는 중요한 사항이 아니다.
- 정렬 또는 Aggregate함수 등이 중요한 역할을 한다.
- Hash Join 등을 많이 사용하도록 유도한다.
- 파싱 타임 등은 그리 중요하지 않으며, 바인드 변수의 사용이 문제가 될 수 있다. - 병렬 질의 등의 사용률을 높인다.
Rule Base Optimizer
질의 최적화(query optimization)에서 RBO(Rule Base Optimizer)는 정해진 랭킹(ranking)에 의해 플랜을 결정한다. 같은 랭킹이라면 Where 절의 뒤부터, From절 뒤의 객체가 우선 순위를 갖는다. 한 객체(예 : 테이 블)에서 같은 랭킹의 인덱스가 있다면 가장 최근에 만들어진 인덱스를 사 용한다. 이는 CBO(Cost Base Optimizer)에서도 같이 적용되는 사항이다.
다분히RBO는 개발자들이 프로그래밍 단계에서 SQL 문장 구조의 인위적 인 조정 등으로 인덱스를 사용 못하게 하는 등 개발자가 코딩에 신경을 많 이 써야 하는 문제점이 있다. 또한RBO는 해당 질의에 대한 테이블의 인덱 스가 존재한다면 전체 90% 이상의 대상이어도 인덱스를 선택한다는 것이 다. 즉, RBO는 무조건 다음과 같은 미리 정해진 룰을 기준으로 플랜을 결 정하게 된다. 1992년 Oracle 7에서 CBO가 지원되면서 CBO는 계속적인 신기능의 적용으로 발전해 온 반면, RBO는 더 이상의 기능 향상은 없으며, 향후는CBO만 지원될 계획이다. 그러므로RBO에 더 이상의 미련을 갖지 말기 바라며, CBO의 훌륭한 기능들을 적극 활용하길 바란다.
다음은RBO의 랭킹을 정리한 것이다.
Path 1 : Single Row by Rowid
Path 2 : Single Row by Cluster Join
Path 3 : Single Row by Hash Cluster Key with Unique or Primary Key
Path 4 : Single Row by Unique or Primary Key
Path 5 : Clustered Join
Path 6 : Hash Cluster Key
Path 7 : Indexed Cluster Key
Path 8 : Composite Index
Path 9 : Single-Column Indexes
Path 10 : Bounded Range Search on Indexed Columns
Path 11 : Unbounded Range Search on Indexed Columns
Path 12 : Sort-Merge Join
Path 13 : MAX or MIN of Indexed Column
Path 14 : ORDER BY on Indexed Column
Path 15 : Full Table Scan
특히 Path 8, 9, 10에 주의를 해야 한다. 예를 들면, ‘emp’테이블에 ‘A’인덱스가“deptno”로 구성되어 있고, ‘B’인덱스가“deptno + empno”로 구성되어 있다면, 다음과 같은 SQL 문장은‘A’인덱스를 사용 하게 된다. 조건이 Bounded Range Search(Between)로 왔기 때문에 아래의 SQL 문장에서 (A)와 (B)의 랭킹은 (A) ==> Rank 9 , (B) ==> Rank 10 조건이 되므로 싱글 칼럼 인덱스를 사용한다는 것이다.
그러면, 이제CBO에 대해 살펴보기 전에, 참고로RBO를CBO로 전환 한 사례를 잠깐 소개하겠다.
현재RBO를 사용하고 있는 상황에서 마이그래이션시CBO로 전환하 고 싶으나, 막연히 두려운 부분도 많을 것이다. 실제 RBO에서 CBO로 전 환하고 나서 가장 효과를 보는 부분은 배치 잡 형태이다. 특히 Oracle9i Database 이상의 WORKAREA_SIZE_POLICY=AUTO로 운영하는 곳 이라면 더욱 더 그럴 것이다. 그러나 OLTP의 변화는 조심해야 한다. 아래 의 경우는, 이전하면서 옵티마이저 모드를RBO에서CBO로 전환한 것 뿐 만 아니라, 블록 사이즈와 CBO 옵티마이저에 민감한 db_file_multi block_read_count 값도 크게 늘렸다. 특히 WORKAREA_SIZE_ POLICY=AUTO로 필요한 워킹 메모리(Sort, Hash, Bitmap 등)를 옵티마 이저가 판단하에 가능한 충분히 사용하게 하는 방식을 사용하였다.
그러다 보니, CBO에 영향을 주는 소트 메모리와 해쉬 메모리가 풍부 하게 되었고, 블록 사이즈도 커졌으며, 풀 테이블 스캔의 정도를 결정하는 db_file_multiblock_read_count 값도 아주 커진 상태이다. 또한 마이그 래이션되면서 데이타가 재정리되어 있는 상태이므로, 풀 테이블 스캔과 Sort Merge Join, Hash Join의 경향이 커진 상태이다. 그러므로 배치 잡의 경우는 최적의 조건이 되었으나, 기존에 주로 Nested Loop Join을 선호하 던 RBO 환경의 OLTP들은 많은 플랜의 변화에 직면하게 된다. 그러면 이 러한 부분을 어떻게 보정해 줄 것인가? optimizer_index_caching, optimizer_index_cost_adj의 파라미터가 그 해답일 것이다. 가능한 Nested Loop Join를 선호하고, CBO의 옵티마이저 모드가 인덱스에 점수 를 더 주어서 인덱스의 비중을 키울 수가 있는 것이다. 물론 이러한 전환형 태 말고 옵티마이저 모드를FIRST_ROWS_n으로 운영하거나, 아웃라인을 이용하는 방법 등도 있을 것이다. 여러 방법이 있겠지만, 필자는 아래와 같 은 방법을 선호한다.
다음은 마이그래이션시RBO에서CBO로 전환한 사례이다.
Cost Base Optimizer
질의 최적화에서 CBO(Cost Base Optimizer)는해당SQL 문장이 참조하 고 있는 객체들(테이블, 인덱스 등)에 대한 수집된 통계정보(statistics)의 값과 데이타베이스 파라미터(init.ora) 설정 값을 기초로 가장 적은 비용 (cost)이 발생되는 플랜을 결정하는 옵티마이저 방식이다.
여기서 중요한 사실은 RBO에서는 전혀 사용되지 않았던 통계정보를 CBO에서는 이용한다는 것이다. 이들 통계정보는 DBA에 의해서 또는 자 동 수집 기능(Oracle9i Database Release 2, Oracle Database10g)에 의 해 객체들의 통계정보를 관리하는 시스템 딕셔널리(Dictionary)에 저장되 고, 이 정보를CBO 옵티마이저가 이용하는 것이다. 이들 정보는 SQL 문장 을 실행하는 데 얼마만큼의 I/O 횟수가 발생할 것인가를 계산하기 위한 각 종 데이타를 가지고 있다. 여기서 중요한 사실은 I/O 크기는 중요하지 않 으며 I/O 횟수가 중요하다는 것이다. 즉, CBO 옵티마이저는 SQL 문장에 대한 여러 가지 경우의 수별로 I/O의 횟수에 비례한 비용을 산출해내고, 이들 비용에서 가장 작은 비용을 갖는 플랜을 결정한다는 것이다. 즉, 비용 은 I/O 횟수에 비례하는 값이라고 보면 쉬울 것이다.
그러나, Oracle Database 10g부터는 비용의 단위 기준이 I/O에서 처리시간으로 바뀌었다(time base). 또한 Oracle9i Database부터 시스템 통계정보(CPU, 디스크 액세스 타임)를 이용해서 I/O로 환산한 방식을 제공 하였으나, 이것은 단지 옵션이었다. 그러나, Oracle Database 10g부터는 시스템 통계정보(CPU, 디스크 액세스 타임)를 이용해서 처리시간으로 환산한 방식을 디폴트로 사용하므로 상당히 정확한 플랜을 만들어내며, 실행 예측 시간도 상당히 정확하다.
그러면, 여기서 잠깐CBO에서 사용되는 통계정보가 저장된 Dictinary 정보 예를 참고로 살펴보자.
[USER|ALL|DBA]_TABLES : Table의 통계정보
NUM_ROWS,BLOCKS,AVG_ROW_LEN,SAMPLE_SIZE,LAST_ANALYZED
[USER|ALL|DBA]_INDEXES : Index의 통계정보
BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,AVG_LEAF_BLOCKS_PER_KEY,
AVG_DATA_BLOCKS_PER_KEY,CLUSTERING_FACTOR,NUM_ROWS,SAMPLE_SIZE,
LAST_ANALYZED
[USER|ALL|DBA]_TAB_COLUMNS : Column의 통계정보
NUM_DISTINCT,LOW_VALUE,HIGH_VALUE,DENSITY,NUM_NULLS,NUM_BUCKETS,
LAST_ANALYZED,SAMPLE_SIZE,AVG_COL_LEN
[USER|ALL|DBA]_TAB_HISTOGRAMS : Column의Data 분포도 정보
TABLE_NAME,COLUMN_NAME,ENDPOINT_NUMBER,ENDPOINT_VALUE,
ENDPOINT_ACTUAL_VALUE
기타 파티션 / 클러스터 등에 대한 통계정보
그러면“select * from dept where deptno = 10”과 같은 SQL 문장을 실행해야 한다고 가정하자. 여기서 dept Table은 deptno에 대한 인덱스가 있고, 테이블은 전체 10 블록으로 구성되어 있으며, 풀 테이블 스캔일 경우 I/O 단위를 결정하는 파라미터는 DBA가 db_file_multiblock_read_count=8로 지정하여 운영하고 있다고 가정하자 . 여기서RBO라면 무조건 인덱스를 타는 플랜을 결정하였을 것이다.
그러나, CBO의 경우는 deptno의 인덱스를 이용해 실행하면, 3회(인덱스는 싱글 블록 단위 I/O)의 I/O가 발생한다 고 가정하고, 풀 테이블 스캔의 경우는 2회(8블록 + 2블록)의 I/O가 발생한다고 가정하면, CBO에서 는 인덱스가 있음에도 I/O 횟수 측면에서 더 효과적인 풀 테이블 스캔을 선택한다는 것이다. 그러므로 CBO는 이와 같이 가능한 정확한(현실 데이 타와 맞는) 통계정보와 적절한 데이타베이스의 파라미터인 init.ora에의해 플랜이 결정되는 것이다.
CBO에서만 가능한 기능들
CBO는 오라클의 신기능을 지원하도록 지속적으로 발전하고 있으며, 다음의 경우는 반드시 CBO에서만 플랜 결정 시 검토되거나 무조건 CBO로 동작되는 경우이다. 예를 들어, 파티션 테이블을 사용한다면 통계정보가 없더라도 무조건CBO로 동작된다는 것이다.
• Partitioned tables (*)
• Index-organized tables
• Reverse key indexes
• Function-based indexes
• SAMPLE clauses in a SELECT statement (*)
• Parallel execution and parallel DML
• Star transformations
• Star joins
• Extensible optimizer
• Query rewrite (materialized views)
• Progress meter
• Hash joins
• Bitmap indexes
• Partition views (release 7.3)
• Hint (*)
• Parallel DEGREE & INSTANCES - ‘DEFAULT’도 해당 (*)
CBO의 옵티마이저에 영향을 줄 수 있는 파라미터 예
옵티마이저가 플랜을 수립하는 데 영향을 줄 수 있는 파라미터 값이 무엇인 지를 알고 있는 것이 무엇보다 중요하다. 실제 옵티마이저가 참조하는 파라 미터는 Oracle9i Database 기준으로 보더라도 60여 개에 이른다. 특히 DBA는 이들 옵티마이저의 파라미터 설정에 신중해야 한다. 또한 이들 파라 미터의 효과적인 설정은 개발 중이거나, 마이그래이션 중에 업무의 특징을 판단한 다음, 해당 업무에 가장 효과적인 것을 설정해야 한다. 기준이 잘못되 면 개발자들은 SQL 문장마다 힌트를 넣기 바쁠 것이고, 많은 인적 자원을 튜 닝에 소모해야 할 것이다. 그러므로 대부분의 업무들이 최적화되어 잘 운영 될 수 있는 형태로 이들 파라미터를 바꿔가면서 기준을 정하는 것이 중요하 다. 물론 이들 값보다도CBO에서 사용되는 통계정보가 중요하다는 것은 당 연한 사실이다. 오라클에서는 개발장비에도 운영장비에 있는 통계정보와 같 게 운영할 수 있도록 DBMS_STATS 패키지를 제공한다.
다음은 질의 수행시 옵티마이저가 플랜을 수립하기 위해 참조한 파라 미터 중 일부이다(버전마다 다르다).
OPTIMIZER_PERCENT_PARALLEL (Default = 0)
Optimizer_Percent_Parallel의 Parameter는 CBO가 비용을 계산하는 데 영향을 주는 파라미터이다. 즉 수치가 높을수록 병렬성을 이용하여 풀 테이블 스캔으로 테이블을 액세스하려고 한다. 이 값이 0인 경우는 최적의 시리얼 플 랜이나 패러렐 플랜을 사용하며, 1~100일 경우는 비용 계산에서 객체의 등급 을 사용한다.
OPTIMIZER_MODE (Default=Choose(Oracle7 ~ Oracle9i
Database),ALL_ROWS)
{Choose(<=9i)|Rule(<=9i)|First_rows|First_rows_n(> =Oracle9i)|All_rows}
기본적인 옵티마이저 모드를 결정한다(왼쪽상자기사‘옵티마이저 모드의 종류 및 특징’참조).
HASH_AREA_SIZE, HASH_JOIN_ENABLED (Oracle Database 10g : _ hash_join_enabled=true)
위의 파라미터 값에 따라서 Hash Join으로유도할수있다. Hash Join이가능 하고 해쉬 메모리가 충분하다면, 플랜에 Hash Join의 경향이 커진다.
OPTIMIZER_SEARCH_LIMIT (Default = 5)
옵티마이저에게 조인 비용을 계산할 경우, From절에 나오는 테이블의 개수에 따라서 조인의 경우의 수가 있을 수 있으며, 옵티마이저는 이들 각각의 경우의 수에 대한 조인 비용을 계산하게 된다. 물론 일부 예외사항은 있다. 예를 들어, Cartesian Production Join 등은 우선 순위가 낮으므로 뒤로 미뤄질 것이다. 이 파라미터의 값이 5일 경우 From절에 5개의 테이블에 대해서 모든 조인의 경우의 수를 가지고 비용을 계산하게 되며, 그 개수는 5!=120개의 경우의 수 에 대한 조인 비용을 계산하게 되므로 옵티마이저가 많은 시간을 소모하게 되 므로 성능에 영향을 미칠 수도 있다.
SORT_AREA_SIZE , SORT_MULTIBLOCK_READ_COUNT
위의 파라미터의 값에 따라서 Sort Merge Join으로 유도할 수 있다. 소트 메모 리가 충분하다면, 플랜에 Sort Merge Join의 경향이 커진다.
DB_FILE_MULTIBLOCK_READ_COUNT
이 파라미터의 수치가 클수록 인덱스 스캔보다는 풀 테이블 스캔의 비중이 높 아진다. 이 파라미터는 옵티마이저의 플랜 결정에 민감하게 영향을 주는 값이 다. 즉, 이 값이 커지면 풀 테이블 스캔과 병행해서 Sort Merge Join 또는 Hash Join의 경향이 커진다.
OPTIMIZER_INDEX_CACHING (Default = 0)
CBO가 Nested Loop Join을 선호하도록 조절하는 파라미터, Nested Loop Join시 버퍼 캐쉬 내에 이너 테이블의 인덱스를 캐쉬화하는 비율(%)을 지정하 므로 Nested Loop Join시 성능이 향상되며, 옵티마이저는 비용 계산시 이 비 율을 반영하여 Nested Loop Join을 선호하도록 플랜이 선택된다(0~100). 100에 근접할수록 인덱스 액세스 경로가 결정될 가능성이 높다. 기존의 RBO 를CBO로 전환시 옵티마이저를RBO 성향으로 보정하는 데 효과적이다.
OPTIMIZER_INDEX_COST_ADJ (Default = 100)
옵티마이저가 인덱스를 사용하는 위주의 플랜으로 풀릴 것인지 또는 가능한 사 용하지 않을 쪽으로 풀릴 것인지의 비중을 지정한다. CBO는RBO처럼 인덱스 를 사용하도록 플랜이 주로 만들어지게 되나, 인덱스가 있다고 해서RBO처럼 인덱스를 이용한 플랜으로 처리되는 것은 아니다. 인덱스를 이용하는 플랜 위 주로 하고자 한다면 100(%) 이하를, 가능한 인덱스를 사용하지 않고자 한다면 100 이상을 지정한다(1 ~ 10000). 이 파라미터는 기존의 RBO를 CBO로 전 환시 옵티마이저를RBO의 인덱스 위주 성향으로 보정하는 데 효과적이다.
WORKAREA_SIZE_POLICY (AUTO | MANUAL)
옵 티 마 이 저 가 [HASH|SORT|BITMAP_MERGE|CREATE_ BITMAP] *_AREA_SIZE를 자동으로 결정하는 PGA 자동 관리 방식으로, 인스턴스에 속한 모든PGA의 메모리의 합이PGA_AGGREGATE_TARGET에서 설정된 메모리를 가능한 넘지 않는 범위 내에서 Workarea(Sort, Hash, Bitmap 등)를 충분히 사용하고자 하는 방식이다. 플랜은 할당된 Workarea를 가지고 플랜을 결정하게 되므로 풍부한 메모리에 의해 Hash Join, Sort Merge Join등을 선 호하는 경향이 높다. 내부적으로 히든 파라미터로*_AREA_SIZE의값을가지 고 플랜을 결정할 수도 있으나 인위적인 설정 없이는 자동 할당된 메모리로 플 랜이 결정된다.
OPTIMIZER_DYNAMIC_SAMPLING (Default = 1(Oracle9i Database), 2(Oracle Database 10g))
더 나은 플랜을 결정하기 위한 목적으로 더 정확한 Selectivity & Cardinality 를 구하기 위한 방법으로 0 ~ 10 레벨이 있으며, 레벨이 높을수록 SQL 문장의 실행 시점에 통계정보를 만들기 위해 테이블의 데이타를 샘플링하기 위한 추가 적인 Recursive SQL이 발생된다. DYNAMIC_SAMPLING(0 ~ 10) 힌트를 통해서도 같은 기능을 할 수 있다. 그러나 내부적으로 추가적인 테이블 액세스 의 비용이 발생하므로OLTP에서는 주로 사용하지 않는다. 특히OLTP 환경에 서 레벨을 디폴트 값 이상 높여 놓지 않도록 한다. Oracle Database 10g의경 우 통계정보가 없다면‘다이나믹 샘플링’이 적용된다.
다음은 Oracle Database 10g의 플랜 및 다이나믹 샘플링의 예이다. 
옵티마이저 모드의 종류 및 특징
• 인 스 턴 스 레 벨 : optimizer_mode = {Choose|Rule|First_rows| First_rows_n| All_rows}
• 세션 레벨 : 인스턴스 레벨에 우선
ALTER SESSION SET optimizer_mode =
{Choose|Rule|First_rows|First_rows_n|All_rows}
• 스테이트먼트 레벨 : 힌트를 사용하며, 인스턴스, 세션 레벨에 우선
• Oracle9i Database에서 FIRST_ROWS_n 옵티마이저 모드가 추가되었음(N : 1, 10, 100, 1000).
• Oracle Database 10g에서는CHOOSE, RULE 모드는 더 이상 지원되지 않으나, 기능은남아있다.
• OPTIMIZER_MODE=CHOOSE 일경우
통계정보가 없다면 기본적으로RBO로 플랜이 결정된다. 그러나, ‘RULE’, ‘DRIVING_SITE’힌트 이외의 힌트가 왔다면CBO로 결정된다(힌트는 룰 의 규정을 깨므로CBO로 동작됨).
• Parallel Degree, Partition Table, SAMPLE절등이있으면무조건CBO
• OPTIMIZER_MODE=First_rows|First_rows_n|All_rows일경우통계 정보의 존재 여부와 관계 없이 무조건CBO로 처리하려고 함.
통계정보가 없다면 Heuristics Value를 이용하거나, Oracle9i Database 이상일 경우는 다이나믹 샘플링의 레벨에 따라 테이블의 데이타를 샘플링 해서CBO로 플랜이 결정된다. 그러나, 플랜이 비효율적일 수 있다.
• 통계정보가 있으나 옵티마이저 모드가 RULE일 경우, 다른 힌트가 오지 않 은 경우와 Parallel Degree, Partition Table, SAMPLE절 등이 나오지 않 은경우는RBO로 처리된다.
CBO를 위한 통계정보 운영 방법
통계정보는 CBO의 플랜 결정에 사용되는 객체들의 물리적인 구성정보를 나타낸다. 즉, 테이블이 몇 블록으로 구성되어 있으며, 몇 건의 로우들을 가지고 있으며, 평균 로우 길이는 어느 정 도이며, 칼럼의 Min/Max 값의 분포, Distinct 값, 인덱스의 레벨, 키(key)당 Leaf Block 수 등의 정보들을 나타낸다. 이들 정보는 CBO의 플랜 결정의 기초 자료로 사용된다. 이들 통계정보를 생성하기 위해서는 ANALYZE 명령어를 이용하거나 DBMS_STATS 패키지를 이용하면 된다. 그러나 2개의 차이점에 주의해야 하며, DBMS_STATS를 지원하는 Oracle8i Database 이상부터는 DBMS_STATS를 사용하기를 권장하고 있다.
Analyze 명령어와DBMS_STATS의 차이점
● Analyze는 파티션의 통계정보를 각 파티션 테이블과 인덱스에 대해서 수집하 고, Global Statistics는 파티션 정보를 가지고 계산하므로, 비정확할 수 있다. 그러므로 파티션 또는 서브파티션이 있는 객체에는DBMS_STATS을 사용하 여야 한다.
● DBMS_STATS은 전체 클러스터에 대해서는 통계정보를 수집하지 않는다. 그 러므로 Analyze를 사용한다.
● DBMS_STATS은 CBO와 관련된 통계정보만을 수집한다. 즉, 테이블의 EMPTY_BLOCKS, AVG_SPACE,CHAIN_CNT 등은 수집되지 않는다.
● DBMS_STATS은 사용자가 지정한 통계정보 테이블에 수집된 통계정보를 저 장할수있고, 딕셔너리로 각 칼럼, 테이블, 인덱스, 스키마등을반영할수있다.
● DBMS_STATS은IMPORT/EXPORT 기능 및 추가적인 기능이 많다. 이기능 을 이용하여 운영 DB의 통계정보를 개발장비의 통계정보로 복사할 수 있으므로 개발장비의 플랜을 운영장비와 같 게 만들 수 있다(매뉴얼 참조).
다음은 Analyze 명령어에만 있는 기능이다.
analyze { index/table/cluster } (schema.){ index/table/cluster } validate structure (cascade) (into schema.table);
• Chained Rows 수집 기능
ANALYZE TABLE order_hist LIST CHAINED ROWS INTO
시스템 통계정보 (>= Oracle9i Database)
시스템 통계정보는 객체의 통계정보와 같이 사용되는 정보로서, 기존의 Oracle8i Database까지의 I/O 중심의 플랜 방식에 CPU와 디스크 I/O 속 도와 같은 시스템 자원의 효율을 반영하여 보다 효율적인 플랜을 결정하기 위한 방법으로, Oracle9i Database에서 처음 소개되었으며, 옵션 기능으로 DBA에 의해 사용될 수도 있고 사용하지 않을 수도 있었다. Oracle Database 10g에서는 시스템 통계정보가 기본적으로 수집되고 사용된다. 그 러므로 기존의 I/O 횟수만 가지고 플랜을 결정하던 부분이 Oracle Database 10g에서는 시스템의 자원의 성능도 고려되어 보다 정확한 플랜을 결정할 수 있게 되었다.
이들 시스템 통계정보는 DBMS_STATS 패키지를 이용해서 수집된다.
Oracle Database 10g에서는 기본적으로 수집되는 값들이 있으며, 또한 사용자가 수집해야 하는 항목도 있다. 다음은 Oracle Database 10g의 시 스템 통계정보의 수집형태를 보여주고 있다.
옵티마이저 원리에 바탕한 SQL 튜닝
지금까지 설명한 바와 같이 개략적으로나마 옵티마이저의 원리를 이해하기 위한 부분에 초점을 맞춰 설명하였다. 더 자세한 부분이 필요하면 오라클 매뉴얼인 [Database Performance Tuning Guide and Reference]를 권장하고 싶다. 다음 호엔 오라클이 사용하는 조인 방법들와 오라클이 제공하는 SQL 튜닝 방법에 대해 알아보도록 하자.