책 (The Logical Optimizer)의 Part 4에 대한 PPT가 완성되었다. 이제 본문의 모든 내용이 PDF로 요약 되었다. 책을 쓴 저자의 의무를 어느 정도 한것 같다.

Part 4는 CBQT (Cost Based Query Transformation)의 내부원리에 대한 내용이다. 즉 쿼리변환(Query Transformation)에 대한 내용이 아니라 옵티마이져의 원리에 대한 내용이다. 본문 내용중에서 가장 난위도가 있는 부분이기도 하다.

사용자 삽입 이미지
사용자 삽입 이미지


Tstory의 용량제한 때문에 할 수 없이 파일을 2개로 나눠(분할압축) 올린다.

압축  프로그램 7zip

THE LOGICAL OPTIMIZER (양장)
국내도서>컴퓨터/인터넷
저자 : 오동규
출판 : 오픈메이드 2010.04.05
상세보기



Posted by extremedb
,

PDF 파일의 95 페이지에 타이틀이 잘못되어 수정해서 다시 올림(2010-09-15 오후 6시)

책 (The Logical Optimizer)의 Part 3에 대한 PPT가 완성되었다. Oracle 10g 부터 시작된 CBQT (Cost Based Query Transformation)에 대한 내용이다. 파워포인트 작업을 할때는 몰랐는데 완성하고 보니 130 페이지가 넘어가고 파일크기도 30MB가  넘는다. Tstory의 용량제한 때문에 할 수 없이 파일을 3개로 나눠(분할압축) 올린다. Part 3의 내용을 이해하는데 도움이 되었으면 한다.

사용자 삽입 이미지
사용자 삽입 이미지

압축  프로그램 7zip





PS
Part 4 도 작업이 완료되는 대로 올릴 예정이다.
Posted by extremedb
,

(The Logical Optimizer) 내용중 Part 2 부분의 PPT 파일이 완성되어 올립니다.
Tstory
10MB보다 큰 파일은 올릴 수 없게 되어있군요. 파일의 사이즈가 커서 분할 압축하여 올립니다
.
압축을 푸시면 아래그림처럼 3개의 파일이 됩니다. 각각 10MB 정도 되는군요.


사용자 삽입 이미지


첫 번째 파일(The Logical Optimizer_Part II_1) Basic 부분(2.A ~2.16)까지 입니다.
두 번째 파일(The Logical Optimizer_Part II_2) Subquery부분(2.17~2.29)까지 입니다.
세 번째 파일(The Logical Optimizer_Part II_2) Data Warehouse부분(2.30~Part2 마무리)까지 입니다.

PPT
파일로 다시 한번 정리하시기 바랍니다.
압축  프로그램 7zip
감사합니다.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
Posted by extremedb
,

원래 3월에 출간 예정이 었으나 마음대로 되지 않았다. 회사 내/외부에서 책이 왜 늦어지냐고 원성을 많이 들었다.
여러분들에게 사과드린다.
 
필름 마감
드디어 인쇄용 필름이 마감되었다. 은행에도 일 마감이 있듯이 출판에도 필름 마감이라는게 있다. 이 과정이 끝나면 인쇄가 시작된다. 오늘 인쇄작입이 시작될 것이다. 1월에 원고를 완성했지만 여러가지 문제(오탈자 수정 작업, 표지 디자인, 띠지 디자인, 메켄토시용 워드로 변환 과정에서 오류및 페이지수가 달라지는 현상, 페이지가 달라졌으므로 목차 및 색인 재작업, 인쇄용지 부족현상, ISBN 번호 취득, 표지와 띠지 그리고 본문의 용지 선택, 최종 필름의 검증) 과정에서 시간을 많이 소모 하였다. 이 모든 과정이서 작가의 의견이 직 간접적으로 들어가야 한다. 이제 남은건 서점과의 계약인데 4월 20일 정도에 YES24나 교보문고 등에서 주문이 가능할 것이다.

그럼 이제 책의 겉모습을 보자.



사용자 삽입 이미지


삼장법사와 손오공의 관계는?
표지는 빈티지 스타일로 처리하여 케케묵은 고서(오래된 책)의 느낌을 받도록 하였다. 앞 표지의 그림은 삼장법사와 손오공이다. 이 그림은 Logical Optimizer와 Physical Optimizer의 관계를 나타낸 것이다. 제일 아래의 미리보기 파일을 보면 상세한 내용을 알 수 있다. 총 430 페이지 이므로 책등을 보더라도 그다지 두껍지는 않다.

이제 표지에 띠지를 입혀 보자.


사용자 삽입 이미지

