Science of Database

SQL 튜닝책을 세 권정도 읽은 신입사원이 SQL 튜닝방법론을 요청하였다. 이유는 튜닝책에 방법론이 없다는 것이다. 튜닝 방법론이란 “SQL을 튜닝 해달라고 요청 받았을 때 내가 무엇 무엇을 해야 하나?” 이다. 즉 SQL 튜닝시의 To-Do 리스트(체크리스트)를 요구한 것이다.

 

SQL 튜닝을 자주 하면서도, 그 안에 몇 가지 작업이 있는지 생각하지 못했다. 누가 그랬던가? 일상을 낯설게 느껴보라고… SQL 튜닝요청을 받았을 때 내가 어떤 일을 하는지 가르쳐 주면 되겠구나 하는 생각이 들었다. 그 결과 7가지 방법이 결론으로 도출되었다. 만약 7가지 방법을 모두 적용할 수 있는 경우임에도 불구하고 하나라도 빠진다면 최적화된 SQL을 만들 수 없다.

 

아래는 필자와 신입사원의 대화이다.

 

신입사원 : SQL 튜닝의 원칙 몇 가지를 저에게 일러 주실 수 있나요? 튜닝책도 몇 가지 보았고, 강의도 많이 들었지만 “이 원칙만 지키면 100점 만점에 90점은 맞는다.” 는 원칙 같은 것은 없더군요. 저는 이제 입문하는 단계이므로 모든 경우에 100점을 맞을 필요는 없습니다.

 

필자 : 온라인 SQL이냐 대용량 배치 SQL이냐에 따라 튜닝방법이 달라지므로 설명하기가 힘들군요.

 

신입사원 : 걱정 하실 것 없습니다. 대용량 배치는 프로그램이 많지 않으므로 제외하고, 온라인 SQL 튜닝 원칙을 몇 가지 일러주세요.

 

필자 : 온라인 SQL이라 하더라도 관점에 따라 튜닝방법이 다릅니다. 예를 들어 Peak Time에 Insert 문이나 Update 문, Select문이 집중적으로 몰릴 때의 튜닝방법이 있고, 단순히 SQL 하나에 에 집중해서 응답시간을 최소화 하는 튜닝방법이 있습니다.

 

신입사원 : 그런 것을 지금 모두 알아야 할 필요는 없습니다. 제가 튜닝 프로젝트에 투입되었다고 가정하고, 성능이 느린 Select문 하나를 받았을 때 튜닝을 어떻게 해야 하는지에 대해서만 설명해주시면 됩니다.

 

고단수 신입사원

이렇게 해서 신입사원에게 말려들게 되었다. 즉, 초보라도 몇 가지 원칙만 지키면 온라인 Select문에 대한 튜닝을 100점 만점에 90점을 맞을 수 있는 방법을 요구하는 것이다. 사실 이런 질문에 가장 적합한 답변은 “SQL 튜닝책을 읽어보라”는 것이다. 그런데 신입사원이 필자와 대화과정(튜닝책도 몇 가지 보았고 ~)에서 이런 답변을 못하도록 교묘히 막고 있다. 고단수이다. 몇 가지 방법만 알게 된다면 90점을 받는다고? 처음부터 그런 방법은 없다고 할 걸 그랬나? 후회가 된다. 어찌되었든 약속처럼 되어버렸으므로 이 글을 쓰게 되었다. 음…..머리가 아파온다.

 

온라인 Select문 튜닝 방법론

온라인 SQL의 튜닝방법은 여러 가지가 있을 수 있다. 하지만 그 중에서 가장 기초적이고, 기본적인 방법을 공개한다. 아래의 7가지 항목을 점검하고 약한 곳을 보강하면 된다. 이 글은 SQL 튜닝책을 두 권 정도 본 사람들을 위한 것이다. 튜닝에 자신있는 사람들은 볼 필요가 없다.

 

1. 적절한 인덱스를 사용하여 Block I/O를 최소화 하라

