Embed Size (px)
Citation preview
The Logical Optimizer
● 저자 오동규E-mail: [email protected]
Blog: Science Of Database(http://scidb.tistory.com)
Blog ID: extremedb
홍익대학교를 졸업하고 오픈메이드 컨설팅의 수석컨설턴트로 재직 중이며 DA(Data Architect)를 맡고 있다. 데이터베이스의 과학과 예술을 널리 전파하는 것을 모토로 삼고 있으며 기업은행, 서울보증보험, 수협, 농협에서 데이터모델링과 DBMS튜닝 컨설팅 및 교육을 수행하 다.
월간 마이크로 소프트웨어에 DBMS와 관련된 고급원서의 서평을 다수 기고하 다. 저자의 블로그를 방문하면 과학(DBMS)과 예술(데이터 모델링)에 관한 깊이 있는 이야기를 공유할 수 있다.
The Logical Optimizer
성능향상을위한트랜스포머의 SQL 재작성전략
Copyrightⓒ 2010 by Dongkyu OPrinted in Republic of Korea
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic ormechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior writtenpermission of the copyright owner
초판1쇄 발행 | 2010년 월 일
지은이 | 오동규
출판사 | ㈜오픈메이드컨설팅, www.openmade.co.kr
출판사 주소 | 서울특별시마포구공덕동 426-19 동우빌딩 202호
출판사 전화 및 팩스 | TEL 02-714-3702, FAX 02-714-3703
표지디자인 | 김지혜
내지디자인 | NTIME 디자인팀팀장이정숙
ISBN 978-89-963840-0-7 93560
값 | 39,000원
이 책은 저작권의 보호를 받으며 저자의 허락 없이는 어떠한 형태의 번역이나 번안, 유포, 복사, 출판, 게재, 디지털 매체로의 저장 및 전송,촬 , 녹음도 할 수 없습니다.
태초에어둠과혼돈이존재했다. 이제암흑과같은세계에동이트려한다.
Introduction
화 <아바타>에는 혼의 나무를 통하여 생명체와 교감하며 평화로운 생활을 위하는 판도라 행성의
나비족이등장한다. 하지만이행성의광물에눈이먼지구인들은무력을통해이들을짓밟게되고, 인간
의탐욕에치를떤지구인제이크셜리는인간을등지고나비족의편에선다. 하지만그과정에서나비족
의 신뢰를 받지 못한 제이크는 무모하게도 나비족 역사 이래 5번밖에 소유하지 못했던 전설의 드래곤인
토르쿠막토를획득하려는불가능한시도를하게된다. 천신만고끝에얻어낸토르쿠막토는모든상황을
급 반전시킨다. 결국 그는 토르쿠 막토의 힘을 빌려 나비족의 새로운 지도자가 되고 인간과의 전쟁을 승
리로이끈다.
토르쿠막토, 우리가가질수있나화가 아닌 현실에서도 모든 상황을 한번에 해결할 만한 토르쿠 막토 같은 위력적인 무기를 가질 수
있을까? 지금부터그것을손에넣었던필자의경험담을소개한다.
2006년 늦은 가을이었던가? 필자는 새로운사이트에투입되어 DBA들과 튜닝중에있었다. 개발자들
이 튜닝을 의뢰하면 먼저 DBA들이 튜닝을 실시하고, DBA가 해결하지 못하는 SQL은 필자에게 튜닝 요
청이 들어온다. 하지만 그 당시 한 달이 넘게 DBA들과 필자가 튜닝 작업에 고심하 음에도 요청되는 튜
닝 건수에 비해 해결되는 건수가 턱없이 부족했다. 베테랑 DBA가 3명이나 있었음에도 불구하고 해결되
지않는 SQL의건수는계속해서쌓여가고있었다.
한 달째인 그날도 밤 12시가 넘었지만 퇴근하지 못했으며 이것이 어쩔 수 없는 컨설턴트의 숙명이거
니 하는 자포자기의 심정이 들었다. 새벽 한 시가 되어 주위를 둘러보니 사무실엔 아무도 없었다. 얼마
후건물전체가소등되었고모니터의불빛만이남아있었다. 암흑과같은공간에서한동안적막이흘 다.
바로 그 순간 요청된 SQL에는 일정한 패턴이 있지 않을까 하는 생각이 번쩍 들었다. 갑자기 든 그 생각
으로 필자는 퇴근할 생각도 잊은 채 SQL에 대한 패턴을 분석하기 시작했다. 그리고 몇 시간 후 동틀 무
렵, 놀라운결과를발견할수있었다.
필자에게 튜닝을 요청한 SQL의 많은 부분이 Query Transformation(이하 QT) 문제 다. 즉 Logical
Introduction 005
The Logical Optimizer
Episode
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년 현재도 마찬가지이다). 필자는 다음날부터 3
일간튜닝을전혀하지않기로마음먹었다. 대신에 DBA들에게 Logical Optimizer에 대한교육을하기로
작정했다. 필자의 입장에서는 교육을 진행하지 않아도 그때까지 쌓여있는 튜닝 이슈만 해결하면 프로젝
트를 마무리 할 수 있었다. 하지만 열정 때문인지 아니면 윤리적 의무감이 원인인지 모르겠으나 교육을
진행하지않은상태에서프로젝트를끝낼수없다고생각하고있었다.
난관다음날 필자는 DBA들과 담당 책임자를 불러서 교육에 관한 회의를 하 다. 책임자는 삼 일간 18시간
의교육때문에튜닝실적이거의없게되므로교육은불가능하다는것이었다. 업무시간중교육을하게됨
으로 필자 뿐만 아니라 모든 DBA들의 튜닝실적이 없게 되는 것이다. 책임자와 DBA들은 해결되지 않는
튜닝문제의대부분이 Logical Optimizer 때문이라는사실을필자의분석자료를통해알고있었다. 하지만
책임자는상부에튜닝실적을보고해야되는처지 으므로교육은불가하다고하 다.
필자는 교육 후에 가속도가 붙을 것이므로 실적을 충분히 따라잡을 것 이라고 책임자를 설득하 다.
그는 실적 대신에 교육후에 향상된 DBA들의 문제 해결능력을 상부에 보고하겠다고 하 다. 다행스러운
일 이었다. 그런데 이번에는 DBA들이 교육을 완강히 거부했다. 그들은 튜닝이외에 Database 관리업무
도 진행해야 하는데 삼 일의 교육기간중 업무를 처리하지 못하게 된다는 것이었다. 따라서 교육 후에 밤
을 세워서라도 린 업무를 수행해야 되는 처지 으므로 교육을 부담스러워 했다. 또한 Logical
Optimizer의 원리보다는고전적인튜닝방법을신뢰하고있었기때문에며칠간의교육으로문제가해결될
006
지모두가의심하고있었다.
필자는강한반대의견때문에‘억지로교육을해야하나?’라는생각이들었다. 마지막이라는심정으
로 설득의 방법을 바꾸어 보았다. DBA들이 교육을 통해서 무엇을 얻을것인가(WIFM) 관점보다는 교육을
받지 못하면 손해를 보게될 상황을 설명 하 다. 즉 튜닝 프로젝트가 끝나고 필자가 나간뒤에도 같은 패
턴의 튜닝 문제가 발생할 것인데 지금 교육을 받지 않는다면 그때가 되어도 튜닝을 할 수 없을 것이라고
강조하 다. 또한업무시간후에교육을받으면시간을거의뺏기지않을것이라고설명하 다.
마침내 설득은효과를발휘했다. 업무시간을제외한저녁 7시부터 10시까지 총 6일간 교육을진행하
기로 모두가 합의하 다. 3일 간의 교육이 6일간의 교육으로 늘어지긴 하 지만 교육을 진행할 수있게
되었다는사실만으로도아주다행스런결과 다. 교육시간에실무에서가장발생하기쉬운 QT 기능들의
원리와 튜닝방법부터 설명하 다. 일주일의 교육을 마치자 곧바로 효과가 나타났다. 교육 후 필자에게
들어오는 튜닝의뢰 건수가절반으로 줄어든 것이다. 비로소 필자는정상적인 시간에 퇴근할수있게 되
었다.
기적은 필자에게만 일어난 것이 아니었다. 교육 이전에 DBA들은 밤 11시가 넘어서야 퇴근 하 다.
왜냐하면필자에게튜닝요청을하기전에성능이개선되지않는 SQL을 짧게는몇시간, 길게는며칠동
안 붙잡고 고민하다가 요청하기가 일쑤 기 때문이었다. 교육 이후로는 DBA들이 SQL을 보는 관점부터
달라졌으며필자가없어도 QT 문제를 스스로해결할수있는능력을갖게되었다. 기대 반 우려반의심
정으로 교육을 허락한 책임자의 얼굴에도 화색이 돌았다. 지난 수 년간 진행되었던 Logical Optimizer의
원리에대한연구가한순간에빛을발하고있었다.
그 사이트의 문제가 해결되고 얼마 후 지난 2년간 다른 프로젝트에서 요청 받았던 튜닝 문제를 같은
방법으로 분석 하 는데 원인 중 절반이 QT 문제 다. 이 같은 경험은 우리에게 시사하는 바가 크다.
어떤 문제로 베테랑 DBA들이 밤을 세우는지, 어떤 기술로 문제를 해결 할 수 있는지 혹은 어떤 기술이
고급 튜너로 가기 위한 것인지 알 수 있다. 혹시 당신이 속한 프로젝트에 DBA, 튜너 혹은 고급 개발자
들이 퇴근을 못하고 밤새 일하고 있다면 고심해 보라. Logical Optimizer의 원리가 상황을 반전 시킬수
있는지를. 의심해보라. 그 원리가토르쿠막토가아닌지를......
Introduction 007
무엇에관한책인가이 책은 고전적인 SQL 튜닝 책이 아니다. 옵티마이져의 기능 중 절반에 해당하는 Logical
Optimization에 대한책이다. Physical Optimization의 개념은최적의 Access Path를 결정하고최적의조
인방법과 조인순서를 결정하는 것이다. 혹자는 다음과 같이 질문할 것이다. ‘그게 옵티마이져의 전체 기
능 아닌가요?’하지만 과연 그럴까? 필자가 보기에 고급 DBA들이 튜닝에 실패하는 대부분의 경우는 바
로 이러한 고정관념에 얽매어 있기 때문이라고 생각된다. 이 책에서 그러한 생각이 왜 성능 문제를 일으
키는지자세히 설명할것이다. 이 책은 실전 튜닝시문제가 되는 Logical Optimizer에 대해서만 집중적으
로다루고있으므로일반적인튜닝서적과는차별화된다.
그렇다면 Logical Optimization이란무엇인가?Logical Optimization은 성능향상을 위해서 옵티마이져가 SQL을 재작성(튜닝) 하는 것으로 정의할 수
있다. 과거에는 개발자가 수동으로 SQL을 수정했다면 이제는 옵티마이져가 많은 부분을 자동으로 재작
성하게 되었다. 그래서 Logical Optimization을 Query Transformation이라고도 하고 Logical Optimizer는
Query Transformer라고도불린다. Query Transformer는 옵티마이져의 3대 Components 이다.
Logical Optimizer와 Physical Optimizer의 관계Physical Optimization은 Logical Optimization에 종속적인 개념이지 대등한 개념이 아니다. 왜냐하면
Logical Optimizer가 SQL을 성능향상의 목적으로 재작성하면 Physical Optimizer는 Logical Optimizer가
작성한틀(SQL) 내에서최적화할수밖에없기때문이다. 이것은마치삼장법사손바닥안의손오공을보
는듯하다. 물론손오공은출중한능력을가졌지만삼장법사의통제아래에서만발휘될수있는것이다.
Logical Optimization은 SQL 자체를 튜닝(변경) 하는 것이고 Physical Optimization은 튜닝된 SQL을 물리
적으로최적화하는것이다.
008
The Logical Optimizer
Introduction
Prologue
이책을통하여얻을수있는것1. 성능향상을위한 SQL 수정을튜너가아닌옵티마이져에게시키는방법
2. 변경된실행계획을정확히읽어내는능력
3. SQL과 Plan만 보고옵티마이져가 SQL을어떻게변경시켰는지알수있는능력
4. 튜닝에실패했던 SQL을튜닝할수있는능력
궁극적으로는옵티마이져를자유자재로 Control 할 수있는능력
집필의어려움2005년 봄부터 2008년 봄까지 Oracle10g 기준으로 상당한 작업이 진행되어 책을 출간할만한 자료
가축적되었으나모든지인들이 Oracle11gR1으로출간하기를원하고있었다. 필자는고민끝에그의
견을 수용하기로 결정 하 다. 결국 모든 테스트를 다시 할 수 밖에 없었다. Oracle11gR1에서 추가된
Logical Optimizer의 기능을 조사하여 분석하 다. 하지만 그것이 끝이 아니었다. 모든 집필 작업이 끝나
고 교정작업을 하고 있었지만 2009년 9월에 Oracle11gR2가 출시된 것이었다. 어쩌겠는가? 11.2의
기능들을추가할수밖에……
이책을출간한이유는세가지이며아래와같다.
첫번째이유 : DBA들이 SQL Transformation을 어려워해필자는 항상 프로젝트에서 DBA 혹은 컨설턴트들이 어려워하는 문제 혹은 튜닝에 실패한 원인을 기록
에 남기는데 이 기록을 가지고 5년간 통계를 내었더니 현장의 DBA나 컨설턴트들이 어려워하는 것은 대
부분 SQL Transformation 문제 다. 이 문제가해결되면필자의많은짐을덜수있으리라. 통계의자세
한결과는 Part 1의 1.2장을참조하라.
두번째이유 : 참조서적의부재Query Transformation 기능이 SQL을 직접 변경함으로써 SQL의 성능에 미치는 향은 지대하지만 전
세계적으로이것을전반적으로다룬서적이없다. 이래서는튜닝에실패할수밖에없는것이다.
세번째이유 : 향후발생할추가적인문제들Oracle11g R2에서 추가된 Join Factorization이라는 기능은 테이블을 반복해서 2번 Access 하게 되
는 SQL을 중복 테이블 제거와 SQL 변경으로 테이블 Access를 한번으로 줄여버리는 것이다. 과거에는
Introduction 009
이런작업을튜너가직접하 으나이제그것은옛말이되어버렸다. 이러한기능들이대폭추가되었지만
DBA나 튜너들이 Logical Optimizer를 Control 할 수 있는 능력은 제자리 걸음이다. 기능이 많아질수록
이러한 Gap은더욱커질것이다.
선구자적시도이유 1~3에의해서많은사람들이이주제에대한참조서적이나오길기대해왔을것이다. 이러한묵
시적인요구에 의해서세계 최초로 Logical Optimizer에 대한 책이 나오게되었다. 이러한 선구적인작업
들이 곧 Database 탄생지인 미국을 포함한 전 세계의 Oracle 유저 수준을 업그레이드하는 발판이 될 수
있을것이다. 그러한발전에조금이나마이바지한다면필자로서는더없는기쁨이겠다.
2010년 1월눈이오는새벽어느연구실에서오동규
010
Introduction
아들로서 생전에 효도를 하지 못했다. 하늘나라로 가신 아버님에게 이 책을 바친다. 못난 아들에게 언
제나 무한대의 사랑과 모토를 주시는 어머님께 감사드린다. 집필기간 내내 컴퓨터만 바라본 남편을 묵묵
히 지켜봐 준 사랑하는 아내와 딸 유림이에게 이 책을 바친다. 책이 출간되면 그 동안 못다한 가족 사랑
을시작해야겠다.
집필기간 내내 지원을 아끼지 않은 최 철 오픈메이드 대표님께 감사드린다. 이분께서는 저자에게 기
회와 용기라는 선물을 주셨다. 평소 구상하시던 모델링 책이 빨리 나왔으면 좋겠다. 모델링 세계의 만고
의 진리를 사내에 전파하셨듯 세상에 전파하셨으면 한다. 바쁜 일상 중에도 따로 시간을 내어 디자인과
출판을 총괄해주신 김기호 오픈메이드 사업관리 본부장님께 감사드린다. 책이란 내용도 중요하지만 출판
이라는 절차가 없이는 독자와 절대로 만날 수 없을 것이다. 그런 면에서 이 책을 독자와 연결시켜 주신
분이다.
사내 컨설턴트 여러 명이 이 책의 Technical Reviewer가 되어 주었다. 무릇 책이란 독자들을 위한 것
이다. Technical Reviewer들은 독자의 관점에서 철저한 검증을 해주었다. 이들이 아니었더라면 필자의
좁은관점에한정된책이나왔을것이다. Review의 총괄을맡아준금은섭수석에게감사의말을전한다.
그는나의절친한벗이자라이벌이다. Technical Reviewer들 중에신정아수석, 지용식수석, 최상운수
석, 김중국 책임, 이지용 책임, 전만기 책임, 곽은호 선임에게감사드린다. 그들은 어려운교정작업을간
단하게할수있게도와주었다. 특히이지용책임의지원으로버전 11.2의 새기능을쉽게연구할수있
었다.
농협 IT분사 전태민부장님과인프라팀의김유경팀장님그리고 DA를 총괄하셨던이용호과장님과모
든 DBA분들께 감사드린다. 이분들은 필자에게는 전우와 같다. 지난 2년 6개월간 생사고락을 같이 하
다. 같이 프로젝트를 진행할 기회를 가진 필자로선 광일 따름이다. 마지막 까지 독자의 입장을 대변해
주신 Database 책임자인장석후과장님, 소속 DBA 송재천과장님, 이석상계장님, 김동진계장님, 이재
진주임님, 강현구계장님에게감사드린다. 그리고고객팀에서모델링을함께진행한장마리차장님과변
비호과장님께감사드린다.
Introduction 011
The Logical Optimizer
감사의
한국 오라클의 조상환 부장님 이하 노종수 차장님, 박준용 차장님, 이상화 차장님께 감사드린다. 이분
들은바쁜와중에도틈틈이시간을내어독자의입장으로내용을교정하는데많은도움을주셨다. 이분들
의높은안목은이책을쓰는데많은도움이되었다.
디자이너 김지혜님께 감사드린다. 이 책의 독특한 Concept을 잘 살려서 표지 디자인을 완성해 주셨
다. 첫번째 독자가 되어주신 이장미 대리님에게 감사드린다. 이분은 책에 관한 좋은 아이디어를 제공해
주셨다.
012
Introduction
이책은옵티마이져에대한책이다. 이책의난이도는중급및고급이다. 아래의조건을모두만족하는사람만이책을구입하기바란다.
-SQL 튜닝책을한권이상보았거나자신이작성한 SQL을튜닝한적이있다.
-기본적인실행계획을이해한다.
-옵티마이져에대하여배우고싶다.
위의 3가지 조건을만족한다면당신은이책을어렵지않게볼수있다. 하지만 아래의조건중에하나
라도해당된다면 SQL 프로그래밍책과기본적인 SQL 튜닝책을반드시읽은후에도전하기바란다.
-기본적인 SQL 문법을모른다.
-Nested Loop Join과 Hash Join을 각각어떤경우에사용해야하는지모른다.
-SQL의기본적인실행계획을이해하지못한다.
이책을읽어야할사람이 책을 구입하는 사람은 오라클을 사용하는 DBA, 중급 및 고급 개발자, DBMS의 성능에 관심이 있
는모델러나설계자, 튜너, DBMS 컨설턴트, Data Architect 등이될것이다. 또한 Oracle 이외의 DBMS
를 사용하는 DBA라면 Oracle의 SQL Transformation 기능과 타 DBMS의 SQL Transformation 기능을
비교해볼수있는기회가될것이다.
대학교에서이내용을강의하거나공부하려면기본적인 SQL과 실행계획을아는상태에서진도를나가
는것이무난하다. 따라서석사이상의과정에서다루는것이적절할것이다.
Introduction 013
The Logical Optimizer
누구를위한책인가?
이책을순서대로보기바란다. 앞에서정의한용어가뒤에서계속나오므로건너뛰고읽게되면용어
를 알지 못한다. 다음으로 이 책을 효율적으로 보기 위한 두 가지 방법과 집필 시 사용된 Oracle의 세부
버전을소개한다.
1) 책을빠르게한번읽고두번째는정독하라튜닝을전문적으로하지않는독자들을위한방법이다. 이 책을빠르게읽는방법을소개한다.
각 Part의 첫 부분(들어가기)를 정독하라. 들어가기는각 Part에서 어떤 것을배울것인지, 어떻게 하면
효과적으로공부할수있는지에대한정보가있다.
Part 1중의 1.7장(10053 Event Trace에 대한 개념을 분석한 부분)은 Skip 하라. 그것을 제외하면
어려운개념이없으므로빠르고쉽게읽을수있다. Part 2와 Part 3의 내용중에 10053 Trace를 분석
한부분은 Skip 하라. 해당 장의 Query Transformation의 개념과원본 SQL, 수정된 SQL 그리고각각의
실행계획만이해한다면목적을달성한것이다. 하지만, 각 장의마지막에있는힌트와파라미터는실전튜
닝에서 필요하므로 정독해야 한다. Part 4는 가장 어려운 내용들로 이루어져 있다. 반드시 Part 1~3를
순서대로보고나서 Part 4를 보기바란다. 초보자의경우 Part 4를 Skip 하기바란다.
Part 2~Part 4까지는 마지막 부분에 핵심을 정리한 장이 있다. 이 부분을 정독하고 다음 파트로 넘어
가기바란다.
이렇게 해서 한번을 빠르게 보았다면 다시 읽을 때는 모든 부분을 정독하더라도 막히는 곳 없이 빨리
볼 수 있을 것이다. 왜냐하면 이미 독자는 전체적인 개념뿐만 아니라 세부적인 상세개념까지 다 알고 있
는상태에서다시보는것이기때문이다.
014
The Logical Optimizer
Introduction
책을효율적으로Master 하는방법
2) 자신있는독자는모르는부분을파고들어라자신 있는 사람들에게는 당부할 말이 따로 없다. 이미 알고 있는 부분은 복습차원에서 빠르게 읽고 지
나가면된다. 하지만모르는부분이조금이라도발견되는경우는정독해야한다.
3) 오라클의버전은 11g집필시 사용된 버전은 Oracle11g 11.1.6.0 이다. 2010년 이후로는 Oracle11g가 대세가 될 것이
고 Oracle11g에서 새롭게 추가된 기능이 있기 때문에 Version11을 선택하 다. 각 장에서 Oracle
11gR1및 11gR2에서 새로 나온 기능은 별도로 언급을 하 으므로 Oracle10g에서 수행될 수 있는
Query Transformation을 어렵지 않게 구분할 수 있다. 11gR2에서 새로 나온 기능은 11gR1에서 수행
되지 않는다. 따라서 모든 예제를 직접 수행해 보려면 Oracle11g 11.2.0.1 이상의 버전으로 사용하기
바란다.
두번째는자기것으로만들어야해Part 1~4를 여행하는 동안 별 어려움이 없었던 독자는 Logical Optimizer의 전문가가 되기 위한 준비
를마친것이다. 하지만어려움이없었던독자라할지라도한번더보기바란다. 두 번째읽는경우는첫
번째와 비교해서 또 다른 관점이 있음을 알게 될 것이다. 첫 번째는 단순히 지식을 습득하는 과정이지만
두 번째는 그것을 자신의 것으로 만드는 과정이 될 수 있다. 만약 세 번째 읽게 된다면 각각의 기능들을
실무에어떻게적용할것이며예전에튜닝에실패했던원인들을다시돌아볼수있는기회가될것이다.
다독이중요한번 읽기가 힘들었던 독자들은 걱정 하지 않아도 된다. 한번을 읽었을 때 느끼는 어려움은 두 번, 세
번을 읽으면서 없어지기 때문이다. 튜닝 초보자의 경우 정독 1번보다 빠른 다독이 필요하다. 필자 또한
이런반복과정을무수히거쳤다. 심지어같은책을 5번이상본적도있다.
10053 Trace 분석력이책은 10053 Trace 분석능력을키워줄것으로확신한다. Part 1에서기본적인분석법에대하여설
명하 으며 Part 2와 3에서 구체적인 예제들을 통하여 설명하 다. 또한 Part 4를 보고 나서 다시 책을
본다면 10053 Trace를 보는느낌이다를것이다.
Introduction 015
모르면악당알면지원군실제로 Query Transformation은 여러 가지 성능 문제를 일으키기도 한다. 하지만 독자가 위의 과정을
마친다면 SQL만 보아도 어떤 종류의 Transformation이 적용될 것인지 내부적으로 Logical Optimizer가
어떤 전략을 선택할지, 어떤 연쇄반응이 일어날지, 메모리의 어떤 부분을 사용하게 될지 모두 파악하게
될것이다. 이것이야말로오라클( 화 메트릭스중)의 눈을가진삼장법사(고전서유기중)의 경지가아닐
까? 그 경지에가까이갈수록 Logical Optimizer는 독자에게든든한지원군으로거듭태어날것이다.
016
Introduction
이책은 Part 1 ~ Part 4로 구성되어있다
1. Part 1은 Part2~ Part4를 보기전에필요한개념과기술및중요성을설명한다.
2. Part 2는 고전적인 Heuristic(Rule Based) Query Transformation에 대하여설명한다.
3. Part 3은 Oracle10g에서 처음 소개된 기술인 Cost Based Query Transformation에 대하여 설명
한다.
4. Part 4는 Cost Based Query Transformation의 내부와숨겨진원리및 Logical Optimizer의 전략에
대하여논의한다.
Part 2와 Part 3의 구성1. 각 장의제목은 Query Transformation의 용어와개념을간략히설명한것이다.
2. 제목이끝나면상세한개념을설명한다.
3. 개념설명이끝나면변환되지않은 SQL과그에따른실행계획을설명한다.
4. 연이어 변환이 수행된 SQL과 실행계획이 설명된다. 여기까지가 핵심이다. 각 장에서 4번 까지만
보아도해당장에서설명되는 Query Transformation의 개념을이해할수있다.
5. SQL에 대한 설명이 끝나면 Query Transformation이 왜 수행되었는지, 수행 과정은 어떤지에 대한
분석과정을기술한다. 이 과정에서 10053 Trace가 분석도구로사용된다.
6. 10053 Trace의 분석이 끝나면 해당 Query Transformation을 Control 할 수 있는 파라미터와 힌
트를설명한다.
대부분의 경우 Part 2와 Part 3의 각 장은 1번부터 6번까지의 순서로 구성된다. Part 1과 Part 4는
위와같은특별한구성이없다.
약어표기법설명Part 2 ~ Part 4의 각장에는제목이있다. 대부분의경우제목에는약어가있으며약어에 *가 붙어있
는 경우가 있다. *가 붙은 이유는 오라클사에서 이용하는 적절한 약어가 없음으로 Full Text에서 첫 자
만따서약어를만든것이다. 따라서 * 가 붙어있지않은것은오라클사의약어이다. 예를들면아래는 *
Introduction 017
The Logical Optimizer
책의구성
가붙어있는 3.1장의제목이다.
3.1 CBPPD*(Cost Based Predicate Push Down): Complex View에 Filter를 어넣어라
예제스크립트Science of Database(http://scidb.tistory.com)에 접속하여 The Logical Optimizer 카테고리의 Script
Download를 선택하면된다
혹시라도 오탈자나 오류들을 발견하면 모든 독자들을 위하여 필자의 블로그에 알려주기 바란다.
Science of Database(http://scidb.tistory.com)에 접속하여 The Logical Optimizer 카테고리의오타와오
류등록을선택하고댓 을남기면된다.
주의사항이 책에서는 수많은 파라미터와 힌트들을 변경해가면서 사용한다. 운 중인 시스템에 문서화 되지 않
은힌트나파라미터를절대수정해서는안된다. 문서화된파라미터도마찬가지이다. 만약수정하고싶다
면오라클사의검증을받은후충분할만큼의테스트를해보아야한다. 이 책에서사용되는힌트또한마
찬가지이다. 테스트가 아닌 실제 운 하는 시스템에서 힌트의 사용은 어떠한 경우에도 신중하게 시도되
어야한다.
018
Episode | 005
Prologue | 008
감사의 | 011
누구를위한책인가 | 013
책을효율적으로Master 하는방법 | 014
책의구성 | 017
Query Transformation Concept
들어가기 | 024
1.1 Logical Optimizer(Transformer)란 무엇인가 | 025
1.2 Query Transformation을 알아야하는이유 | 027
1.3 Query Transformation의 개념 | 031
1.4 Query Transformer의 구조 | 033
1.5 DBMS_XPLAN.DISPLAY_CURSOR | 037
1.6내가사용한 Hint가 무시되는이유 | 045
1.7 10053 Event Trace | 054
Heuristic Query Transformation
들어가기 | 068
2.A Heuristic Query Transformation이란? | 069
2.1 CSE(Common Subexpression Elimination) :
Where 절에서 or 사용시중첩된조건절은제거하라 | 071
2.2 JE(Join Elimination) :
직접사용하지않는테이블은 SQL에서삭제하라 | 073
2.3 OE(Outer Join Table Elimination) :
불필요한 Outer쪽 테이블은삭제하라 | 077
2.4 OJE(Outer-Join Elimination) : 의미 없는 Outer 조인을
Inner 조인으로바꾸어라 | 080
2.5 OBYE(Order By Elimination) :
불필요한 Order By를 삭제하라 | 084
2.6 DE(Distinct Elimination) : 불필요한 Distinct를 제거하라
| 086
2.7 CNT(Count(column) To Count(*)) : Count(컬럼) 사용시
해당컬럼이 Not Null인 경우 Count(*)로 대체하라 | 091
2.8 FPD(Filter Push Down) : 조건절을뷰내부로이동시켜
라 | 093
2.9 TP*(Transitive Predicate) : 조인절을 이용하여 다른 테
이블에상수조건을생성시켜라 | 097
2.10 SVM(Simple View Merging) : Simple View를 해체하
여메인쿼리와통합하라 | 100
2.11 LV*(Lateral View) : View를 Scalar 서브쿼리처럼 사
용하라 | 104
2.12 FOJC*(Full Outer Join Conversion) : Full Outer 조인
을 Union All로 변경하라 | 112
2.13 NFOJ*(Native Full Outer Join) : Full Outer 조인시 중
복 Scan되는테이블을제거하라 | 117
2.14 OT*(Operator Transformation) : 특정 연산자를 다른
연산자로변환하라 | 119
2.15 PM(Predicate Move Around) : Where 조건을 다른
뷰에이동시켜라 | 123
2.16WCOTR*(Where Current Of To Rowid) : Where
Current Of 를 사용하여 Index Scan을 회피하라 | 127
Heuristic Query Transformation for Subquery
2.17 SSU(Simple Subquery Unnesting) : 단순 서브쿼리를
조인으로바꾸어라 | 132
2.18 CRSW(Correlated Removal Subquery Using
Part 1
Part 2
Contents
Window Function) : 상관서브쿼리를사용할때분석함수를
사용할수있는경우서브쿼리를제거하라 | 138
2.19 URSW(Uncorrelated Removal Subquery Using
Window Function) : 분석함수를 사용할 수 있는 경우 비상
관서브쿼리를제거하라 | 142
2.20 SJ(Semi Join) : 서브쿼리를 Semi 조인으로 변환하라
| 145
2.21 AJ(Anti Join) : 부정형 서브쿼리를 Anti 조인으로 바꾸
어라 | 151
2.22 ANTI NA(Anti Join Null Aware) : Null 허용 컬럼으로
서브쿼리와조인시 Anti 조인이가능하다 | 156
2.23 OJTAJ*(Outer Join to Anti Join) : Outer 조인을 Anti
조인으로변환하라 | 160
2.24 EJE*(Enhanced JE) : Semi / Anti 조인과 ANSI Style
로 조인할경우도 JE가가능하다 | 164
2.25 JESJ*(Join Elimination Using Self Join) : Self Join 사
용시에도 JE가가능하다 | 168
2.26 SSTS*(Scalar Subquery To Subquery) : 스칼라 서
브쿼리를서브쿼리로변환하라 | 172
2.27 SQC(Subquery Coalescing) : 불필요하게 분리되어
있는서브쿼리를하나로통합하라 | 177
2.28 DSJ(Driving Semi Join) : Semi Join을 Bitmap 인덱스
를이용하여 Driving 테이블로바꾸어라 | 181
2.29 SJR*, AJR*(Hash Join Right Semi/Anti) : Hash
Semi/Anti Join 시 사용되는 서브쿼리 집합을 Build Input 집
합으로변환하라 | 188
Heuristic Query Transformation for Data Warehouse
2.30 PC*(Pivot Conversion) : Pivot 절을 Case + Group
By로 변환하라 | 194
2.31 GBEP*(Group By Extension Pruning) : 불필요한
Rollup 이나 CUBE를삭제하라 | 198
2.32 GSTT*(Grouping Sets Using Temp Table) :
Grouping Sets 사용시 Temp 테이블에 적재후 이를 반복해
서이용하라 | 204
2.33 GSTU*(Grouping Sets To UNION) : Grouping Sets
를 UNION ALL로변환하라 | 207
2.34 GSTR*(Grouping Sets To Rollup) : Grouping Sets을
Rollup으로변환하라 | 211
2.B Part 2를 마무리하며 | 213
Cost Based Query Transformation
들어가기 | 222
3.A Cost Based Query Transformation이란무엇인가 | 223
3.B Search Type과 Iteration이란무엇인가 | 226
3.1 CBPPD*(Cost Based Predicate Push Down) :
Complex View에 Filter를 어넣어라 | 228
3.2 PPU(Predicate Pull Up) : 비용이 많이 드는 조건절을
뷰외부로이동시켜라 | 234
3.3 OR-Expansion(OR To Union All Conversion) :
OR 조건을이용하여 Union All로 변경시켜라 | 241
3.4 OR-Expansion Using Function*(NVL, DECODE,
RANK To Union All) : NVL, DECODE, RANK 함수를사용
한조건절을이용하여 Union All로 변경하라 | 249
3.5 TE(Table Expansion) : 여러 개의 파티션을 액세스 할
때파티션마다 Union All로 분리해서 Index scan을 할지
FTS를할지판단하라 | 255
3.6 SJC(Set To Join Conversion) : 집합연산을 조인으로
바꾸어라 | 260
3.7 CSU(Complex Subquery Unnesting) : 복잡한 서브쿼
리를조인으로바꾸어라 | 271
3.8 CVM(Complex View Merging) : Distinct나 Group By
가 있는뷰를해체하라 | 278
3.9 JPPD Union View : Union을 사용한뷰에조인조건을
침투시켜라 | 284
3.10 JPPD Union All View : Union All을 사용한 뷰에 조
인조건을침투시켜라 | 291
3.11 JPPD Outer Join View : 뷰에 Outer 조인을 사용한
Part 3
경우조인조건을침투시켜라 | 294
3.12 Multi Level JPPD : 뷰 내부에또다른뷰가있더라도
메인쿼리의조인조건을침투시켜라 | 298
3.13 JPPD Extension : Distinct 나 Group By, Semi/Anti-
join을 사용한뷰에조인조건을침투시켜라 | 304
3.14 GBP (Group By Placement) : Group By를 먼저 수
행하고 Join 하라 | 312
3.15 GBPD (Group By Push Down) : Parallel Query 수
행시 Group by를 한번더수행하라 | 315
3.16 JF(Join Factorization) : Union / Union All 사용시 공
통으로사용하는테이블을분리시켜라 | 319
3.17 ST(Star Transformation) : From 절의 Dimension 테
이블을 서브쿼리로 변환하고 DSJ 기능을 이용하여 Bitmap
연산을수행하라 | 324
3.18 CBST(Cost Based Star Transformation) : Star Trans
formation 적용시 Cost Based 환경을이용하라 | 330
3.19 MVR(Materialized View Rewrite) : Materialized View
를 사용하지 않는 SQL을 Materialized View를 사용하는
SQL로바꾸어라 | 336
3.20 JBE (Join Back Elimination) : Bitmap Join Index를
사용할경우필요없는테이블액세스를제거하라 | 341
3.C Part 3을 마무리하며 | 345
Cost Based Query Transformation Internal
들어가기 | 358
4.1 Search Type의 개념과종류 | 359
4.2 Search Type 분석에사용될 SQL | 364
4.3 Exhaustive Type 전략 | 367
4.4 Iterative Type 전략 | 371
4.5 Linear Type 전략 | 377
4.6 Two_Pass Type 전략 | 379
4.7 Off Option 전략 | 381
4.8 On Option 전략 | 382
4.9 State Space란 무엇인가 | 387
4.10 CA*(Cost Annotation)란 무엇인가 | 390
4.11메모리관리 | 393
4.12 Interleaving : 선 변환 과정이 끝나면 후 변환 과정을
연이어수행하라 | 395
4.13 Juxtaposition : 배타적인 변환을 동시에 고려하여
Cost가 낮은것을선택하라 | 398
4.14실무에적용하기 | 401
4.A Part 4를 마무리하며 | 404
부록과 색인
실무에서의 Query Transformation 이슈 | 407
미해결과제 | 416
Epilogue | 417
Bibliography | 421
Index | 424
Part 4
PART I
Query TransformationConcept
Part 1
Query Transformation Concept
들어가기 : Part 1의 목표는 Part 2와 Part 3를 배우기 위하여 Warming Up을 하는 것이다. 그러므로 Query
Transformer가 무엇인지 알아보고 Query Transformation이 중요한 이유를 설명하게 될 것이다. 한발 더
나아가서 Query Transformation의 목적과원칙그리고원리에대해서도상세히설명하게된다.
1.4장에서는 옵티마이져의 구조에 대해서 간략히 설명된다. 간략히 설명하는 이유는 Part 2와 Part 3
에서 구조도의 세부 내용에 대해 상세히 설명될 것이기 때문이다. 여기서는 전체적인 구조를 이해하는데
중점을두면된다. 하지만이장에서설명되는쿼리블럭의개념은아주중요하다.
Part 1의 후반부는 DBMS_XPLAN.DISPLAY_CURSOR 함수와 10053 Event Trace에 대해 배우게
된다. Part 2부터는이두가지 Tool로서 모든것을설명하게된다. 따라서 Part 1에서이 Tool들과 익숙
해질필요가있다. 1.6장은 Part 1에서실무적으로가장도움이될수있는예제를소개하 으니꼼꼼히
체크해보기바란다.
Query Transformation Concept | PART 1
오라클 Logical Optimizer(Transformer)란 옵티마이져의 가장 중요한 구성요소이며 성능향상을 위해
SQL을 재작성(Query Transformation)하는 역할을 담당한다. 개발자가 튜닝의 목적으로 SQL을 재작성
하는것이아니라오라클 Transformer가 SQL을재작성하는것이다.
SF 화 <트랜스포머>를 보면 Transformer가 등장한다. 자동차가로봇으로변환하는과정이그것이다.
자동차와 로봇간의 변환과정은 아주 현란하다 못해 황홀하여 시청자로 하여금 넋을 놓고 빠져들게 한다.
오라클의 Transformer도 이와비슷하게매우다이나믹하다.
변환과정이있어야지구를지킬수있어만약 이 화에서 자동차가 로봇으로 변환을 못한다고 상상해보자. 악한 로봇이 쳐들어와도 싸울 수가
없고 격렬한 전투장면도 사라진다. 이래서는 화가 재미도 없거니와 지구를 지킬 수도 없다. 그럼 오라
클에서 Query Transformer가 없어진다면어떻게 될까? 마찬가지로 Query의 상당부분을튜닝할 수 없게
되어전체시스템이느려지게된다.
오라클 Optimizer에서 Query Transformer는 3대 Components로서 아주 중요한 위치에 있다. 먼저
Query Transformer를 이해하기위해서 Optimizer의 구조를살펴보자.
[그림1.1.1] Optimizer 구조도
위의 그림을 설명하면 Query Parser가 SQL을 검사하여 넘겨주면 Query Transformer(Logical
PART 1 | Query Transformation Concept 025
The Logical Optimizer
1.1 Logical Optimizer(Transformer)란 무엇인가
Optimizer)가 SQL을 변신시켜서 Cost Estimator에 넘겨준다. 이때 Cost Estimator는 통계정보등을참조
하여 가장 낮은 Cost(비용)를 갖는 SQL을 찾아내어 Plan Generator에 넘겨주고 실행계획을 완성하게
된다.
화 Transformer에서 주인공 로봇의 변환과정은 아주 복잡하다. 하지만 소형 악당 로봇이 카세트 레
코더로 변환하는 과정을 유심히 보았는가? 이 과정은 매우 간단하다. 오라클의 쿼리변환(Query
Transformation) 과정도간단한것부터매우복잡한과정을거치는것까지다양하다.
026
Query Transformation Concept | PART 1
필자는 성능 컨설팅을 수행 하면서 튜닝이 가능한 개발자, DBA, DB 컨설턴트 등의 다양한 사람들과
같이 생활 하 다. 그러다 보니 자연스럽게 Process 비슷한 것이 생겨 났다. 먼저 업무 팀의 고급 개발
자가 튜닝을 하고 튜닝이 어려운 SQL은 DBA에게 SQL 튜닝을 의뢰한다. DBA가 대부분의 경우 튜닝을
잘하지만튜닝에실패할경우필자에게튜닝을의뢰하곤한다.
DBA들이튜닝에실패하는원인지난 5년간필자에게의뢰한모든 SQL들을분석하여통계를내보았다. 이 통계만잘살펴보아도 DBA
들이 왜 SQL 튜닝에 실패하는지 어떤 부분을 공부해야 고급 튜닝실력을 기를 수 있는지 분석 할 수 있
다. 이것은 필자 개인의 통계가 아니다. 왜냐하면 필자의 History에서 나온 통계이긴 하지만 5년간 무려
60명에 이르는 DBA/튜너/고급개발자들의 취약점에 관한 통계이기 때문이다. 통계의 표본을 60명이 아
닌 100명, 200명으로한다고해도비슷한결과가나올것이다. 통계의결과는아래와같다.
5년간의통계1위: Query Transformation에 대한지식부족(49%)
2위: Business 관점의접근부족, 정확한업무파악부족(25%)
3위: Wait Event에 대한지식부족(15%)
4위: 신기술에대한지식부족혹은두려움(8%)
5위: 잘못된액세스패턴, 잘못된조인방법, 잘못된조인순서(3%)
통계의 결과는 놀랍게도 절반(49%) 에 해당하는 경우가 Query Transformation을 제대로 이해하지 못
하여 SQL 튜닝에 실패한 경우이다. 이 문제만 해결되어도 필자에게 의뢰한 SQL의 건수가 절반으로 줄
어들게될것이다. Query Transformation이 그 동안필자를먹여살린셈이다. 이제 무엇이고급튜닝기
술이며 무엇부터 공부해야 하는지 알겠는가? 스스로에게 물어보자. 문제가 생겼을 때 그 문제에 대한 지
식도없고참조할수있는서적도없다면? 아마좌절할것이다. 이러한사실은위의통계치가나올수밖
에없는것을직접적으로증명하는것이다.
PART 1 | Query Transformation Concept 027
The Logical Optimizer
1.2 Query Transformation을 알아야하는이유
액세스 패턴, 조인 방법, 조인 순서 등은 중요하지만 결과는 3% 밖에 나오지 않았다. 숙달된 DBA들
은 이러한 방법들에 대해서는 이미 정통 했다는 것을 알 수 있다. 실제로 대부분의 SQL 튜닝 책들이 이
러한 방법에 입각해서 최근에도 출간되고 있다. 하지만 이러한 책들이 계속 출간된다고 해도 숙달된
DBA및 개발자들에게 미치는 향(3%)은 미미 할 것이다. 위의 통계는 5년간의 결과이다. 최근 2년간
(2008, 2009년)으로다시통계를내어보면더욱놀라운결과를얻을수있다.
최근 2년간의통계1위: Query Transformation에 대한지식부족(53%) 4% 증가
2위: Business 관점의접근부족, 정확한업무파악부족(26%) 1% 증가
3위: Wait Event에 대한지식부족(10%) 5% 감소
4위: 5위는동일함.
결과를 보면 Wait Event에 대한 지식 부족현상이 2년 사이에 5%나 해소되었음을 알 수 있다. 몇 년
전부터 전세계적으로 Wait Event에 대한 관심이 증폭되고 관련 서적들이 잇달아 나오고 있다. 이와 함께
DBA들의 OWI 지식은 빠르게 상승되었다. 이것은 매우 바람직한 현상이다. 실제로 DBA들의 책장에는
예외없이 OWI 관련서적들이나열되어있었다.
아쉬운것은최근에 OWI에 대한관심이증폭되어문제가많이해결되었지만 1위와 2위의자리는고정
적이라는 것이다. 그 중에서도 Query Transformation에 대한 지식 부족은 더욱 심각해졌다. 왜 그럴까?
그이유를 DBA들에게물어보았고대답은한결같았다.
1. 이 주제와관련된적절한교제가없습니다. 특히튜닝매뉴얼에는정보가거의없습니다.
2. 일부의 튜닝책에 몇 가지의 Query Transformation이 나와 있지만 그것으론 부족 합니다. (이 책에
서소개되는 Query Transformation의 종류는 50가지가넘는다.)
3. Physical Optimization에 대한 책은 몇 권이 있지만 Logical Optimization(Query Transformation)에
대한책은전무합니다.
위의세가지답변은비단한국만의문제가아니며전세계적인문제이다. 이러한문제는이책을만들
게된동기이기도하다.
흰수건을던질것인가? 고급DBA가튜닝에실패하여다른사람에게 SQL 튜닝을의뢰하는것은마치권투선수가시합을포기할
028
때흰색수건을링위로던지는것과같다. 게이머들은경기를포기할때GG(Good Game)를침으로서기
권을선언한다고한다. 당신이고급개발자이거나 DBA 혹은튜너라면 Logical Optimizer의 원리는이러한
상황을개선할수있는튜닝의비급이될것이다. 흰색수건이나GG는더이상당신의것이아니다.
이제는Optimizer다그동안오라클성능과관련된많은책들이출간되었다. 그것을시기별로정리하면다음과같다.
(2010년이후에출간이예상되는종류의책도함께정리하 다)
1. SQL의효율적작성법, Access Path, 조인, Object 최적화 (1990년대)
-1990년대는 튜닝의 기본이라 할 수 있는 SQL의 효율적 작성과 인덱스의 적절한 사용, 조인 최적
화, Object(테이블, 인덱스, 파티션) 최적화등의책이주류를이루었다.
2. OWI(Oracle Wait Interface), RAC (2000년대)
-1999년에 YAAP Method를 필두로 하여 2003년의 Method-R 등의 OWI를 이용한 Response
Time 튜닝방법론이완성되었고 RAC를이용하게됨에따라관련서적에대한관심이증폭되었다.
3. 2010년이후: 옵티마이져의내부에대한연구(Logical Optimizer, Physical Optimizer)
-2005년에 조나단 루이스에 의해 Physical Optimization에 관한 책이 최초로 집필되었다. 이 사람은
트랜드를 최소한 5년은 앞서간 사람이다. 하지만 안타깝게도 전 세계적으로 Logical Optimization에
대한 책은 전무한 실정이다. 이 사실은 DBA들을 암흑의 세계로 이끈다. 이 문제로 수많은 DBA들이
밤을세웠으며아직도발등에떨어진불만끄기위해전전하고있다. 암흑시대를마무리해줄등대와
같은교과서가필요한시점이다.
패러다임의전환이필요해Physical Optimization의 원리는인덱스의선택, 조인방법의선택, 조인순서의선택등 Physical 옵티
마이져의 행동을 분석하는 데는 적합하지만 실전에서 SQL을 튜닝 할 때는 활용도가 떨어진다. DBA나
튜너가 실전에 투입되면 Physical Optimization의 결과물인 Cost를 계산하면서 SQL을 튜닝하는 사람은
거의없기때문이다.
이 책은 옵티마이져의 기능 중 절반에 해당하는 Logical Optimizer에 대한 책이다. 이제는 Logical
Optimizer로 튜닝의패러다임의전환이필요한시기이다. Query Transformation은 옵티마이져가 SQL 자
체를 변경시키기 때문에 성공/실패의 여부에 따라 SQL의 성능에 지대한 향을 끼친다. 따라서 모든 튜
PART 1 | Query Transformation Concept 029
너들이 Logical Optimizer를 Control 할 수 있어야 한다. 이제는 직접 튜닝 하는 것에서 벗어나 Logical
Optimizer에게 SQL 튜닝을맡기고그한계를드러내는경우옵티마이져에게더좋은방법을가이드하는
것이튜너의역할이되었다.
030
Query Transformation Concept | PART 1
Query Transformation은 Transformer의 기능이며‘개발자가작성한 SQL을 옵티마이져가다른모습으
로 재작성하는 것’으로 정의 할 수 있다. 이제 옵티마이져가 SQL을 재작성하는 목적과 원칙, 원리 등을
알아보자.
SQL을재작성하는옵티마이져의목적1. 성능향상
2. 성능향상
1, 2번이똑같이성능향상이다. 이렇게표현한것은실수도, 과장도아니다. 그만큼Query Transformation
은 성능향상이중요하다는의미이다. 옵티마이져는 SQL을 재작성하여성능이저하되는경우 SQL을 재작
성하지않는다. 사실 성능의향상은목적이기이전에옵티마이져의존재이유이다. 옵티마이져가 SQL을
재작성하여 SQL이단순화된경우가있지만Query Transformation의목적이나존재이유가아니다.
SQL을재작성하는옵티마이져의원칙‘변환된 SQL은논리적으로원본의 SQL과의미하는바가같아야한다.’
너무도당연한원칙이다. 성능을 빠르게한답시고원본 SQL의 결과와재작성된 SQL의 결과가다르면
안된다. 결과 건수, 컬럼의 값, Sort의 순서 등이 원본 SQL의 결과와 완전히 일치해야 한다. ‘원칙대로
행동하라’라는말에옵티마이져는충실하며앞으로도그럴것이다.
SQL을재작성하는옵티마이져의원리1. Rule 기반의원리
2. Cost(비용) 기반의원리
-뻔한것은 Rule로 정할수있다
PART 1 | Query Transformation Concept 031
The Logical Optimizer
1.3 Query Transformation의 개념
첫 번째, Rule 기반의 SQL 재작성 원리이다. 예를 들어‘불필요한 Distinct는 제거하라’라는 원리가
있다. SQL에 Distinct가 포함되면 Sort + 중복제거 라는 2가지 과정이 항상 수행된다. 이에 따른 부하와
성능저하는불을보듯뻔한것이다. 하지만 Distinct가 불필요한 SQL도 많이있는데이럴경우옵티마이
져는과감히 Distinct를 삭제해버린다. Rule이란이런것이다.
Rule과 Heuristic은 같은말이며이책에서는 Heuristic Query Transformation으로 불릴 것이다. 다양한
Rule에 대해서는 Part 2에서 자세히 설명된다. 이 책에서 설명되는 Heuristic Rule은 34개가 넘는다. 이
Rule들이전부는아니지만이것들을모두Master한다면실무에서자주발생하는거의모든 Rule을 Cover
한다고볼수있다.
-비용이많이들어가면망한다
두 번째, Cost 기반의 SQL 재작성 원리이다. 모든 SQL의 재작성 원리를 Rule로 Cover 할 수 있다면
좋겠지만현실적으로는여러가지복잡한문제들이있으므로그렇지못하다.
이해를 돕기 위해 한가지예를들어보자. 모든 직원이 교육을통해서 Upgrade 된다면 그 회사는경쟁
력이상승하여빠른성장을이룰수있다. 하지만직원한명이 1억원의비용이드는일주일과정의교육
을 요청 했다면? 당신이 경 자라면 이 요청을 받아 들일 것인가? 물론 일주일 교육에 의한 효과는 있겠
지만비용(Cost)이 너무많이들기때문에이런교육을많은인원이받게된다면회사가성장하기도전에
망할판이다. 이때총무부장은현재의재정상태를점검하고교육을승인하는역할을한다.
Cost Based Query Transformer는 Cost Estimator를 이용한다위의 예제는 가상의 이야기다. 하지만 옵티마이져의 구성요소 중에서 위의 총무부장과 같은 일을 하는
것이 Cost Estimator이다. Cost Estimator는 SQL을 던져주면 Cost(비용)를 Return 하는 옵티마이져의 중
요한구성요소이다. Cost 기반으로 SQL을 재작성 할 경우 Logical Optimizer는 Cost Estimator를 이용하
여원본 SQL과 재작성된 SQL의 Cost를 비교하여저렴한쪽을선택하게된다. Cost 기반의 SQL 재작성
원리는 Part 3에서자세히설명된다.
시작이반이다앞으로 나올 모든 Query Transformation의 이야기들은 위에서 이야기한 목적, 원칙 그리고 원리에 충
실하다. 우리는 세 가지(목적, 원칙, 원리)를 큰 그림으로 이해 하 다. 이것으로 반은 정복 한 것이다.
왜냐하면 Part 2와 Part 3는 이러한원리를상세히설명한것에불과하기때문이다.
032
Appendix
이 책은 비형식 논리학의 관점에서 집필 되었다. 논증이란 하나의 사실을 밝히는 작업이다. 하나의 사
실을 다음과 같이 밝히고 싶다. 아래는 명제를 논증하는 과정에서 가상의 독자와 필자가 서로의 논리를
주장하는과정이다.
명제 : Logical Optimizer를 모르면고급튜닝을할수없다.
필자 : 위의말은사실이다.
독자 : 이유가 무엇인가? 최적의 Access Path와 조인 방법, 조인 순서 등으로 성능을 보장받는 것이
아닌가? 이것들이 Logical Optimizer와 무슨상관인가?
필자 : 독자가 이야기한 것은 Physical Optimizer가 하는 일이며 매우 중요하다. 하지만 Logical
Optimizer도 마찬가지로 중요하다. 실행계획의 이해는 SQL 튜닝의 기본이라는 것은 누구나 공감할 것이
다. 그런데 Logical Optimizer는 사용자가작성한 SQL을 성능향상의목적으로바꿔버린다. 따라서실행
계획도바뀐다. 실제수행되는 SQL과바뀐실행계획을이해하지못하면성능향상의꿈은요원할것이다.
독자 : 쎄… 이때까지 Logical Optimizer를 모르고도튜닝을성공적으로해왔다고생각한다. 실제로
그증거들을보여주기전에는믿지못하겠다. 근거를보여다오.
필자 : 근거라…너무많아서문제가되지만핵심이되는근거들만나열하면아래와같다.
첫 번째, Rule에 근거한 SQL 변경이다. Logical Optimizer는 Rule에 의해서 SQL을 재작성한다. 이때
실행계획도같이바뀐다. 2.1 장부터 2.34 장 까지가증거이다. 직접 SQL을 실행하면서증명한것이므
로독자가실행하여도결과는같을것이다.
두 번째, 비용에 근거한 SQL 변경이다. 원본 SQL의 비용을 계산하고재작성된 SQL의 비용을 계산하
여둘중에저렴한것을선택하게된다. 3.1 장부터 3.20장까지가근거이다.
Appendix 417
The Logical Optimizer
Epilogue
세 번째, 비용에 근거한 SQL 변경은 여러 가지 전략이 뒤따른다. 이 전략을 알지 못한다면 비용에 근
거한 SQL 변경의원리를놓치는것이다. 이 원리를놓친다면실무적으로도여러가지를적용할수없다.
근거는 4.1 장부터 4.14 장까지이다.
독자 : Logical Optimizer가 많은 일을 하는 것 같다. 하지만 한편으로 SQL을 변경 한다는 것은 성능
을좋게하겠다는의도가아닌가? Logical Optimizer가 자동으로 SQL을 더빠르게해준다는개념인데우
리가그원리를알아서수동으로 SQL을재작성할필요는없지않은가?
필자 : 공감이 간다. 대부분의 경우 문제가 없고 성능이 좋아진다. 하지만 Logical Optimizer의 능력에
는한계가있다. 2.B 장과 부록의‘Merge문과 In 조건이 만난다면’이라는 과 4.3 장부터 4.8 장까지
그원리와현실적인한계를밝혀놓았다. 그 한계를넘어설때는우리가올바른길로안내해야한다. 그
것이튜너의할일이다.
독자 : 이해가 될 것 같다. 하지만 Logical Optimizer의 원리는 이론일 뿐 DBA나 중/고급 개발자들이
실전에서놓치는튜닝포인트가많을까? 내경험상매우적을것이다.
필자 : 독자가 말한대로 Logical Optimizer가 항상 문제를 일으키는것은 아니다. 하지만 정작 그 문제
가 발생한다면 여타의 튜닝 이슈와 달리 많은 수의 사람들이 고통을 받을 수 밖에 없다. 왜냐하면 문제
발생시 원리를 알아야 해결책을 찾을 수 있는데 그 원리를 아는 사람이 거의 없으므로 오랜시간 고민을
하더라도 문제를 해결할 수 없기 때문이다. 고급 튜너가 되려면 이점을 놓치면 안된다. 1.2장의 통계에
서도 알 수 있지만 1.6장, 2.B 장, 3.C 장과 부록의 예제들이 현재 많은 사람들이 고통받고 있는 것들
이다.
독자 : Query Transformation 문제가항상발생하는것은아니지만만약문제가된다면원인을파악하
지 못하므로 문제를 해결할 수 없다는 이유는 설득력이 있어 보인다. 고급 튜너가 되려면 Logical
Optimizer의 원리를알야야한다는사실도이해가간다.
위의 논증을 토대로 하여 책이 집필 되었고 이제 여러분은 이 관점으로 집필된 모든 내용을 다 마스터
하 다. 마지막으로당부하고싶은것은이른바파레토의법칙에서의전체를이끄는상위 20%의 전문가
집단은이미옛말이다. 세상은이미상위 1%만기억하는시대가되었다. 원리를이해하는것으로만족하
지 말고 그 원리를 실무에 응용하는 능력을 기르며, DBMS의 버전이 올라갈 때마다 새로운 Optimizer의
원리를발견한다면여러분은진정한상위 1%의 Database Guru가 될것이다.
물론 그러기 위해서는 험난한 여정은 필수이다. 그것은 마치 사막을 횡단하는 것처럼 힘들 것이다. 이
418
책은상위 1%로가기위한여정중에들르는첫번째오아시스가될것이고그오아시스는오래도록존재
할 것이다. 많은 시간이 지나 오라클 버전 V13 이나 V14가 나오더라도 Logical Optimizer의 기능이 추
가될뿐원리는크게변하지않을것이기때문이다.
Appendix 419
Bibliography
·Allison Waingold, et al.Delaying Evaluation of Expensive Expression in a Query:US Patent0078812 A1. CA(US):Oracle Corporation,2007
·Alon Yitzchak Levi and Indepal Singh Mumik,Query Optimization By Predicate Move-Around:US Patent 5659725. Murray Hill, N.J.:Lucent Technologies Inc.,1997
·Andrew Witkowski.Method And Article For Processing Queries That Define Outer JoinedViews:US Patent 6438541 B1. CA(US):Oracle Corporation,2002
·Andrew Witkowski and Tolga Bozkaya,Group Pruing from Cube, Rollup and GroupingSets: US Patent 6775662 B1. CA(US):Oracle Corporation,2004
·Silberschatz Abraham and Korth Henry and Sudarshan S,Database System Concepts(5thEdition).US:McGraw-Hill,2006
·Cetin Ozbuton,et al.Method and Apparatus For Processing Count Statements In aDatabase System:US Patent 5819256. CA(US):Oracle Corporation,1998
·Christian Antognini,Blog:Striving for Optimal Performance (http://antognini.ch).Ticino,Switzerland:Christian Antognini,2009
·Christian Antognini,Troubleshooting Oracle Performance. Berkeley,CA(US):Apress,2008
·Dinesh Das, et al.Global Hints:US Patent 0125398 A1. CA(US):Oracle Corporation,2007
·Dion Cho,Optimizing Oracle Performance.Seoul, Korea:EXEM,2008
·Dong Kyu O,Blog:Science of DataBase(http://scidb.tistory.com).Seoul,Korea:Dong Kyu O
Bibliography 421
·Fred Koo, Thornhill and Ting Y. Leung,Redundant Join Elimination and Sub-QueryElimination Using Subsumtion: US Patent 0167258 A1. CA(US):Oracle Corporation,2003
·George Lumpkin and Hakan Jakobsson,White Paper:Query Optimization in OracleDatabase 10g Release 2. CA(US):Oracle Corporation,2005
·Hakan Jokobsson, et al.Method And Apparatus For Transforming Queries:US Patent5963932. CA(US):Oracle Corporation,1999
·Hong Su, et al.Efficient Search Space Analysis For Join Factorization:US Patent 0219977A1. CA(US):Oracle Corporation,2007
·Hong Su, et al.Join Factorization of Union/Union All Queries:US Patent 0219969 A1.CA(US):Oracle Corporation,2007
·Immanuel Chan and Lance Ashdown,Oracle Database Performance Tuning Guide 11gRelease 2.CA(US):Oracle Corporation,2009
·Jonathan Lewis,Blog:Oracle Scratchpad (http://jonathanlewis.wordpress.com).UK:Jonathan Lewis
·Jonathan Lewis,Cost-Based Oracle Fundamentals.Berkeley,CA(US):Apress,2005
·Joseph M. Williams and Gregory G. Colomb.The Craft of Argument(3rd edition).NewYork(US):Longman,2006
·Mohamed Ziauddin and Ahmed Alomari,Query Optimization with Switch Predicates:USPatent 6581055 B1.CA(US):Oracle Corporation,2003
·Optimizer Development Group,Blog:Inside the Oracle Optimizer - Removing the blackmagic(http://optimizermagic.blogspot.com).CA(US):Optimizer Development Group,2007
·Patric D. Bossman, et al.Query Transformation For Queries Involving CorrelatedSubqueries Having Correlation Join Predicates With Local Filtering Predicates InvolvingPredicate Transitive Closure And Predicate Pull-Out:US Patent 7181446 B2.CA(US):Oracle Corporation,2007
·Paul Lane,Oracle Database Data Warehousing Guide 11g Release 2.CA(US):OracleCorporation,2009
·Rafi Ahmed, et al.Cost Based Query Transformation in Oracle.Seoul, Korea:VLDBConference,2006
422
·Rafi Ahmed, et al.Join Predicate Push-Down Optimizations:US Patent 0219951 A1.CA(US):Oracle Corporation,2007
·Rafi Ahmed,Multi-Tier Query Processing:US Patent 0283471 A1. CA(US):OracleCorporation,2005
·Rafi Ahmed,Reusing Optimized Query Blocks in Query Processing:US Patent 7246108B2. CA(US):Oracle Corporation,2007
·Rafi Ahmed,Selecting Candidate Queries:US Patent 0041537 A1. CA(US):OracleCorporation,2006
·Rafi Ahmed and Angela Amor,Null Aware Anti-Join:US Patent 0219952 A1.CA(US):Oracle Corporation, 2007
·Riyaj Shamsudeen,Cost Based Query Transformations Concept And Analysis Using10053 Trace. Dallas, TX(US): HOTSOS’,2008
·Srikanth Bellamkonda, et al.Enhanced Subquery Optimization in Oracle. Lyon France:VLDB Conference,2009
·Srikanth Bellamkonda, et al.Evaluation of Grouping Sets By Reduction to Group-ByClause, With or Without a Rollup Operator, Using Temporary Tables:US Patent 6775681B1. CA(US):Oracle Corporation,2004
·Tomas Kyte,On Rollups, Merges, and Moves:Oracle Magazine March-April 2005.CA(US):Oracle Corporation,2005
·Weipeng P. Yan and Per- Ake Larson,Eager Aggregation and Lazy Aggregation.Zurich,Swizerland:VLDB Conference,1995
·Weipeng P. Yan and Per-Ake Larson,Interchanging the Order of Grouping andJoin.Ontario, Canada:Department of Computer Science ,University of Waterloo,1995
·Wikipedia encyclopedia(http://wikipedia.org)
Bibliography 423
Index
424
_always_anti_join 151
_always_semi_join 150, 164
_b_tree_bitmap_plans 184, 326
_complex_view_merging 283
_convert_set_to_join 261, 265
_eliminate_common_subexpr 72
_groupby_nopushdown_cut_ratio 318
_no_or_expansion 248
_optimizer_coalesce_subqueries 180
_optimizer_cost_based_transformation 227, 248, 254, 340,
344, 362, 376, 377, 379, 381, 382
_optimizer_distinct_elimination 90
_optimizer_distinct_placement 416
_optimizer_enhanced_filter_push 233
_optimizer_extend_jppd_view_types 310
_optimizer_filter_pred_pullup 240
_optimizer_group_by_placement 314
_optimizer_join_elimination_enabled 75, 78, 171
_optimizer_join_factorization 323
_optimizer_max_permutations 376
_optimizer_multi_level_push_pred 301, 303
_optimizer_native_full_outer_join 112, 117
_optimizer_null_aware_antijoin 153, 156, 157
_optimizer_or_expansion_subheap 394
_optimizer_order_by_elimination_enabled 85
_optimizer_outer_to_anti_enabled 161, 163
_optimizer_push_pred_cost_based 288, 292, 297
_optimizer_reuse_cost_annotations 392
_optimizer_table_expansion 259
_optimizer_transitivity_retain 98
_optimizer_use_cbqt_star_transformation 335
_optimizer_use_subheap 393
_or_expand_nvl_predicate 254
_pivot_implementation_method 195
_push_join_predicate 297
_push_join_union_view 293
_push_join_union_view2 288
_remove_aggr_subquery 141, 144
_right_outer_hash_enable 192
_simple_view_merging 103
_union_rewrite_for_gs 210
_unnest_subquery 150
_unnesting_subquery 141, 275
10053 Event Trace 54
10053 Trace Simple Case Study 55
10053 Trace에서 CBQT 부분 59
10053 Trace에서 HQT 부분 58
10053 Trace에서 Outline Data 부분 63
10053 Trace에서 Plan 부분 63
10053 Trace에서 SQL 부분 62
10163 Trace Level Event 343
1Mem 39
5년간의 통계 27
두 번째 Turn의 규칙 372, 404
무노동 무비용의 원칙 216
불완전 CBQT 330, 335, 340, 344
비상관 서브쿼리 144
삼장법사의 경지 372
숫자표기법 360
실무에서의 CBQT의 활용도 354
옵티마이져 상세 구조도 33
적응적 탐색 370, 380
첫 번째 Turn의 규칙 372, 404
최근 2년간의 통계 28
추가적인 두 번째 Turn의 규칙 374
쿼리변환 26
쿼리블럭 34
튜닝에 실패하는 원인 27
Index 425
파라미터 혹은 힌트간의 종속관계 141
패러다임의 전환 29
하위 Loop를 경계하라 402
Adaptive Null Aware Scan 159
Adaptive Search 370
AJ 151
AJR 188
ANSI SQL 166
Anti Join 151
Anti Join + JPPD 309
Anti Join Null Aware 156
ANTI NA 156
ANTI NA에서 IS NULL 조건이 추가된 이유 158
Any Subquery To Normal Join 133
A-Rows 39
A-Time 39
Best Plan 388
Between 413
Bit Map 인덱스 324
Bit Map And 329
Bit Map Iteration 325
Bit Map Join Index 341
Bit Map Merge 325
Bitmap Key Iteration 184
BITMAP_TREE 342
Block Level Lock 326
BP 388
branch 322
Buffers 39
CA 390, 392, 404
candidate phase 300, 306
CBPPD 228, 230
CBQT 35, 223, 267, 393, 395, 396
CBST 330
CNT 91
CNT 기능의 제약조건 92
COALESCE_SQ 178
Column Projection Information 41, 197
Common Subexpression Elimination 71
Complex Subquery Unnesting 271
Complex View 228, 305
Complex View Merging 278
CONCATENATION 242, 243
Constraint를 지정해야 하는 이유 92
Correlated Removal Subquery Using Window Function 138
Cost (%CPU) 39
Cost Annotation 390
Cost Based Predicate Push Down 228
Cost Based Query Transformation 35, 223
Cost Based Star Transformation 330
Cost Estimator 26, 223, 345, 390, 393
Count(column) To Count(*) 91
CRSW 138
CSE 71
CSU 271, 364, 394, 404
CSU가 발생되는 두 가지 규칙 137
CUBE 198
Cursor Expression 283
Cursor For Loop 127
Cut-off 369, 376, 391
Cut-off의 법칙 401
CVM 278, 281, 362, 396, 398, 399, 404
CVM 제약 사항 282
DBMS_XPLAN.DISPLAY 37
DBMS_XPLAN.DISPLAY_CURSOR 37, 116, 197
DE 86
DE와 DEUI의 차이점 89
DE의 함정 87
DECODE 249, 251, 414
DECODE를 이용한 선택적 조인 109
DEUI 88, 350
Dimension 테이블 324
Distinct Elimination 86
Distinct Elimination using Unique Index 88
Distinct Placement 416
DP 416
Driving Semi Join 181, 183, 185, 329
DSJ 181, 333
Dynamic Programing appproch 361
Dynamic SQL 239, 249
Early Filter의 효과 176
E-Bytes 39
EJE 164
ELIMINATE_JOIN 74, 78, 165, 166, 169, 342
ELIMINATE_OBY 85
Enhanced JE 164
E-Rows 38
E-Temp 39
E-Time 39
Exhaustive Type 226, 273, 345, 360, 367, 375, 380, 382
EXPAND_GSET_TO_UNION 207
Expand_Table 259
Exporting Predicate 237
Extend JPPD 310
426
FACT 329
FACTORIZE_JOIN 321, 323
Filter 379
Filter 서브쿼리 275
Filter Push Down 93, 228
Filter Subsumtion 120
final phase 307
FK 164
FOJC 112
force_no_combine 210
Format 38
FPD 93, 228, 407
FPD의 제약조건 95
Full Outer Join 112
Full Outer Join Conversion 112
GATHER_PLAN_STATISTICS 37
GBEP 198
GBP 312, 314
GBPD 315
GBY_PUSHDOWN 316
Global Hint 49
Global Hint 쿼리블럭 표기법 52
Global Hint Dot 표기법 50
Group By Extension Pruning 198
Group By Placement 312
Group By Push Down 315
Grouping Sets 204, 207, 211
Grouping Sets To Rollup 211
Grouping Sets To UNION 207
Grouping Sets Using Temp Table 204
GSTR 211
GSTT 204, 210
GSTU 207
GSTU 사용시 제약사항 210
Hard Parsing 238, 368, 391, 402, 403
Hash Join Right Anti 191
Hash Join Right Outer 191
Hash Join Right Semi 190
Hash Join Right Semi/Anti 188
Heuristic 69
Heuristic 변환 381
Heuristic Query Transformation 69
Heuristic Rule 69
Hint가 무시되는 이유 45
HQT 70
Index Combination 327
Inline 144
Interleaving 395, 396, 402, 403, 404
Interleaving과 Juxtaposition의 다른 점 398
Intersect 260, 265
Iteration 226, 227, 345, 389
Iteration Skip 391
Iterative Type 360, 371, 377, 404
JBE 341, 343
JE 74, 164, 169
JE 기능의 제약사항 75
JE의 기능강화 214
JESJ 168
JESJ using Filter SubSumption 171
JF 319, 320
Join Back Elimination 341, 343
Join Elimination 73, 168, 169
Join Elimination Using Self Join 168
Join Factorization 319, 320
Join Predicate Push Down 283, 284, 294
JPPD 283, 284, 346, 350, 362, 396, 398, 399, 404, 407
JPPD Extension 304, 349
JPPD Outer Join View 294
JPPD Union All View 291
JPPD Union View 284
JPPD가 발생하는 경우 307
Juxtaposition 398, 399, 400, 403, 404
kkoqbc 394
Lateral View 104, 284, 285, 295, 299, 408, 411, 412, 415
Lateral View 흉내내기 110
Linear Type 226, 232, 345, 360, 377, 382, 385, 404
LNNVL 243
Logical Optimizer 25, 345, 376, 393
Logical Optimizer의 목적 31
Logical Optimizer의 원리 31
Logical Optimizer의 원칙 31
Logical Optimizer의 전략 359
LV 104
LV를 이용한 선택적으로 조인 109
LV의 제약조건 105
Materialized View 336
Materialized View Rewrite 336
Max-Tmp 39
MERGE 103
Merge 문 407
MERGE 문에서 IN 조건의 사용 407
MERGE문 실행시 쿼리변환이 발생하는 순서 407
Minus 260, 266
Multi Level JPPD 298, 301
Index 427
MView 336
MVR 336
Name 38
NATIVE_FULL_OUTER_JOIN 117
NESTED LOOPS ANTI SNA 157
NFOJ 117
no transformation phase 300, 306
NO_ELIMINATE_JOIN 75
NO_ELIMINATE_OBY 85
NO_EXPAND_GSET_TO_UNION 210
No_Expand_Table 259
NO_FACTORIZE_JOIN 323
NO_GBY_PUSHDOWN 317
NO_MERGE 103, 230, 267
NO_NATIVE_FULL_OUTER_JOIN 117
NO_OUTER_JOIN_TO_INNER 163
NO_PLACE_GROUP_BY 314
NO_PULL_PRED 240
NO_PUSH_PRED 288, 293, 297, 301
NO_STAR_TRANSFORMATION 329
NO_SWAP_JOIN_INPUTS 192
NO_UNNEST 139, 149, 275
Non-Cost-Based-JPPD 290
Not In 과 Not Exists의 차이 155
Not In 서브쿼리 사용시 결과가 안나오는 이유 154
NVL 249
O/1/M 39
Object Alias 40
Object Type 110
OBYE 84
OE 77
Off Option 362
OJE 80
OJE의 제약조건 82
OJPPD 288, 289, 297
OJTAJ 160
OJTAJ의 제약사항 162
OLD_PUSH_PRED 288, 297
OMem 39
On Option 361, 382
Operation 38
Operator Transformation 119
Optimizer 구조도 25
optimizer_secure_view_merging 283
OR 조건으로 분기 241
OR_PREDICATES 245
ORA-4031 393
Oracle11gR2 142, 168, 177, 245, 255, 319, 323, 330
OR-branching 246
Order By Elimination 84
ORDERED 190
OR-Expansion 241, 394
OR-Expansion Using Function 249
OR-Expansion Using Function의 주의사항 251
OT 119
OT의 발생규칙 119
Outer Join Table Elimination 77
Outer Join to Anti Join 160
OUTER_JOIN_TO_INNER 80, 161, 163
Outer-Join Elimination 80
Outline Data 40
Parser 25
Partial Rollup 212
PC 194
Physical Optimization 393
Pivot Conversion 194
Pivot1 195
Pivot2 196
PLACE_GROUP_BY 312, 314
Plan Generator 36, 390
Plan State Space 388
PM 123, 283
PM의 발생규칙 126
PPU 234
PPU의 제약조건 234
pre rewrite 과정 135
Predicate Information 40
Predicate Move Around 123, 283
Predicate Pull Up 125, 234
Predicate Push Down 125
Pseudo Code 402
PULL_PRED 235, 238, 240
PUSH_PRED 288, 293, 297, 301
PUSH_SUBQ 174
QB_NAME 35, 149, 275, 364, 398
QUERY BLOCK 35
Query Block Name 40
Query Block Registry 114
QUERY BLOCK SIGNATURE 78, 115
Query State Space 388
Query Transformation 25
Query Transformation의 개념 31
Query Transformation의 순서 33
Query Transformer의 구조 33
428
query_rewrite_enabled 340
RANK 249, 252
Reads 39
REWRITE 337, 339
Rollup 198, 211
Row Level Lock 326
RSW 138
Scalar Subquery To Subquery 172
Search Type 226, 232, 345, 359
Search Type 분석에 사용될 SQL 364
Semi Join 145, 327
Semi Join/Anti Join의 강점 148
Semi Join이 Driving 집합이 되는 상황 145
Semi/Anti Join + JPPD 308
SEMIJOIN_DRIVER 183, 184, 187, 331
Set To Join Conversion 260
SET_TO_JOIN 261
Simple FPD 95
Simple is Best 401
Simple Subquery Unnesting 132
Simple View Merging 100
Single Level JPPD 302
SJC 260, 264
SJR 188
SQC 177
SQL을 재작성 하는 옵티마이져의 원칙 347
SSTS 172
SSU 132, 271, 364
ST 324
Star Transformation 185, 324, 329, 330
STAR TRANSFORMATION PLANS 328, 342
star_transformation_enabled 185, 326, 329
Starts 39
State Space 387, 390, 404
STJ 269
Sub Heap 393, 404
Subquery Coalescing 177
Subquery Pushing 176, 213
SVM 100
SWAP_JOIN_INPUTS 190, 192
SYS_OP_MAP_NONNULL 263
Table queues 315
TE 255
TE의 제약사항 255
Temp Table Transformation 327
TP 97
TQ 315
Transformation Unit 33
Transformation간의 관계 395
Transformer 25, 223
Transformer가 View Merge를 시도하는 이유 102
Transitive Closure 97
Transitive Predicate 97, 296, 306
Two_Pass Type 361, 369, 375, 379, 385
Uncorrelated Removal Subquery Using Window Function
142
Uncorrelated Subquery 142
Union 284, 319
Union All 207, 211, 241, 255, 291, 319
Unnest 275
Unnesting 139
UNPARSED QUERY 114
URSW 142
USE_CONCAT 244, 245
Used-Mem 39
Used-Tmp 39
View Merging 412
WCOTR 127
WCOTR의 제약사항 129
Where Current Of To Rowid 127
WITH 144, 205
Writes 39
yes_gset_mvs 210
㈜오픈메이드컨설팅 www.openmade.co.kr
◎핵심비즈니스 역
·데이터아키텍처 컨설팅 (Data Architecture Consulting)
·데이터모델링 (Data Modeling)
·BI/DW/CRM 컨설팅
(Business Intelligence/Data Warehouse/Customer Relationship Management Consulting)
·ISP(DAP) 컨설팅
(Information Strategic Planning(Data Architecture Planning) Consulting)
·DBMS 성능개선컨설팅 (Performance Tuning Consulting)
·Database Management
◎주요프로젝트수행내역
▶차세대시스템구축 (데이터모델링)
·농협중앙회, 대구은행, 신라상호저축은행
·한국투자증권, 한국증권금융, SK증권, 대신증권
·국민연금관리공단, 서울보증보험
▶ BI/DW/CRM
·KB, 하나은행, IBK, 수협중앙회
·KB카드, 비씨카드, 삼성카드
·국민건강보험공단
▶성능개선(튜닝)컨설팅
·농협신용시스템, 현대해상차세대시스템, 국민건강보험공단시스템
▶ ISP Consulting
·국민건강보험공단, 수협중앙회
드러난것은누구나볼수있다보이지않는원리를파악하라
![x K ºI xK >sigmapress.co.kr/shop/shop_image/g38607_1406004120.pdf · 2014-07-22 · ] \ ¯ > Ý ] i b î: b 7 r > t < > ² ( > b f i m f~ Ø ñ , ; d i ÿ * 5if](https://img.pdfslide.net/doc/110x75/5e24b59bdecc06010545b793/x-k-i-xk-2014-07-22-i-b-b-7-r-t-.jpg)
