책 (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

댓글을 달아 주세요

  1. 리베 2010.10.04 10:35 신고  댓글주소  수정/삭제  댓글쓰기

    항상 좋은 자료 감사합니다. 오동규님 덕분에 실력이 쑤~~~욱 올라가고 있는듯... ^^

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.10.04 12:38 신고  댓글주소  수정/삭제

      안녕하세요. 리베님
      실력이 향상되었다면 참으로 다행스런 일 입니다.
      제가 이제 좀 쉬었으니 슬슬 다음 주제를 준비해야 할 단계가 온것 같습니다.^^

  2. feelie 2010.10.07 12:39 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 자료 감사합니다

  3. 김시연 2010.10.26 14:15 신고  댓글주소  수정/삭제  댓글쓰기

    오늘 컨설팅 복귀하고, 자료 다운받아서 쭉 보고 있습니다. PPT 만드는게 보통일이 아닌데, 수고 많으셨습니다.
    그리고 혹시 Logical Optimizer에 대한 세미나나 교육 계획이 있으신가요?
    그럼 갑자기 추워진 날씨에 감기 조심하세요~!

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.10.26 14:53 신고  댓글주소  수정/삭제

      시연님 오랜만 입니다. 복귀하셨군요. 고생하셨습니다. 교육에 관하여 말씀 드리겠습니다.
      올해부터 HP 교육센터를 오픈메이드가 운영하게 됨에 따라 logical optimizer 교육은 준비중입니다. 아마도 주말(토, 일)을 이용한 4일 과정이 될것 같습니다. 혹시 짧은 세미나나 출장교육은 수고스럽더라도 저에게 메일로 문의해 주시기 바랍니다.
      감사합니다.

  4. 2010.11.30 09:55 신고  댓글주소  수정/삭제  댓글쓰기

    귀한 자료네요... 책도 읽었는데 이렇게 또 볼수 있어서 좋습니다. 감사합니다.

  5. Favicon of http://blog.naver.com/genisu BlogIcon 김승욱 2013.01.07 10:55 신고  댓글주소  수정/삭제  댓글쓰기

    책을 읽다 놀란것이 의무감에 대한 말씀을 하신거에 대해 참 감동받았는데
    PPT까지 올려주시다니...정말...대단하신것 같습니다.감사합니다!!!


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

댓글을 달아 주세요

  1. 윤상원 2010.09.15 17:07 신고  댓글주소  수정/삭제  댓글쓰기

    파트3, 기다리고 있었는데 감사합니다!
    책 내용을 정리하는데 많은 도움이 될 거 같습니다.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.09.15 17:20 신고  댓글주소  수정/삭제

      반갑습니다.
      의외로 파워포인트를 기다리는 분들이 많이 계시는군요.
      Part 4도 힘을 내서 빨리 작업을 해야겠습니다.
      감사합니다.

  2. 윤상원 2010.09.15 17:30 신고  댓글주소  수정/삭제  댓글쓰기

    방금 보는중에 PDF파일 95페이지에 보니 갑자기 3.8 CVM 내용이 나오네요. 앞내용이 3.15 GBPD인데 말이죠. 카피되는 중에 잘못 들어간거 같습니다~

(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

댓글을 달아 주세요

  1. 썸바디 2010.08.13 09:41 신고  댓글주소  수정/삭제  댓글쓰기

    늘 좋은 정보 감사합니다~~
    근데 다운받은 파일 압축이 잘 안풀리네요 ㅡㅡ

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.08.13 09:58 신고  댓글주소  수정/삭제

      분할 압축이므로 모두 다운받은 후에 푸셔야 합니다.
      7zip 프로그램을 다운받으시거나 알집으로 압축을 푸시면 됩니다. 7zip 프로그램을 다운받을 수 있게 글을 수정하였습니다. 해결 되셨나요?

  2. 썸바디 2010.08.13 10:21 신고  댓글주소  수정/삭제  댓글쓰기

    7zip 으로 하니 압축 잘 풀리네요~ 감사합니다~^^

  3. 써니 2010.08.16 23:44 신고  댓글주소  수정/삭제  댓글쓰기

    먼저, 좋은 정보 감사드립니다.

    제가 최근 DBUA를 이용한 9i --> 10gR2(10.2.0.4), 11gR1(11.1.0.7) 로 Upgrade를 한 이후에 기존 SQL Plan에 비해
    현저하게 안좋은 Plan을 보이고 있어, 여기 저기 Web Site를 찾다가 우연히 이 Site를 알게 되었습니다.

    올려 주신 정보이외에도 최근 이곳에서 많은 도움을 받고 있습니다.
    이렇게 글을 올리게된 이유는 다름이 아니오라 한가지 궁금한 점이 있어서 입니다.

    Upgrade 한 이후에 업무 특성상 주요 Table들에 대해서, 매일 Analyze를 하고 있습니다.
    그런데, 9i에서 보여 주었던 SQL Plan에 비해 안좋은 결과를 보이고 있어서 원인 분석 중
    Upgrade된 DB에서 해당 Table에 대한 통계정보를 삭제 후, 다시 Plan을 보니 9i와 같은 Plan을 보여주고 있습니다.

    마치, 10gR2 와 11gR1의 Optimizer가 멍청해진것 같은 현상입니다.
    이걸 어찌 받아 들여야 할까요?
    (예로, 심지어는 Index도 안타고 Table Full Scan 하고 있습니다...
    Table에 대한 통계정보를 삭제 후엔 Index Scan 합니다.)

    지금은 SQL문 곳곳에 Hint문을 사용하여 해결하고 있으나, 본질적인 해결책이 아닌 듯 하여
    답답한 마음에 글 올립니다.
    /*+OPT_PARAM('_OPTIMIZER_PUSH_PRED_COST_BASED', 'FALSE') */
    /*+ opt_param('_optimizer_cost_based_transformation', 'off') */
    와 같은 Hints를 사용하고 있습니다.

    한 말씀 남겨주시면 감사하겠습니다.

    감사합니다.
    (딱히, 질문을 올릴만한 곳이 없어 이곳에 올립니다.)

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.08.19 21:41 신고  댓글주소  수정/삭제

      써니님 안녕하세요.
      답변이 늦어 죄송합니다.
      말씀하신 옵티마이져의 문제는 예전부터 많이 있었습니다.
      old 버젼에서 new 버젼으로 upgrade 함에도 불구하고 악성 Plan으로 되는 경우가 있습니다.
      하지만 그것은 SQL의 5% 내외일 것입니다. 다시말하면 성능이 좋아진 것이 많은 부분을 차지하고 있지만 그것은 눈에 띄질 않습니다. 예를들어 0.2초 걸리던 것이 0.1초걸린다면 이런것은 문제가 되지 않지요. 하지만 약 100개중의 5개의 경우는 악성 plan을 만드는 경우가 많습니다.
      이런 경우는 어쩔 수 없습니다. 사람이 개입하여 올바른 길을 알려주는 수 밖에요.

      참고로 위에서 이야기한 5% 라는것은 정확한것이 아닙니다. 어림짐작으로 이야기한것이고 실제로는 시스템과 버젼에 따라 약간은 달라질 수 있습니다.

      먼저 두가지를 점검해 보시기바랍니다.
      1.통계정보를 충실히 수집했는지?
      예륻들어
      건수가 아주 많은 테이블은 0.01%
      건수가 조금 많은 테이블은 0.1%
      건수가 보통인 테이블은 5%
      건수가 적은 테이블은 10%
      건수가 아주 적은 테이블은 100%
      건수에 상관없이 기초성 테이블(고객, 상품, 부서, 직원, 계좌, 공통코드)등은 100%

      이렇게 하시면 됩니다. 이것은 예시 이므로 실제하실때는 구체적으로 하셔야 겠죠. 제가 수행한 사이트에는 통계정보를 수집할때 Oracle10g R2의 경우 AUTO 옵션을 쓰지 않습니다.

      local 파티션통계는 수집하지 않는것이 좋습니다. 즉 Global 통계만 관리하시면 됩니다. 단 전제조건이 있습니다. 각 파티션마다 실행계획이 달라져야 하는 경우는 local 파티션 통계를 수집하시는 것이 옳습니다. 반대로 모든 파티션의 실행계획을 고정시키고자 할때는 global 파티션의 통계정보만 관리해도 충분합니다.

      2.적절한 인덱스가 존재하는지?
      이것 또한 어려운 문제입니다.
      어려움을 토로하시는 걸로 봐서 Query Transformation 문제 같습니다. 각각의 SQL과 PLAN을 보고 적절한 인덱스가 있는지 판단 하셔야 합니다.
      예를 들어 인라인뷰가 있고 그 내부의 where절에 상수조건이 있다고 할때 거기에 JPPD가 발생했다고 치면 조인조건이 인라인뷰 안으로 파고 듭니다. 그런데 상수조건으로만 인덱스를 만들어주면 JPPD의 효과는 줄어들겁니다. 인덱스가 상수조건 + 조인조건으로 결합인덱스를 만들어주어야 JPPD의 효과가 최적으로 나타납니다. 아래의 SQL을 보세요.

      SELECT d.department_id, d.department_name, e.employee_id, e.job_id, e.email_phone_num
      FROM department d,
      (SELECT employee_id, department_id, job_id, phone_number AS email_phone_num
      FROM employee
      WHERE job_id = :v_job2 )e
      WHERE d.department_id = e.department_id(+)
      AND d.location_id = 1700;

      위의 SQL에서 EMPL0YEE 테이블에 존재해야 할 최적의 인덱스는 JOB_ID 가 아니라 JOB_ID + department_id 인덱스 입니다. 변경되지 않은 SQL만 보았을 때는 JOB_ID 인덱스만 있으면 될것 같지만 변경된 SQL을 보면 결합인덱스가 왜 필요한지 아실겁니다. 아래의 변경된 SQL을 보시죠.

      SELECT d.department_id, d.department_name, e.employee_id, e.job_id, e.email_phone_num
      FROM department d,
      LATERAL (SELECT employee_id, department_id, job_id, phone_number AS email_phone_num
      FROM employee e2
      WHERE e2.job_id = :v_job2
      AND e2.department_id = d.department_id ) e
      WHERE d.location_id = 1700 ;

      위의 변경된 SQL을 보신다면 결합인덱스가 최적임을 아실것 입니다. 물론 결합인덱스의 효율이 더 좋은경우를 이야기 하는 겁니다. 쿼리변환의 문제는 통계정보의 적절성과 인덱스의 최적화 문제가 거의 대부분 입니다.

      하지만 이 두가지가 완벽히 되어 있다고 할지라도 옵티마이져가 완벽하지 않으므로 5% 미만의 경우는 악성 PLAN을 생성하기 때문에 사람이 힌트나 쿼리튜닝을 통하여 손을 봐주어야 합니다. 옵티마이져가 아무리 업그레이드 되어도 사람의 손길이 필요하다는 것입니다. 아마도 앞으로 20년간은 그럴것 같습니다.
      감사합니다.

  4. 써니 2010.08.18 13:28 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 말씀 진심으로 감사드립니다.
    앞으로도 많은 공부가 필요할 듯 합니다.

    다시 한 번 감사의 말씀드립니다.

  5. 써니 2010.08.20 00:41 신고  댓글주소  수정/삭제  댓글쓰기

    브라이언 홍님 관심주셔서 고맙습니다.

    그리고 extremedb님 오늘도 좋은 말씀 감사드립니다. ^^

  6. 써니 2010.08.20 11:29 신고  댓글주소  수정/삭제  댓글쓰기

    여기저기 문서를 찾아보니,
    Analyze 와 dbms_stats Procedure의 차이점이 심할 수도 있겠습니다.

    위에서 언급한 Index를 사용하지 못않는 Table을 대상으로 Test한 결과
    Analyze 와 비교해서 dbms_stats Procedure를 이용해서 통계를 구한 결과가
    제가 원하는 Plan을 보여주고 있습니다.

    관련 자료를 참고로 올리고 싶은데.. 올릴 수 있는 방법이 없네요..^^
    혹 다른 분들을 위해서 다음 정보를 남김니다.

    What’s Up With dbms_stats?
    by Terry Sutton
    Database Specialists, Inc.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.08.20 11:51 신고  댓글주소  수정/삭제

      헉! analyze로 실행하고 계셨나요?
      말씀하신대로 그차이는 엄청 큽니다. 앞으로도 차이가 더 벌어질 것입니다.
      11g에서 dbms_stats는 정확성과 성능면에서 또 한번 진화되었습니다. 아래의 글을 참고하세요.
      http://scidb.tistory.com/entry/11g-DBMSSTATS-개선사항

  7. 브라이언홍 2010.08.23 09:22 신고  댓글주소  수정/삭제  댓글쓰기

    저도 현재 이런 경우를 많이 접하고 있습니다.
    써니님꼐서 사용하시는 힌트는 저의 경우 Long Parse일 경우에 사용합니다.
    "왜 Long Parse가 발생하느냐?"가 관건일 것 같습니다.

    문득 어제 밤에 이런 생각을 해 보았습니다.
    제 친구 중 하나는 물건을 구입할 때 딱 한가지 기준이 있답니다. 그래서 쇼핑할때 시간이 많이 걸리지 않는다고 하더군요.
    그런데 저는 이것저것 비교하기를 좋아합니다. 심지어 이마트에서 본 물건이 롯데마트에서 더 좋은 디자인과 더 좋은 가격 더 좋은 품질을 있었는지 기억을 더듬습니다. 참~~~ 쇼핑하기 힘들지요.. ㅡ,ㅡ; 신중하다라고 말하기엔 너무 오타쿠 같아서ㅋㅋ

    옵티마이저가 비용기반으로 작동하기에 너무 많은 것을 고민하고 있는것은 아닐까요?
    그래서 과감히 그 기능을 꺼버리면 파싱하는 시간이 줄어드는게 당연하겠지요~~ 그러나 실행계획이 최적이 안되면 또 낭패입니다.

    제가 예전에 이런 문제로 엑셈에 올린글이 있어 공유해봅니다. 혹시 보셨는지 모르겠지만 ..
    http://121.254.172.39:8080/pls/apex/f?p=101:11:0::::P11_QUESTION_ID:2470200346608331

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.08.19 11:17 신고  댓글주소  수정/삭제

      하드파싱시간은 아래의 두가지를 합친것 입니다.
      Logical Optimizing + Pysical Optimizing
      그래서 위의 관련 파라미터를 꺼 놓으면 시간이 줄어들 수는 있으나 또다른 문제가 발생합니다. 실행계획이 악성이 될 수 있습니다. 즉 파라미터를 끄는 방식으로는 두마리 토끼를 다 잡기가 어렵다는 것입니다.

      두마리 토끼를 다 잡는 방법이 있습니다. 하지만 이방법은 100개중에 문제가 되는 SQL에만(5% 미만) 적용하시는것이 좋을것 입니다.

      1.Hard Parsing시간을 고려하지않고 최적의 실행계획을 찾는다.
      2.최적의 실행계획을 유도하는 오라클 내부힌트(Internal Hint)를 찾는다. DBMS_XPLAN.DISPLAY_CURSOR 의 Outline Data를 참조하시면 됩니다.
      3. 그 힌트들을 해당 SQL에 적용한다.

      모든 힌트를 적용할 필요는 없습니다. 두가지 카테고리의 힌트만 적용하시면 됩니다.
      1.LOGICAL 힌트 (unnest, merge, push_pred, USE_CONCT...)
      2.PHYSICAL 힌트 ( 조인순서 (leading), 조인방법(use_nl/hash/merge), 엑세스방법(index, full) )

      환경적 힌트, 예컨데 OPTIMIZER_FEATURES_ENABLE이나 DB_VERSION ,all_ROWS 등의 힌트는 빼셔도 됩니다. 환경적 힌트 또한 Logical 과 Physical Optimization을 결정하기 위한것 입니다. 그러한 것들을 미리 결정해 놓았으므로 환경적 힌트는 필요가 없습니다.

      이렇게 한다면 Hard Parsing시간이 최소화 되면서도 최적의 실행계획을 유지할 수 있습니다. 왜냐하면 옵티마이져가 고민하여 결정해야할 것을 고민할 필요없이 만들어버렸기 때문입니다. 즉 여러마트들을 돌아다니면서 시간을 죽이며 어렵게 쇼핑할 필요가 없습니다. 또한 개발자가 힌트를 적용하지 않는다고 하여도 오라클이 그러한 힌트를 내부적으로 적용할 것입니다.

      제가 집필한 책(The Logical Optimizer)에도 239 페이지에 이부분을 언급하였습니다.
      감사합니다.

      주의사항은 이렇게 적용한 SQL은 별도의 목록을 만들어 관리하는 것이 좋습니다. SQL이 변경될때 다시 1~3번을 적용해야 되기 때문입니다.

원래 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)파일을 올린다. 에피소드, 서문, 감사의 글, 책의 구성과 책을 읽는 방법, 목차, 종문, 참조문서, 색인 등을 볼 수 있다.
   

The Logical Optimizer_Preview.pdf

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-오타와 오류등록  (26) 2010.04.20
저자와의 대화  (36) 2010.04.20
The Logical Optimizer  (61) 2010.04.05
Posted by extremedb

댓글을 달아 주세요

  1. 이전 댓글 더보기
  2. 디비딥 2010.04.06 01:02 신고  댓글주소  수정/삭제  댓글쓰기

    앗 눈팅만 하다가 책이 출판된다고 하길래 너무 기대되서 댓글 남깁니다.
    내공은 별로 없어 이해가 될지 모르겠지만 잘 보겠습니다. 어서 출판해 주세요^^

  3. 홍택현 2010.04.06 10:51 신고  댓글주소  수정/삭제  댓글쓰기

    정말 고생하셨습니다 수석님~~
    어서 쾌차하시길 기원하겠습니다. ^^

  4. daemon 2010.04.06 15:34 신고  댓글주소  수정/삭제  댓글쓰기

    오라클을 공부하며 오동규님의 블로그에 항상 도움을 받아 왔었습니다.
    이번으로 2번째 리플을 달게 되는데요 감사한 마음을 가지면서도 감사의 글을 자주 못올려 죄송했습니다.
    정말 감사한 책이 이제 다음달이면 나오는군요 .. 오랜 시간 책을 쓰시느라 정말 고생하셨습니다.
    블로그도, 책도 항상 감사하다는 말뿐이 드릴말씀이 없습니다.

  5. 타락천사 2010.04.06 16:05 신고  댓글주소  수정/삭제  댓글쓰기

    축하드립니다.
    꼭 봐야겠네요 !!
    항상 건강하시구요 !!
    고고씽

  6. 초보DBA 2010.04.06 18:32 신고  댓글주소  수정/삭제  댓글쓰기

    아직 시장에는 안풀린것인가요? yes24나 인터파크등에서 보이지가 않네요
    출간 축하드립니다.

  7. 마늘장아찌 2010.04.07 10:05 신고  댓글주소  수정/삭제  댓글쓰기

    항상 책에 대한 갈증이 있지만 막상 서점에 가보면
    딱히 손에 잡히는 책은 별로 없더라구요.
    가끔 사이트에 들어와, 실무 경험이 느껴지는 글을 읽으며
    제가 모르는 부분에 대하여 생각을 많이하고 또 부족한 저자신을 더욱 채찍질 하는 계기가 되곤 합니다.
    출간을 다시한번 축하드리며, 조만간 꼭 구입해서 읽어 보겠습니다.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.04.07 13:18 신고  댓글주소  수정/삭제

      마늘장아찌님의 이야기처럼 이 책은 현장의 문제점에 대한것 입니다.
      내공을 확장시키는 기회가 되었으면 합니다.
      감사합니다.

    • 마늘장아찌 2010.04.07 17:51 신고  댓글주소  수정/삭제

      올리신 preview 화일 잘읽었습니다.
      개인적으로 조금 아쉬운 부분은 epilog에 있는 명제,필자,독자 라는 단어에 조금 불만입니다. 조금 딱딱한 느낌이 옵니다. 그때그때의 상황에 적절한 가상의 시나리오로 처리하고 결론을 도출한다면 좀더 쉽게 와닿을수 있을것 같아요. 예를들면 존고든의 에너지버스나 마케팅의 천재가된 맥스 같은 책을 보면 가상의 인물이 처하는 상황에 대한 문제들에 대해 해결책을 제시함으로써 저자가 이해시키고자 하는 결론을 독자가 쉽게 이해할수있도록 진행해 주는 부분이 있습니다.물론 그런류의 책과 분야가 좀 다른건 인정하지만 향후 그러한 시나리오로 e-learning등 다양한 컨텐츠로도 제작이 되길 바라는 마음에 몇자 적어 봤습니다.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.04.07 21:01 신고  댓글주소  수정/삭제

      논증은 epilog에만 있습니다. 전체적인 집필 의도를 밝힌 부분이기 때문에 그렇습니다. 본문의 내용은 그렇게 딱딱하지 않습니다. 자기개발서의 특징이 감성을 자극하는 면이 있습니다. 하지만 논리가 약한 면도 있지요. 논리와 논증을 익히시려면 입문서로 '논증의 탄생'을 읽어 보시기 바랍니다.
      조언에 감사드립니다.

  8. baind 2010.04.07 15:13 신고  댓글주소  수정/삭제  댓글쓰기

    책의 출판을 축하드립니다. 귀한 책 누구보다도 즐거이. 그리고 깊게 읽을 것을 약속드립니다.^^
    4월20일 그날이 기대 되는군요^^
    수고많으셨습니다. ㅎㅎ

  9. 눈팅독자 2010.04.08 21:27 신고  댓글주소  수정/삭제  댓글쓰기

    항상 오동규님의 블로그에서 좋은 정보를 얻어 가고 있는 많은 오라클 스터디생중에 한명입니다. 책 출간 진심으로 축하 드립니다. logical optimizer에 대한 내용에 너무 목말라 있었습니다. 반드시 구입해서 토시 하나 빼지 않고 완독 하며 공부 하겠습니다. 감사합니다.

  10. 봉봉아빠 2010.04.10 21:02 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 비법서를 내놓으심을 진심으로 축하드립니다. 튜닝이라고 수박 겉핥기만 하던 저에게는 가뭄 속 단비같은 보물입니다. 꼭 구입해서 수박 속 까지 싹싹 비워 먹도록 하겠습니다 ^^

  11. Favicon of http://imnews.tistory.com BlogIcon XOXOSQL 2010.04.11 08:49 신고  댓글주소  수정/삭제  댓글쓰기

    드디어 책이 나오는군요

    작가 친필사인 이벤트 같은건 안하시나요? ^^

    수고하셨습니다.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.04.13 01:21 신고  댓글주소  수정/삭제

      안녕하세요. 오동규 입니다.
      출간세미나를 하려고 했지만 허리가 별로 좋지 않아서 힘들것 같습니다.
      방문과 성원에 감사드립니다.

  12. Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.04.21 12:52 신고  댓글주소  수정/삭제  댓글쓰기

    한가지 주의사항은 초보자가 띠지 내용에 혹 해서 사면 안된다는 것입니다. 초보자 용이 아니기 때문입니다. 하지만 이 블로그의 구독자라면 충분히 보실 수 있을것 입니다.

  13. 김시연 2010.04.23 16:33 신고  댓글주소  수정/삭제  댓글쓰기

    책 출간을 진심으로 축하드립니다~! Preview만 봐도 얼마나 많은 정성과 노력을 투자하셨는지 잘 알겠네요. 그리고 논증의 탄생이란 책도 구매를 해봐야겠습니다. ㅎㅎ 그럼 주말 잘보내세요~!

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.04.23 16:57 신고  댓글주소  수정/삭제

      감사합니다.
      시연님께서 좋은 평가를 해주시니 부끄럽습니다.
      출간을 하고나니 아쉽기도 하고 그렇습니다.
      좋은 주말 되세요.

  14. 로또 2010.05.16 09:11 신고  댓글주소  수정/삭제  댓글쓰기

    너무 많이 늦었지만 출간을 축하드립니다.
    오랜 고통이 결실을 보셨군요.

    글 끝부분에 1인 4역하셨다는 부분...
    정말 어마어마한 노력과 인내심에 감탄을 금할 수 없습니다.
    제일먼저 건강부터 챙기셔야겠네요.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.05.17 00:21 신고  댓글주소  수정/삭제

      로또님 반갑습니다.
      일요일임에도 불구하고 방문하셨네요.

      한방쿼리의 댓글 의견은 저도 공감합니다. 노스트라 다무스도 미래를 맞추지 못한것 같습니다. 하지만 아쉽게도 ERP 패키지를 설계하는 분들 중의 일부가 유지보수를 생각하지 않는 경우가 가끔 있었습니다.

      다행히 허리는 출간직후에 좋아졌습니다.
      저처럼 오래 않아 계신분들은 하루에 한번의 가벼운 체조가 도움이 된다고 합니다.
      감사합니다.

  15. Favicon of http://blog.naver.com/david2kim BlogIcon [리베™] 2010.05.24 12:36 신고  댓글주소  수정/삭제  댓글쓰기

    수요에 비해서 책을 너무 조금 출판하신게 아닌지??
    일이 있어서 나갔다가 서점에서 직접 구매하려고 하니, 생각보다 쉽지 않더군요.
    대형 서점 3곳을 뒤진 후에야 허탕을 치고, 예약을 해서 다음날 방문해서 받았습니다.
    아무래도 좋은 내용의 도서인 만큼 수요자분들이 많은듯 합니다.
    항상 블로그 글귀들을 보면서 많은 도움들을 받았었는데... 이번 도서를 통해서 또 한번 정리를 하는 기회를 갖게
    되는 것 같습니다. 대박나시길 기원합니다. 감사합니다.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.05.24 15:51 신고  댓글주소  수정/삭제

      제 책을 구하기 위해 고생을 많이 하셨네요.
      참고로 오픈메이드는 오프라인 서점중에는 교보문고와 반디앤루니스만 거래합니다. 아마 리브로나 영풍문고를 가신듯 합니다.

      그리고 리베 tm님 말씀처럼 수요예측을 잘못한것 같습니다. 회사에서 이 추세 대로 라면 3~4개월 후에 재고가 바닥 날것 같다고 하더군요. 너무 빨리 절판 되는 것이 아닌지 걱정입니다.

      솔직히 옵티마이져라는 주제가 너무 무겁고 어려운 내용이라 수요가 이렇게 많을지 예측하지 못하였습니다.
      여러가지로 수고를 끼쳐드려 죄송합니다.

  16. 김시연 2010.06.11 10:44 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요~. 외부 컨설팅 수행하고 어제 회사에 복귀했습니다. 컨설팅시에 환경이 11gR2였는데 Logical Optimizer책이 많은 도움이 됬습니다. 늦었지만 감사 인사드립니다.~ 그럼 주말 잘보내세요.

  17. 2010.12.22 11:08  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.12.22 11:17 신고  댓글주소  수정/삭제

      반갑습니다.
      우선 책의 예제는 HR 과 SH 스키마를 이용한 것 입니다. 말씀하신 예제는 hr 스키마 입니다. hr 에 있는 COUNTRIES 테이블은 sh에 있는것과 다릅니다. 왜냐하면 IOT로 되어 있기 때문입니다. 테이블 자체가 인덱스의 몸체이므로 테이블을 방문하지 않아도 됩니다.

      즐거운 성탄절 보내시기 바랍니다.
      감사합니다.

  18. Favicon of http://blog.naver.com/darkturtle BlogIcon 타락천사 2010.12.22 14:37 신고  댓글주소  수정/삭제  댓글쓰기

    역시나... 감사합니다.

  19. Favicon of http://www.perfectreplicawatch.co.uk/ BlogIcon wrist watches 2011.08.06 16:33 신고  댓글주소  수정/삭제  댓글쓰기

    항상 책에 대한 갈증이 있지만 막상 서점에 가보면
    딱히 손에 잡히는 책은 별로 없더라구요.

  20. Favicon of http://bestshoppingbox.com BlogIcon Air Jordan Shoes 2011.11.18 00:17 신고  댓글주소  수정/삭제  댓글쓰기

    Glad to visit your blog. Thanks for great post that you share to us!

  21. Favicon of http://www.minnikesko.dk/ BlogIcon Nike Shox sko 2012.03.30 11:36 신고  댓글주소  수정/삭제  댓글쓰기

    Glad to visit your blog. Thanks for great post that you share to us!

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

댓글을 달아 주세요

  1. Favicon of http://lemonfish.egloos.com BlogIcon killy 2009.10.30 00:01 신고  댓글주소  수정/삭제  댓글쓰기

    끄어... 오늘 포스팅 하나 하나 볼때마다 놀라게 되고 제 무식함에 치가떨리는군요. NUMBER 가 정밀도에 따라서 이렇게 차이가 나는 줄은 오늘 처음 알았습니다. ㄷㄷㄷ

  2. 떠비 2010.02.09 15:04 신고  댓글주소  수정/삭제  댓글쓰기

    관련글 보다가 추천책들을 보게되었습니다. 책은 예전에 학원에서 준책인데, 튜닝초기교육인데 이책을 주면서 이건 지금 보면안된다고 하면서 개별진행을 했었지요. 아직도 튜닝의 튜자도 시작안했지만, 이책이라도 꼭 완독해야겠습니다.
    다른 포스팅하시는글들은 이미 튜닝경력이 있는 분들에 대한 이슈제공(?)류라 제가 보기에는 아주~~ 힘드네요.

    감사합니다. 이제는 자주 들르겠습니다.

  3. 이재훈 2010.08.28 03:11 신고  댓글주소  수정/삭제  댓글쓰기

    우연히 발견하고 난 뒤에 참 배울 것이 많다고 생각이 들었습니다.
    앞으로도 자주 들러서 많은 부분에서 고민하고 많이 배울 수 있는 교류의
    장이 될 거 같네요..

    감사합니다. 자주 들를께요..

예전에 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

댓글을 달아 주세요