조인이 없는 경우는 적절한 인덱스를 사용하는 것 만으로도 상당한 효과를 볼 수 있다. 조인이 있는 경우는 특히 Driving(선행) 집합에 신경을 써야 한다. 왜냐하면 Nested Loop 조인을 사용했고, 선행집합의 건수가 많다면, 후행집합의 조인의 시도횟수가 증가하므로 성능이 느려진다. 따라서 적절한 인덱스를 이용하여 선행집합의 건수를 줄인다면, 혹은 가장 적은 집합을 선행으로 놓는다면, 후행집합으로의 조인건수는 줄어든다. 물론 이때에도 후행집합의 적절한 인덱스는 필수 조건이다. Driving 집합의 Block I/O를 줄이기 위하여 최적화된 인덱스가 없다면 생성하고, 있다면 그것을 사용하라. 다시 말해 최적의 Access Path를 만들어라.

 

운영중인 시스템이라면 최적의 Access Path를 위해 인덱스를 변경하거나 생성할 때는 주의해야 한다. 현재 튜닝하고 있는 SQL에 최적화된 인덱스를 생성하더라도 다른 SQL에 악영향을 줄 수 있기 때문이다. 인덱스를 생성하거나 변경할 때는 그 테이블을 사용하는 다른 SQL의 실행계획이 변경되지 않는지 각별히 신경을 써야 한다. 이런 이유 때문에 개발과정에서 효율적인 인덱스 설계가 중요시 된다.

 

2. 조인방법과 조인순서를 최적화 하라

온라인에서 사용하는 Select문은 좁은 범위를 검색하는 경우가 많다. 이럴 때는 대부분 Nested Loop Join이 유리하다. 그러므로 조인건수가 소량인 SQL에 Hash Join이나 Sort Merge Join이 발견되면 Nested Loop Join으로 변경하는 것이 더 유리한지 검토해야 한다. 물론 여기서도 Nested Loop 조인에 관해서만 다룬다.

 

Nested Loop 조인에서 가장 중요한 것은 조인순서이다. From절에 테이블(집합)이 두 개라면 후행집합의 관점에서는 적절한 인덱스만 존재한다면 그것으로 족하다. 만약 From절에 테이블(집합)이 세 개 이상이라면 조인순서를 변경할 수 있는지에 대한 두 가지 원리를 사용하라. 두 가지 원리는 아래의 단락에서 소개된다. 아무리 조인할 집합이 많다고 하더라도 이 두 가지의 원리는 동일하게 적용될 수 있다. 두 가지 원리를 이용할 때 필요하다면 Leading 힌트를 사용해야 한다.

 

첫 번째, 후행집합에 적절한 인덱스가 없는 경우에 조인순서를 바꾸면, 최적의 인덱스를 사용할 수 있는 경우가 많다. 예컨대, 튜닝전의 조인순서가 Aà B à C 라고 하면, 중간집합인 B에 적절한 인덱스가 없고 오히려 C에 적절한 인덱스가 존재하는 경우가 있다. 이럴 때는 B에 인덱스를 무작정 생성하지 말고, 조인순서를 A à C à B로 바꿀 수 있는지, 바꾸는 것이 더 효율적인지 검증하라. 조인순서만 바꾸어 주어도 일량이 획기적으로 줄어드는 경우가 많다. 만약 조인순서를 바꿀 수 없거나, C를 중간집합으로 하는 것이 비효율적이라면, B를 중간집합으로 유지하고 적절한 인덱스를 사용해야 한다.

 

두 번째, 조인되는 집합 중 특정 인덱스에서 Block I/O가 증가하는 경우에 조인순서의 변경을 검토하라. 이때 10046 Trace나 DBMS_XPLAN.Display_Corsor를 이용하면 조인집합들의 Block I/O량을 관찰할 수 있다. 예를 들어, 튜닝전의 조인순서가 Aà B à C 라고 하고, 집합 B에서 Block I/O량이 증가하면 A à C à B로 바꾸면 일량이 줄어드는 경우가 많다. C를 먼저 조인(Filter)하여 선행집합(B의 입장에서는 C가 선행이다)의 건수를 줄이고 B에 조인하면 성능이 향상된다.

 

3. Table Access(Random Access)를 최소화 하라