그림을 클릭하면 크게 볼 수 있다. 띠지가 너무 강렬하다는 의견도 있었으나 바꿀 경우 작업시간 때문에 출간일자가 늦어지므로 그냥 가기로 하였다. 나중에 알고보니 띠지가 강렬한 것이 아니라 띠지의 표준색이 빨강이라 한다. 평소에 띠지를 주의 깊게 보지 않아서 오해한 것이다.


책을 집필 하게된 원인
2006
년 늦은 가을의 한 사건 때문에 이 책이 나올 수 있었다. 그 사건이 아니었다면 Logical Optimizer로 인한 문제가 실무에서 얼마나 중요한지 알 수 없었을 것이다. 아래에 그 사건과 관련된 에피소드를 소개한다.

Episode

영화 <아바타>에는 영혼의 나무를 통하여 생명체와 교감하며 평화로운 생활을 영위하는 판도라 행성의 나비족이 등장한다. 하지만 이 행성의 광물에 눈이 먼 지구인들은 무력을 통해 이들을 짓밟게 되고, 인간의 탐욕에 치를 떤 지구인 제이크 셜리는 인간을 등지고 나비족의 편에 선다. 하지만 그 과정에서 나비족의 신뢰를 받지 못한 제이크는 무모하게도 나비족 역사 이래 5번밖에 소유하지 못했던 영적 동물 토르쿠 막토를 획득하려는 불가능한 시도를 하게 된다. 천신만고 끝에 얻어낸 토르쿠 막토는 모든 상황을 급 반전시킨다. 결국 그는 토르쿠 막토의 힘을 빌려 나비족의 새로운 지도자가 되고 인간과의 전쟁을 승리로 이끈다.


토르쿠 막토, 우리가 가질 수 있나
영화가 아닌 현실에서도 모든 상황을 한번에 해결할 만한 토르쿠 막토 같은 위력적인 무기를 가질 수 있을까? 지금부터 그것을 손에 넣었던 필자의 경험담을 소개한다.

2006년 늦은 가을이었던가? 필자는 새로운 사이트에 투입되어 DBA들과 튜닝 중에 있었다. 개발자들이 튜닝을 의뢰하면 먼저 DBA들이 튜닝을 실시하고, DBA가 해결하지 못하는 SQL은 필자에게 튜닝 요청이 들어온다. 하지만 그 당시 한 달이 넘게 DBA들과 필자가 튜닝 작업에 고심하였음에도 요청되는 튜닝 건수에 비해 해결되는 건수가 턱없이 부족했다. 베테랑 DBA 3명이나 있었음에도 불구하고 해결되지 않는 SQL의 건수는 계속해서 쌓여가고 있었다.

도대체 왜?
한 달째인 그날도 밤 12시가 넘었지만 퇴근하지 못했으며 이것이 어쩔 수 없는 컨설턴트의 숙명이거니 하는 자포자기의 심정이 들었다. 새벽 한 시가 되어 주위를 둘러보니 사무실엔 아무도 없었다. 얼마 후 건물 전체가 소등되었고 모니터의 불빛만이 남아있었다. 암흑과 같은 공간에서 한동안 적막이 흘렀다. 바로 그 순간 요청된 SQL에는 일정한 패턴이 있지 않을까 하는 생각이 번쩍 들었다. 갑자기 든 그 생각으로 필자는 퇴근할 생각도 잊은 채 SQL에 대한 패턴을 분석하기 시작했다. 그리고 몇 시간 후 동 틀 무렵, 놀라운 결과를 발견할 수 있었다.

필자에게 튜닝을 요청한 SQL의 많은 부분이 Query Transformation(이하 QT) 문제였다. Logical Optimizer의 원리만 알았다면 필자를 비롯한 DBA들은 저녁 7시 이전에 일을 마칠 수 있었을 것이다. QT Logical Optimizer가 성능 향상의 목적으로 SQL을 재 작성(변경)하는 것을 말한다. 하지만 옵티마이져가 완벽하지 못하므로 많은 경우에 문제를 일으키게 된다.

베테랑 DBA들의 아킬레스건은 고전적인 튜닝 방법에 의존하는 것
DBA들은 지금껏 전통적인 튜닝 방법 3가지(Access Path, 조인방법, 조인순서)에 대한 최적화만 시도하고, 그 방법으로 해결되지 않으면 필자에게 튜닝을 요청한 것이다. 그들에게 QT를 아느냐 물었을 때 대답은 거의 동일했다. 그들이 아는 것은 Where 조건이 뷰에 침투되는 기능, 뷰가 Merging(해체)되는 기능, OR 조건이 Union All로 변경되는 기능, 세 가지 뿐이었다. 실무에서 발견되는 대부분의 문제를 해결하려면 최소한 30가지 이상은 알아야 한다. 그런데 세 가지만 알고 있다니...... 충격적인 결과였다. 10개 중에 9개를 모르는 것과 같았다.

하지만 QT와 관련된 적절한 교재나 교육기관이 전무한 상태였기 때문에 이러한 문제에 대해 DBA들을 탓할 수는 없을 것이다(이 사실은 2006년이 아닌 2010년 현재도 마찬가지이다). 필자는 다음날부터 삼 일 동안 튜닝을 전혀 하지 않기로 마음 먹었다. 대신에 DBA들에게 Query Transformation에 대한 교육을 하기로 작정했다. 필자의 입장에서는 교육을 진행하지 않아도 그때까지 쌓여있는 튜닝 이슈만 해결하면 프로젝트를 마무리 할 수 있었다. 하지만 열정 때문인지 아니면 윤리적 의무감이 원인인지 모르겠으나 교육을 진행하지 않은 상태에서 프로젝트를 끝낼 수 없다고 생각하고 있었다.


난관
다음날 필자는 DBA들과 담당 책임자를 불러서 교육에 관한 회의를 하였다. 책임자는 삼 일간 18시간의 교육 때문에 튜닝 실적이 거의 없게 되므로 교육은 불가능하다는 것이었다. 업무시간 중 교육을 하게 됨으로 필자 뿐만 아니라 모든 DBA들의 튜닝실적이 없게 되는 것이다. 책임자와 DBA들은 해결되지 않는 튜닝문제의 대부분이 Logical Optimizer 때문이라는 사실을 필자의 분석자료를 통해 알고 있었다. 하지만 책임자는 상부에 튜닝 실적을 보고해야 되는 처지였으므로 교육은 불가하다고 하였다.

필자는 교육 후에 가속도가 붙을 것이므로 실적을 충분히 따라잡을 것 이라고 책임자를 설득하였다. 그는 실적 대신에 교육 후에 향상된 DBA들의 문제 해결능력을 상부에 보고하겠다고 하였다. 다행스러운 일 이었다. 그런데 이번에는 DBA들이 교육을 완강히 거부했다. 그들은 튜닝 이외에 Database 관리업무도 진행해야 하는데 삼 일의 교육기간 중 업무를 처리하지 못하게 된다는 것이었다. 따라서 교육 후에 밤을 세워서라도 밀린 업무를 수행해야 되는 처지였으므로 교육을 부담스러워 했다. 또한 Logical Optimizer의 원리보다는 고전적인 튜닝 방법을 신뢰하고 있었기 때문에 며칠간의 교육으로 문제가 해결될지 의심하고 있었다.


설득의 방법
필자는 강한 반대 의견 때문에  ‘억지로 교육을 해야 하나?’ 라는 생각이 들었다. 마지막 이라는 심정으로 설득의 방법을 바꾸어 보았다. DBA들이 교육을 통해서 무엇을 얻을 것인가(WIFM) 관점보다는 교육을 받지 못하면 손해를 보게될 상황을 설명 하였다. 즉 튜닝 프로젝트가 끝나고 필자가 나간 뒤에도 같은 패턴의 튜닝 문제가 발생할 것인데 지금 교육을 받지 않는다면 그때가 되어도 튜닝을 할 수 없을 것이라고 강조하였다. 또한 업무시간 후에 교육을 받으면 시간을 거의 뺏기지 않을 것 이라고 설명하였다.

마침내 설득은 효과를 발휘했다. 업무시간을 제외한 저녁 7시부터 10시까지 총 6일간 교육을 진행하기로 모두가 합의하였다. 3일 간의 교육이 6일간의 교육으로 늘어지긴 하였지만 교육을 진행할 수 있게 되었다는 사실만으로도 아주 다행스런 결과였다. 교육시간에 실무에서 가장 발생하기 쉬운 QT 기능들의 원리와 튜닝방법부터 설명하였다. 일주일의 교육을 마치자 곧바로 효과가 나타났다. 교육 후 필자에게 들어오는 튜닝 의뢰 건수가 절반으로 줄어든 것이다. 비로소 필자는 정상적인 시간에 퇴근할 수 있게 되었다
.