Random Access란 rowid로 테이블을 엑세스하는 것을 말한다. 1번과 2번을 최적화 했다면 Random Access도 자동으로 많이 줄어들었을 것이다. 하지만 그것이 끝은 아니다. 여전히 성능이 만족스럽지 못하다면 Random Access 횟수를 줄이는 것을 간과해서는 안 된다.

 

인덱스를 사용하면 rowid가 자동으로 획득된다. 만약 인덱스에 없는 컬럼을 Select 해야 한다면 rowid로 테이블을 엑세스 해야 한다. 이때 테이블로 엑세스 해야 할 건수가 많고, 인덱스의 컬럼순으로 테이블이 sort되어있지 않다면 성능이 매우 저하된다. 왜냐하면 테이블이 인덱스 기준으로 sort되어 있지 않기 때문에 테이블을 방문할 때마다 서로 다른 블럭을 읽어야 하기 때문이다.

 

비유적으로 설명해보자. 우리가 심부름을 할 때 세 군대의 상점(A,B,C)을 들러야 한다고 치자. 그 상점들이 모두 한 건물 내부에 존재한다면 얼마나 좋겠는가? 그 심부름은 매우 빠른 시간에 끝날 것이다. 하지만 반대로 상점 A는 부산에 있고 상점 B는 대구에 있고, 상점 C는 서울에 있다면? 만약 당신의 성격이 매우 좋아서 그 심부름을 한다고 해도 시간이 많이 걸릴 것이다. Random Access도 마찬가지이다. 인덱스의 rowid로 테이블을 방문할 때, 테이블이 인덱스기준으로 sort되어 상점처럼 다닥다닥 붙어있다면 성능은 매우 빠르고, 흩어져 있을수록 성능이 느려진다. (오라클에서는 테이블이 인덱스 기준으로 sort 되어 있는 정도를 Clustering Factor라고 한다.) 바로 이런 이유 때문에 index scan보다는 Table Scan이 느린 것이다. 따라서 우리는 Random Access의 부하를 최소화 해야 한다.

 

Random Access의 부하를 줄이는 방법은 네 가지이다. 첫 번째, 테이블의 종류를 변경하는 방법이다. IOT나 클러스터를 이용하면 Clustering Factor가 극단적으로 좋아진다. 또한 파티션을 이용하면 같은 범위의 데이터를 밀집시킬 수 있다. 두 번째, 효율적인 인덱스를 사용하거나 조인방법과 순서를 조정하여 Table Access를 최소화 하는 방법이다. 이 방법은 1번과 2번에서 이미 설명 되었다. 세 번째, 인덱스에 컬럼을 추가하여 Table Access를 방지하는 방법이다. 예를 들어 Select절의 특정 컬럼 때문에 테이블이 엑세스 된다면, 인덱스의 마지막에 그 컬럼을 추가하면 된다. 네 번째, 인덱스만 엑세스 하고 테이블로의 엑세스는 모든 조인을 끝내고 마지막에 시도하여 Random Access의 횟수를 줄이는 방법이다. 해당 글을 참조하라. 

 

4. Sort나 Hash 작업을 최소화 하라

1,2,3번을 통하여 최적의 Access Path와 Join을 사용했다면, Block I/O의 관점에서는 튜닝이 끝난 것이다. 하지만 1,2,3번이 모두 해결되었다 해도 Order by나 Group By 때문에 성능이 저하 될 수 있다. 특히 결과가 많은 경우, sort는 치명적이다.

 

인덱스가 sort 되어있다는 특성을 이용하면 order by 작업을 대신할 수 있다.  Group By도 sort 가 발생하는데 group by 단위와 인덱스의 컬럼이 동일 하다면 sort는 발생하지 않는다. 최적의 인덱스를 사용하면 Access Path를 개선하는 효과뿐만 아니라 Sort의 부하도 없어진다.