기적은 필자에게만 일어난 것이 아니었다. 교육 이전에 DBA들은 밤 11시가 넘어서야 퇴근 하였다. 왜냐하면 필자에게 튜닝 요청을 하기 전에 성능이 개선되지 않는 SQL을 짧게는 몇 시간, 길게는 며칠 동안 붙잡고 고민하다가 요청하기가 일쑤였기 때문이었다. 교육 이후로는 DBA들이 SQL을 보는 관점부터 달라졌으며 필자가 없어도 QT 문제를 스스로 해결할 수 있는 능력을 갖게 되었다. 기대 반 우려 반의 심정으로 교육을 허락한 책임자의 얼굴에도 화색이 돌았다. 지난 수 년간 진행되었던 Logical Optimizer의 원리에 대한 연구가 한 순간에 빛을 발하고 있었다
.

그 사이트의 문제가 해결되고 얼마 후 지난 2년간 다른 프로젝트에서 요청 받았던 튜닝 문제를 같은 방법으로 분석 하였는데 원인 중 절반이 QT 문제였다. 이 같은 경험은 우리에게 시사하는 바가 크다. 어떤 문제로 베테랑 DBA들이 밤을 세우는지, 어떤 기술로 문제를 해결 할 수 있는지 혹은 어떤 기술이 고급 튜너로 가기 위한 것인지 알 수 있다. 혹시 당신이 속한 프로젝트에 DBA, 튜너 혹은 고급 개발자들이 퇴근을 못하고 밤새 일하고 있다면
고심해 보라. Logical Optimizer의 원리가 상황을 반전 시킬 수 있는지를.
의심해 보라. 그 원리가 토르쿠 막토가 아닌지를......

<본문 내용 중에서>

 
이 책의 가장 큰 특징은 목차만 보고 어떤 기능을 하는 것인지 떠올릴 수 있다는 것이다. 물론 책을 한번 읽은 상태에서 가능하다. 복습할 때 가장 유용한 것이 목차만 보고 요약이 되는 것인데 Part 2와 Part 3가 이런 접근법을 따르고 있다.   

아래에 책의 미리보기(Preview)파일을 올린다. 에피소드, 서문, 감사의 글, 책의 구성과 책을 읽는 방법, 목차, 종문, 참조문서, 색인 등을 볼 수 있다.
   

invalid-file

The Logical Optimizer 미리보기


PS
글을 준비하고 작성하는데 5년이나 걸렸고 글을 실물의 책으로 만드는 과정에서 3개월이 소모되었다. 맡은 프로젝트 + 전공이외의 Study + 블로그 관리+ 옵티마이져의 연구 및 집필을 동시에 진행하는 것은 고통의 연속이었다. 이제 좀 쉬어야 겠다. 몇년뒤에 다음 책이 나올 수 있을지.....
지금의 심정으로는 자신이 없다.



위에서 언급한 필자의 에피소드가 한국 오라클의 2010년 매거진 여름호에 실려있다. 아래의 PDF 파일을 참고하기 바란다.
(2010년 7월 추가)
사용자 삽입 이미지

오라클 매거진 2010년 여름호



THE LOGICAL OPTIMIZER (양장)
국내도서>컴퓨터/인터넷
저자 : 오동규
출판 : 오픈메이드 2010.04.05
상세보기



'The Logical Optimizer' 카테고리의 다른 글

The Logical Optimizer Part 1 - PPT  (17) 2010.07.26
The Logical Optimizer-서점  (0) 2010.04.27
The Logical Optimizer-Script Download  (37) 2010.04.20
The Logical Optimizer-오타와 오류등록  (27) 2010.04.20
저자와의 대화  (36) 2010.04.20
Posted by extremedb
,

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 개를 넘기지 말아야 할 이유등이 그것이다. 아래의 예제를 보면 데이터 타입의 최적화가 얼마나 중요한지 알수 있다.

SQL> CREATE TABLE t (n1 NUMBER, n2 NUMBER(*,2));

SQL> INSERT INTO t VALUES (1/3, 1/3);

SQL> SELECT * FROM t;


결과:

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

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

SQL> SELECT vsize(n1), vsize(n2) FROM t;

결과 :

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 서평

Posted by extremedb
,
예전에 Relational Database Index Design and the Optimizers 라는 글과
중급 개발자들이 보아야 할 오라클 책 이라는 글에서 DBMS 및 오라클 관련책을 추천한바 있다.
이번에는  Cost-Based Oracle Fundamentals 의 저자인 Jonathan Lewis 가 DBMS 관련 책 8권을 추천하였다.
우연히도 필자가 추천한 책 2권을 Jonathan Lewis도 도 추천 하였다.
아래의 주소를 참조하기 바란다.

http://jonathanlewis.wordpress.com/2009/01/14/books/

편집후기: Comments 부분에도 책 여러권이 등장 하므로 꼭 읽어보기 바란다.
Posted by extremedb
,