Union All을 제외한 집합연산(Union, Minus, Intersect)를 사용하면 Sort Unique 혹은 Hash Unique가 발생한다. Union은 Union All로 바꿀 수 없는지 검토해야 하고, Minus는 Not Exists 서브쿼리를 이용하여 Anti Join으로 바꿀 수 없는지 고려해야 한다. Intersect는 교집합이므로 조인으로 바꿀 수 있는지 검토해야 한다. 아주 가끔 Distinct를 사용한 SQL이 눈에 뛰는데 이 또한 Sort Unique 혹은 Hash Unique를 발생시킨다. 모델러나 설계자에게 문의하여 Distinct를 제거할 방법이 없는지 문의해야 한다.

 

Oracle 10g부터는 Hash Group By가 발생할 수 있는데, 이미 적절한 인덱스를 사용하는 경우라면 Hash Group By를 사용할 필요는 없다. 이런 경우 NO_USE_HASH_AGGREGATION 힌트를 사용하면 Sort Group By로 바꿀 수 있다. 이렇게 해주면 실행계획에 “SORT GROUP BY NOSORT” Operation이 발생하며, Sort나 Hashing 작업이 전혀 발생하지 않는다. Group By의 부하를 해결하는 또 하나의 방법은 스칼라 서브쿼리를 사용하는 것이다. 조인을 사용하면 Sum 값을 구하기 위해 Group By가 필수적이다. 하지만 스칼라 서브쿼리를 사용하면 Group By를 사용하지 않고도 sum 이나 Min/Max 값을 구할 수 있다. 또한 분석함수의 Ranking Family(rank, dens_rank, row_number)를 최적화된 인덱스와 같이 사용하면 Group By나 Sort를 하지 않고도 Min/Max 값을 구할 수 있다. 이때는 실행계획에 “WINDOW NOSORT” Operation이 발생한다. 관련 글을 참조하기 바란다.

 

5. 한 블록은 한번만 Scan하고 끝내라

같은 데이터를 반복적으로 Scan하는 SQL이 의외로 많다. 대표적인 경우가 Union All로 분리되었지만 실제로는 그럴 필요가 없는 경우이다. 예를 들어 Where 절에 구분코드가 1일 때 , 2일 때, 3일 때 별로 SQL이 나누어져 있는 경우이다. Where 절을 구분코드 in (1,2,3) 으로 처리하고, Select절에서 Decode나 Case 문을 사용하여 구분코드별로 처리해준다면 Union All은 필요 없다. Union All을 사용하는 또 한가지의 경우는 Sub Total(소계)과 Grand Total(총계)를 구해야 하는 경우이다. 이 경우도 Rollup/Cube나 Grouping Sets를 Group By절에 사용한다면 소계나 총계를 위한 별도의 Select문을 실행 시킬 필요는 없다. 1~4번의 과정은 SQL문의 변경이 없거나 최소화 된다. 하지만 5번의 경우는 SQL을 통합시켜야 하기 때문에 시간이 많이 소모되며, 많은 사고가 요구되는 창조적인 과정이다. 여기까지 했다면 진행되었다면 원본 SQL 자체의 튜닝은 완료 된 셈이다.

 

6. 온라인의 조회화면이라면 페이징처리는 필수이다

부분범위 처리를 해야 한다. 물론 전체 건을 처리해야 하는 경우는 있을 것이다. 하지만 조회화면이라면 몇 십만 건 혹은 몇 만 건이나 되는 결과를 모두 볼 수 없다. 따라서 볼 수 있는 단위로 끊어서 출력해야 한다. 예를 들어 결과 건수가 10만 건이라고 해도 최초의 50건을 화면에 먼저 뿌린다면 1,2,3,4 번에서 설명했던 모든 부하(Block I/O의 부하, 조인의 부하, Random Access의 부하, Sort의 부하)를 한꺼번에 감소시킬 수 있다. 따라서 가능하면 개발자를 설득하거나 책임자를 설득하여 페이징 처리를 하는 것이 바람직하다.

 

페이징 처리를 해도 효과를 볼 수 없는 몇 가지 예외가 있다. 분석함수를 사용하거나, Connect By + Start With를 사용한다면 페이징 처리의 효과는 없다. 분석함수의 경우 인라인뷰의 외부로 뺄 수 있다면 부분범위 처리가 가능하다. 이에 관해서는 해당 글을 참조하기 바란다. Connect By + Start With를 사용한 경우는 부분범위처리가 불가능하다. 하지만 11g R2의 신기능인 Recursive With절을 사용한다면 페이징 처리의 효과를 볼 수 있다. 이때, Recursive With절에 Search절(Order By절과 같은 기능)을 사용한다면 Connect By와 마찬가지로 페이징 처리의 효과가 없으니 주의해야 한다. 즉 인덱스의 구성을 적절히 하여 Sort를 대신해야 한다. Recursive With가 무엇인지 궁금한 사람은 관련 글을 참조하기 바란다.

 

7. 답이 틀리면 안 된다. SQL을 검증하라

7번은 SQL 자체를 튜닝하는 것은 아니다. 하지만 7번을 튜닝 방법에 추가한 이유는 있다. 튜닝을 하였음에도 답이 틀린다면, 튜닝을 하지 않은 것 보다 못하다. 그러므로 튜닝 후에 답이 옳은지 항상 검증해야 한다. 1번~ 7번 중에 가장 중요한 것이 7번이다.

 

방법론 정리

1.     적절한 인덱스를 사용하여 Block I/O를 최소화 하라.

2.     조인방법과 조인순서를 최적화 하라.

3.     Table Access(Random Access)를 최소화 하라

4.     Sort나 Hash 작업을 최소화 하라

5.     한 블록은 한번만 Scan하고 끝내라

6.     온라인의 조회화면이라면 페이징처리는 필수이다

7.     답이 틀리면 안 된다. SQL을 검증하라

 

방법론의 의미

만약 1~7번을 모두 적용할 수 있는 경우임에도 불구하고 하나라도 빠진다면 그것은 최적화된 SQL이 아니다. 물론 튜닝을 할 때 위의 1~6번을 항상 적용할 수 있는 것은 아니다. 경우에 따라서는 하나만 적용될 수도 있고, 두 개만 적용할 수 있는 SQL도 있다. 하지만 1~6번을 모두 적용할 수 있는지 꼼꼼히 살펴야 한다.

 

이 글은 튜닝 입문하여 관련 책들을 몇 권 본 사람들을 위한 기본적인 튜닝방법에 관한 것이다. 1번부터 7번까지의 방법은 기본 중에 기본이다. 이것들만 알아도 온라인 조회화면에서 사용하는 SQL을 튜닝하는데 어려움이 없을 것이다. 다시 말해 90%는 해결 할 수 있다. 그렇다면 나머지 10%는? 그것들은 그때 그때 마다 다르게(On the fly 모드) 처리된다. 또한 그것들은 책이나 매뉴얼에 나와있지 않기 때문에 경험치 이거나 실험과 연구의 결과로 알아내는 것들이다.

 

일상을 낯설게 느껴보니 좋은 점이 많다. 언제 필자의 다른 일상(모델링, 시스템분석/진단)에 대한 방법론도 만들어 보려고 한다.

DBMS를 이용하여 프로젝트를 진행하는 사람들에게 영원한 이슈는 무엇일까?
아마도 모델링 또는 튜닝 혹은 데이터 품질 등일 것이다. 그중에서도 DBMS 지식을 가장 많이 요구하면서도 지속적으로 지식을 Upgrade 해야 하는 분야를 꼽으라면 당연히 DBMS 튜닝분야 이다. 모델링이나 데이터 품질에는 DBMS 종류나 버젼과는 상관이 없는 부분이 많지만 튜닝분야는 전혀 다르다. 튜닝은 그특성상 특정 DBMS에 정통해야 하며 특정기능의 사용여부는 프로젝트에서 사용하는 DBMS의 특정 버젼에 종속될수 밖에 없기 떄문이다. 따라서 DBMS의 버젼이 올라가면 공부해야 할 튜닝관련 도서들도 달라져야 한다. 이런 의미에서 이미 Old Fashioned Love Book이 되어버린 Tomas Kyte의 Efective Oracle By Design이나 Jonathan Lewis의 (Practical Oracle 8i)의 명맥을 이을 Oracle 11g의 튜닝서적의 서평을 적어보려한다.

 

얼마나 좋은 책 이기에?
이번에 소개할 책은 스위스 엔지니어인 Christian Antognini가 저술한 Trouble Shooting Oracle Performance 이다. 2008년 11월에 출간 되었으나 한동안 관심이 없다가 2009년 2월에야 이 책을 보게된 계기는 추천사를 쓴 엔지니어 두사람 때문이었다.

오라클을 잘아는 사람이라면 진정한 Guru인 Cary Millsap과  Jonathan Lewis를 잘알것이다. Cary Millsap은 21 세기형 Oracle DBMS 의 튜닝방법론인 Method-R 을 집대성한 사람이다. Jonathan Lewis는 유명한 저서 Cost-Based Oracle: Fundamentals로 널리 알려진 사람이다. 이두사람이 추천한 책이라면 최소한 책값(?)은 하기 때문이다.

스위스 사람이 영어로 책을 써?
미국이나 영국 사람이 아니므로 영어가 이상할 것이라고 생각하는 사람이 있을수 있다. 하지만 필자는 역으로 생각한다. 영어권이 아닌 사람이 영어로 책을 쓸경우 오히려 이해하기가 훨씬 편하다. 철학적인 문구나 이해하기 어려운 문구를 넣는 경우가 극히 드물기 때문이다.

책의 내용을 살펴보자
이 책은 4개의 부분으로 나눌수 있다.

part1 : 기본
여기서는 거시적인 관점에서 문제 발생시 기본적인 접근방법론과 튜닝시 필요한 여러가지의 개념을 다루고 있다.
또한 프로젝트 방법론에 따른 튜닝 방법을 제시하고 있는데 약간은 고전적인 Water Fall 방법론을 따르고 있다.
튜닝 프로젝트에서 이책에서 제시한 대로만 한다면 아주 완벽하게 성공할수 있을것이다.
하지만 이론과 현실의 괴리감은 항상 있는법. 이책의 내용대로 라면 요구사항 분석단계에서 튜닝팀이 이미 존재하고 있어야 한다.

하지만 현실은? 대부분 설계단계(물리모델링시) 혹은 개발단계(개발자가 SQL을 작성하는 단계)에서 튜닝팀이 투입되고 심지어 마지막 통합 Test 단계에서도 종종 투입되기도 한다. 참으로 안타까운 아쉬운 현실이다.
저자가 이야기 하는 또하나의 중요한 점은 문제 발생시 항상 Business 관점에서 접근하라는 것이다.
필자도 이점에 동의 한다. 시스템적으로 접근하는 것은 항상 한계가 있기 마련이다.
Business를 이해하고 문제를 분석한다면 SQL 이 쉽게 이해될 것 이며 튜닝 작업이 더욱 쉬워질것이다.
Metod R 방법론 에서도 이점을 강조하고 있다는 것을 잊지말기 바란다.

part2 : 문제의 발견
저자는 문제의 분석시 반드시 모든구간에서 분석하라고 말하고 있다. 병목구간이 만약 AP 서버이거나 네트웍 구간이라면 DB의 문제가 아니라고 말할수 있다. Loop 로 처리된 SQL이 아니라면...
물론 이렇게 하려면 DB 모니터링 툴이 아닌 APM Tool이 존재 해야한다.

part2에서 필자가 가장 맘에드는 것은 TVD$XTAT 라는 멋진 분석 TOOL 을 제공 하고 있다는 점이다. TKPROF가 주지못하는 정보를 이 TOOL에서 제공한다. 꼭 사용해보기 바란다. 이 Tool 은 GUI Tool이 아니라 Command Line Tool 이다. 오해하지 말기 바란다.

part3 : 옵티마이져
part2 가 문제 발생시 접근 방법이라면 part3는 튜닝시 꼭 필요한 옵티마이져 관련지식이라고 할수 있다.  
일반적인 튜닝책이라면 통계정보의 생성이나 성능관련 파라미터의 설정법등이 대충설명 되어있음에 실망하게 될것이다. 대부분의 경우 통계정보나 파라미터 보다는 SQL 튜닝 테크닉이나 실행계획을 보는 방법등을 상세히 설명하고 있는데 이책에서는 모든것을 언급하고 있다.

통계정보의 경우  dbms_stats 패키지가 11g 에서 달라진 부분까지 상세히 설명하고 있으며 파라미터의 경우 로드맵 까지 제시하고 있다. 특히 chater 4(System and Object Statistics) 와 chapter5(Configuring the Query Optimizer)의 경우 여타의 튜닝책에서 찾아볼수 없는 부분이다.

한가지 오해하지 말아야 할것은  Physical Optimizer(비용을 계산 하여 최적의 엑세스 Path및 조인 Method를 선택하는 것을 담당함) 혹은 Logical Optimizer(Query Transformation 을 담당함)등을 직접적으로 설명한 책이 아니라는 것이다. Physical Optimizer나 Logical Optimizer는 각각 1권의 두터운 책으로 나와도 지면이 부족하다는 것을 알아야 한다.

part4 : 최적화
팔자가 가장 좋아하는 부분이다.
Parsing 을 최소화 하는방법, 데이터 access 및 Join 최적화, Advanced Technic, Physical Design 등을 다루고 있는데 가장 마음에 드는 부분은 Physical Design 부분이다. 이것은 사실상 Modeling 책에서나 나올법한 주제이지만 이책에서는 일반적인 물리 모델링 방법론을 다루는 것이 아니라 다른 Modeling책에서 다루지 않는 부분을 아주 세밀하게 다루고 있다.

예를들면 컬럼순서가 중요한 이유, 데이터 타입이 옵티마이져에 미치는 영향, 테이블의 컬럼이255 개를 넘기지 말아야 할 이유등이 그것이다. 아래의 예제를 보면 데이터 타입의 최적화가 얼마나 중요한지 알수 있다.

결과:

N1                                                             N2
------------------------------------------ ----
.3333333333333333333333333333333333333333   .33

위에서 데이터 한건을 insert 하고 밑에서 컬럼값을 Byte 로 환산하고 있다.

결과 :

VSIZE(N1)   VSIZE(N2)
---------- ----------
21               2

컬럼값의 Size가 무려 10배 이상 차이가 난다. 바로 이것이 물리모델링시 Width가 없는 Number형을 쓰지 말아야 할 이유이다.

뭐? 모델러가 튜닝 책을 봐야 한다고?
이러한 물리적 특성은 물리모델링을 고민하는 모델러들이 반드시 알아야 한다. 필자는 논리 모델은 잘되어 있지만 물리 모델이 최적화 되어 있지 않은 경우를 숫하게 보아왔다. Oracle을 이용하여 물리모델링 을 하는 사람들은 반드시 이런 종류의 책을 읽기 바란다. 왜냐하면 일반적인 모델링책의 경우 물리모델링시 오라클에 최적화 시키는 방법은 언급이 없기 때문이며 이러한 이유 때문에 튜닝책을 모델러들이 보아야만 하는 것이다.

결론:
필자가 이 책을 좋아하는 이유는 위에서와 같이 NUMBER형을 쓰지말아야 할 이유를 테스트를 통해서 비교해 주기 때문이다.  이 책에는 위와 같은 예제가 많이 등장한다. 마치 Tomas Kyte의 책(Efective Oracle By Design)이나 Jonathan Lewis의 (Practical Oracle 8i)과 같은 책을 보는듯 하다. Oracle 튜닝의 교과서라 할수 있는 이런 책들은 튜닝을 적용한 경우와 그렇지 않은 경우를 번갈아 보여주며 차이점을 극명하게 대조시키는 방법을 사용하고있다.
다행스럽게도 오늘 필자가 리뷰한 Trouble Shooting Oracle Performance 또한 이러한 방법을 쓰고있다.
여러가지 면에서 Oracle 튜닝에 관해 진지한 고민을 해본 사람들에게 추천하고 싶은 책이다. 여러분들도 한번 고민해보지 않겠는가?

P.S : 이책과 관련된 또다른 서평을 아마존(Amazon)에서 참조하기 바란다.
Amazon 서평