티스토리

Science of Database

검색하기

블로그 홈

Science of Database

scidb.tistory.com/m

오동규 블로그 odong91@naver.com

구독자: 14

방명록 방문하기

주요 글 목록

PARTITION WISE JOIN이란 무엇인가? 부제: Partition Wise Join의 성능 DBA나 튜닝 컨설턴트들에게 PARTITION WISE JOIN(이후 PWJ)를 설명해 보라고 하면, 언제나 PARALLEL과 PQ_DISTRIBUTE 힌트를 언급한다. 이상한 일이다. PWJ는 PARALLEL + PQ_DISTRIBUTE 힌트 조합과 상관없이 독립적으로 존재한다. 그럼에도 불구하고 PWJ를 설명하기 위해 두 힌트를 항상 끌어들인다. 마치 PWJ 기능이 두 힌트에 종속되기라도 하는 것처럼 말이다. 그 이유는 메뉴얼을 포함한 거의 모든 튜닝책에 위의 두 힌트를 사용해서 PWJ를 설명하고 있기 때문이다. 말도 안 되는 소리 이제는 PWJ를 설명 할 때, PARALLEL과 PQ_DISTRIBUTE 힌트와 연계하여 설명하지 말기 바란다. 이렇게 .. 공감수 27 댓글수 406 2013. 5. 21.
DP(Distinct Placement): 뷰의 건수를 Distinct로 줄여서 조인하라 SQL에서 DISTINCT의 위치는 중요하다. DISTINCT가 메인쿼리에 위치하면 조인이 모두 처리된 후 DISTINCT가 실행된다. 그 반대로 각각의 집합을 DISTINCT 한 후에 조인한다면 양측 집합의 건수가 줄어들므로 조인의 부하가 줄어든다. 그런 관점에서 보면 아래의 SQL은 최악이다. 환경: ORACLE 11.2 SELECT /*+ qb_name(MAIN) LEADING(S@INLINE) USE_NL(C@MAIN) */ DISTINCT c.channel_id, c.channel_desc, s.prod_id, s.promo_id FROM channels c, (SELECT /*+ qb_name(INLINE) NO_MERGE */ s.channel_id, s.prod_id, promo_id FR.. 공감수 6 댓글수 6 2013. 5. 13.
COUNT(Distinct 컬럼)의 성능 집계함수 내부에 Distinct를 사용할 수 있다는 것은 많은 사람들이 알고 있다. 하지만 실제로 그렇게 사용했을 때 내부적으로 무슨 일이 일어나는지 아는 사람은 드물다. 한걸음 더 나아가서 COUUNT(COL) 대신에 COUNT(Distinct COL)를 사용했다면 분명히 추가적인 부하가 존재할 것인데, 그 부하를 어떻게 해결할 것인가를 아는 사람은 거의 없을 것이다. 만약 그렇다면 SQL을 실행할 때 마다 성능이 느려질 것이고 문제를 해결할 수 없을 것이다. 여러분들에게는 그런 일이 발생하지 않는다. 이미 이 글을 읽고 있기 때문이다. 이 글은 위에서 언급된 두 가지 문제를 다룬다. 즉 내부적으로 어떤 변화가 발생하는지 알아보고, 추가적인 부하를 어떻게 없앨 수 있는지도 연구해보자. SQL 변경에 따.. 공감수 20 댓글수 9 2013. 5. 6.
Oracle에 SSD(Flash Disk)를 사용한다면 Window 7을 사용하는 사람들은 ReadyBoost 기능을 잘 알 것이다. 부팅 시에 필요한 정보를 성능이 우수한 Flash Disk(USB)에 넣음으로써 부팅속도를 향상시키는 것이다. 즉 부팅 시에 성능이 느린 Hard Disk를 사용하지 않으므로 성능이 향상된다. 이와 비슷한 기능이 오라클에도 있다. Oracle 11.2부터 Database Smart Flash Cache라는 것이 추가되었다. 이 개념은 buffer cache가 Aging Out되어 Disk로 내려가는 단점을 보완한 것이다. 즉 buffer cache에서 Aging Out 되더라도 성능이 우수한 Flash Disk(SSD)로 내려가는 개념이다. 따라서 SSD로 Aging out된 블록을 다시 읽을 때 기존 Disk보다 빠른 성능을.. 공감수 11 댓글수 8 2011. 5. 4.
Sort Merge Join에 대한 오만과 편견 일반적인 의견 흔히 Sort Merge Join에 대해 다음과 같이 이야기 한다. “조인에 참여하는 양측 집합에 Sort가 발생하므로 대용량 집합간의 조인에는 불리하다. 그러나 조인 되는 양쪽 집합에 적절한 인덱스가 있다면 Sort가 발생되지 않으므로 성능이 좋다.” 일견 일리가 있는 말이다. 하지만 이 정도는 튜닝에 입문하는 단계에서 언급되는 정도일 뿐이다. 2단을 외운다고 해서 구구단을 모두 안다고 할 수는 없다. 튜닝에 입문하는 사람과는 반대로 경력이 있는 사람들은 좀더 구체적인 사실들을 알고 있다. Sort Merge Join과 관련된 튜닝을 많이 해보고, Merge Join에 대해 여기저기 튜닝서적들을 탐독한다. 그 결과 다음과 같은 섣부른 결론을 내리는 사람이 많이 있다. 1. 양쪽 집합이 F.. 공감수 20 댓글수 476 2011. 4. 28.
전산장애에 늑장 대응하는 기업들의 공통점 영화 다이하드 4.0을 보면 파이어 세일이라는 용어가 나온다. 이 용어는 3단계의 해킹과 크래킹 과정을 의미한다. 그 과정을 통해 가공할 만한 전상장애를 일으켜 국가를 붕괴시켜버리는 것이다. 1단계는 교통기관 시스템 마비, 2단계는 금융·통신 전산 장애, 3단계는 가스·수도·전기·원자력 시스템을 점령하는 것이다. 모든 것이 컴퓨터 속의 소프트웨어로 컨트롤 되고 있으므로 위의 3단계와 같은 전산장애만 일으킨다면 국가가 무너지는 것은 불을 보듯 뻔한 것이다. 국가가 아니라 당신이 위험하다 현실에서의 전산장애는 영화처럼 1,2,3 단계가 동시에 발생하지는 않으므로 국가가 아니라 개인과 기업을 위협한다. 현실에서 실제로 발생하는 전산장애를 생각해보자. 오늘이 만기일이라고 가정하자. 오후 4시에 송금을 하려고 했.. 공감수 19 댓글수 22 2011. 4. 11.
COPY_T 테이블 필요한가? ▶ 더미 테이블을 사용해서 장애를 만나는 경우 ▶ 더미 테이블을 사용하는 이유 ▶ 더미 테이블을 사용하지 않는 방법 포장마차에서 지인에게 재미있는 이야기를 들었다. 물론 공장 이야기 이다. 나는 이야기를 재미있게 들었지만, 지인의 입장에서는 머리가 쭈뼛쭈뼛 서는 심각한 일이었다. 사건은 2011년 겨울에 시작된다. 2011년 1월 1일 이른 아침, 갑자기 잘 돌아가던 시스템에 몇몇 프로그램들이 작동하지 않는 장애를 만났다. Y2K 버그도 아니고 2011년 1월 1일에 장애라니? 서버와 네트워크 그리고 Database는 정상이므로 관심의 화살은 개발팀으로 집중되었다. 개발팀에서 장애 프로그램을 조사해보니 지난 한 달간 프로그램 수정이 없다고 하였다. 결국 모든 것이 정상인데 프로그램만 돌아가지 않는 상황이.. 공감수 7 댓글수 6 2011. 4. 4.
Sort 부하를 좌우하는 두 가지 원리 ▶적절한 인덱스가 없을 때 Sort의 부하를 줄이는 방법 ▶Pagination에서 Sort의 부하 줄이기 ▶주의사항 Order by 절에 의한 Sort의 부하는 성능에 치명적이다. Block I/O의 최소화는 분명 튜닝의 핵심이다. 하지만, Block I/O를 최소화 해도 Sort의 부하가 심하다면 결코 만족스런 성능을 내지 못한다. 특히 “페이징 처리용 SQL에는 Sort를 대신할 수 있는 인덱스가 있어야 성능을 확보할 수 있다”고 많은 튜너들이 주장한다. 맞는 말이다. 그렇게만 된다면 Sort가 전혀 발생하지 않을 테니까. 하지만, 다음과 같은 어려움도 있다. 인덱스 최적화가 힘든 이유 첫 번째, 인덱스를 모든 조회화면의 기준에 맞게 만들려면 테이블마다 많은 수의 인덱스가 필요할 것이다. 두 번째, .. 공감수 21 댓글수 11 2011. 3. 29.
오라클 Upgrade 후에 파티션을 만들 수 없어요 ▶11.2.0.2에서 파티션 생성시 용량부족 현상 ▶Partition Large Extents란 무엇인가 ▶Deferred Segment Creation과 Partition Large Extents의 관계 오라클 11.2.0.2 에서 황당한 일이 발생했다. DBA는 데이터가 없는 빈 테이블을 파티션으로 생성하려고 했다. 그런데 느닷없이 용량부족 에러가 발생한 것이다. 디스크용량은 10 Giga Bytes나 여유가 있으므로 이런 에러메시지를 만날 이유가 없다. 아무리 파티션이 많은 테이블이라도 기껏해야 100MB 정도의 공간만 있으면 테이블을 문제없이 생성했던 DBA로서는 이유를 알 수 없었다. 어찌되었건 문제를 해결해야 하므로 디스크를 30 Giga Bytes 추가했더니 더 이상 에러가 발생하지 않았다고.. 공감수 7 댓글수 0 2011. 3. 15.
창의력을 키우는 과학적인 방법 세 가지 ▶창의성을 얻는 방법의 문제점 ▶같은 결과를 놓고 왜 해석이 다를까? ▶창의성을 얻는 방법 세 가지 많은 사람들이 창의성을 원하고 있다. 이에 따라 여러 가지 창의성 관련서적이 나오고 있다. 그 서적들에서 창의성을 키우는 방법으로 다음과 같은 것들을 공통적으로 이야기 한다. 아마도 새로운 것을 발견할 때 사용하는 방법인 모양이다. “틀을 깨라” “반대로 생각하라” “다른 관점으로 생각하라” 원하는 것만 보게 된다 하지만 위의 말들을 이해하더라도 창의성을 확보할 수 없다. 왜냐하면, 사람은 보고 싶은 것만 보고, 듣고 싶은 것만 듣기 때문이다. 만약 당신도 그렇다면, 옆의 그림에서 컵만 보일 가능성이 높다. 물론 일부의 사람들은 정확한 관찰을 통해 남들이 못보는 것을 관찰 할 수 있다. 하지만 많은 사람들.. 공감수 11 댓글수 12 2011. 3. 7.
관계선을 함부로 긋는 이유 ▶ 부서-사원 모델에 대한 단상 ▶ 조회관계란 무엇인가 ▶ 전달관계와 조회관계의 차이점 거의 모든 프로젝트 현장에서 위와 같은 잘못된 모델이 등장한다. 위의 부서-사원 모델에서 틀린 곳을 발견할 수 있는가? 잘못된 점을 발견하지 못했다면, 여러분도 잘못된 모델링을 하고 있을 가능성이 높다. 이 글은 부서와 사원 사이에 존재하는 관계선이 잘못되었다는 것을 이야기 하고자 한다. 어느 설계자가 논리모델링을 하고 있었다. 그가 작업중인 위의 모델을 보는 순간 기대를 했지만 역시나 실망했다. 왜냐하면 부서엔티티에서 사원엔티티로 관계선을 긋는 것을 보았기 때문이다. 부서와 사원은 가장 기본적인 엔티티 아닌가? 핵심엔티티임에도 불구하고 관계선을 마음 내키는 대로 긋고 있는 것이다. 그래서 내가 그 설계자에게 다음과 .. 공감수 28 댓글수 23 2011. 2. 24.
분석함수의 성능개선 그 결과는? ▶분석함수의 비효율을 찾는 방법 ▶분석함수의 성능개선 원리 ▶분석함수의 실행계획 3부 - 심화과정의 모범답안 이번 글이 분석함수의 실행계획 시리즈의 마지막이다. 1부와 2부에서 분석함수의 실행계획에 대해서 알아보았다. 이 글(3부)은 새로 작성되었으며, 이전 글( 문제 출제용 )은 삭제하지 않고 그대로 두었음을 밝혀둔다. 나중에라도 문제를 풀어볼 사람은 이 글(답안)을 보지 말고, 이전 글을 보기 바란다. 각각의 답안은 오렌지색으로 표시해 두었으므로 쉽게 채점할 수 있을 것이다. 분석함수의 다섯 가지 원리 많은 수의 개발자, DBA, 튜너들은 분석함수를 만나면 식은 땀을 흘린다. 왜냐하면, 분석함수의 비효율을 어떻게 찾을 수 있는지, 또 그 비효율은 어떻게 제거 할 수 있는지 알 수 없기 때문이다. 기껏.. 공감수 9 댓글수 14 2011. 2. 18.
분석함수의 실행계획 - 심화과정 필자가 제안한 SQL 튜닝방법론을 읽어 보았다면 다음을 기억할 것이다. “SQL 튜닝방법론은 온라인 SQL 중 90% 만 해결할 수 있으며, 나머지 10%는 그때 그때 마다 다르게(On the fly 모드) 처리된다. 또한 그것들은 책이나 매뉴얼에 나와있지 않기 때문에 경험치 이거나 실험과 연구의 결과로 알아내는 것들이다.” 이번 글은 방법론에서 다룰 수 없는, 나머지 10%에 해당하는 경험치와 연구의 결과이다. 분석함수의 나머지 10% 오늘은 SQL 튜닝방법론에서 언급한 나머지 10%를 만났을 때 어떻게 해야 하는지 알아보자. 이번 글이 분석함수의 실행계획 시리즈의 마지막이다. 1부와 2부에서 분석함수의 실행계획에 대해서 알아보았다. 하지만 두 개의 글로도 분석함수와 관련된 성능이슈를 모두 알 수는 없.. 공감수 4 댓글수 12 2011. 2. 14.
분석함수의 실행계획 - 2부 빠른 이해를 위해서 이전 글을 먼저 보고 이 글을 읽기 바란다. 이 글의 1부에서 WINDOW SORT, WINDOW SORT PUSHED RANK, WINDOW NOSORT, WINDOW NOSORT STOPKEY OPERATION들을 정리해 보았다. 이번에는 나머지 네 가지 Operation에 관해 알아볼 것이다. 이번 시간을 마치면 분석함수의 실행계획은 모두 정리된다. WINDOW (SORT) WINDOW (SORT PUSHED RANK) WINDOW (NOSORT) WINDOW (NOSORT STOPKEY) 공감수 3 댓글수 12 2011. 2. 10.
분석함수의 실행계획 - 1부 Oracle Data Access Pattern Partition Access Pattern Oracle 조인 방법 25가지 필자는 위의 글들을 이미 게시하였다. 그래서 Access Path와 Join Method는 정리가 되었고, 블로그로 배포되었으므로 그것으로 끝이라고 생각했다. 하지만 어느 개발자와 대화를 해보니 그런 생각이 짧았음을 알게 되었다. 개발자 : 위의 3가지 문서는 잘 보고 있습니다. 하지만 Access Path에 관해서는 큰 구멍이 있습니다. 필자 : 네? 무슨 말인가요? 개발자 : 분석함수는 Access Path를 변경시킵니다. 즉 분석함수를 어떻게 사용하느냐에 따라 실행계획의 Operation이 변경되므로 여타의 함수와는 엄연히 다릅니다. 그러므로 수석님께서 분석함수와 관련된 Ac.. 공감수 9 댓글수 12 2011. 2. 7.
SQL튜닝 방법론 SQL 튜닝책을 세 권정도 읽은 신입사원이 SQL 튜닝방법론을 요청하였다. 이유는 튜닝책에 방법론이 없다는 것이다. 튜닝 방법론이란 “SQL을 튜닝 해달라고 요청 받았을 때 내가 무엇 무엇을 해야 하나?” 이다. 즉 SQL 튜닝시의 To-Do 리스트(체크리스트)를 요구한 것이다. SQL 튜닝을 자주 하면서도, 그 안에 몇 가지 작업이 있는지 생각하지 못했다. 누가 그랬던가? 일상을 낯설게 느껴보라고… SQL 튜닝요청을 받았을 때 내가 어떤 일을 하는지 가르쳐 주면 되겠구나 하는 생각이 들었다. 그 결과 7가지 방법이 결론으로 도출되었다. 만약 7가지 방법을 모두 적용할 수 있는 경우임에도 불구하고 하나라도 빠진다면 최적화된 SQL을 만들 수 없다. 아래는 필자와 신입사원의 대화이다. 신입사원 : SQL .. 공감수 54 댓글수 20 2011. 1. 27.
같은 테이블을 두 번 읽었지만 일량이 틀려요 select /*+ full(a) full(b) leading(a) use_hash(b) */ a.col1, b.col2 from tab1 a, tab1 b where a.col1 = b.col2 ; 오해와 현실 “위의 SQL을 보면 from 절의 두 테이블은 동일하다. 그리고 건수가 많아서 힌트를 주었으므로, 둘 다 full table scan을 할 것이다. 따라서 위의 SQL을 실행하고 결과를 본다면, a 와 b의 일량(block I/O량)은 동일하다.”라고 알고 있는 사람이 많이 있다. 즉 a를 읽었더니 block I/O 량이 1000 블럭이라면 b를 읽을 때도 1000 블럭이 나올 것이라는 이야기다. 이런 주장이 사실일까? 결론부터 말하자면 사실이 아니다. b쪽이 더 많은 블럭을 scan 해야 한.. 공감수 5 댓글수 16 2011. 1. 14.
이공계 출신이 은유를 사용해야 하는 이유 글의 순서 1.쉽게 이해되는 글을 작성하는 방법 2.은유는 본능이다 3.은유의 사용규칙 4.은유를 사용해야 하는 과학적 이유 5.은유는 당신의 뇌를 속인다 “이공계 출신은 특히 은유를 많이 사용해야 한다. 그렇지 않으면 이해와 소통이 부족할 것이다.” 나는 이렇게 주장한다. 뭔 헛소린가 하고 생각할 것이다. 왜냐하면 감성을 자제하고, 이성을 강조하는 과학적인 글에서는 은유가 적합하지 않다고 생각하기 때문이다. 반면에 은유는 감성적인 것이므로 문학적인 글에서 사용해야 한다고 생각한다. 이런 생각이 누구의 주장으로부터 나온 것인지 모르겠지만, 명백한 오류이다. 왜냐하면 이공계의 말과 글에서 은유를 통제한 결과는 처참하기 때문이다. 즉 쉽게 이해할 수 없는, 어려운 말과 글을 양산하고 말았다. 서로 이해 할 .. 공감수 31 댓글수 11 2011. 1. 3.
Pagination과 분석함수의 위험한 조합 -대표적인 페이징 처리방법 -누적집계가 필요할 때 페이징(부분범위) 처리방법 -Pagination의 단점을 이용하는 방법 주의사항 이 글에서 사용되는 분석함수는 현재 row 까지의 누적집계(Cumulative total) 이다. 이와 반대로 전체집계(Grand Total)나 그룹집계(Sub total)는 부분범위처리를 할 수 없다. 왜냐하면 데이터를 모두 읽어야만 결과를 낼 수 있기 때문이다. 하지만 누적집계는 데이터가 sort 되어 있고, 이미 출력된 컬럼들의 값을 알 수 있다면 부분범위처리가 가능하다. 우리는 이점을 이용할 것이다. 상황 Time Out이 발생하여 개발자가 종이 한 장을 들고 급하게 뛰어왔다. 개발자: 페이징 처리를 했고, 최적의 인덱스도 존재하고, 그 인덱스를 잘 타는데도 Time .. 공감수 4 댓글수 26 2010. 12. 23.
과학과 철학의 간격 -개발 방법론 VS 모델링 방법론 최근에 어느 모델러에게 “~개발 방법론 때문에 미치겠다.”는 말을 들었다. SI 프로젝트에 참여하면 여러 가지 방법론이 등장한다. 하지만 그것들은 개발 방법론 혹은 관리방법론이기 때문에 분석과 사고, 그리고 통찰이 중요한 모델링을 수행하는 데는 오히려 방해가 되는 경우가 있다. 왜냐하면 이런 방법론들은 복잡한 건물을 세우는 방법, 건물 내부를 채우는 방법, 그리고 최소의 인력으로 최소의 시간을 들여 프로젝트를 마치는 방법에 관심이 집중되어 있기 때문이다. 이런 방법들은 프로젝트의 일정이 진행되는 입장에서 보면 관리적이며 과학적인 방법이다. 하지만 데이터 모델링에는 그런 과학적 방법이 얼마나 보탬이 될지는 미지수 이다. 데이터의 품질은 어떻게 보장되나? 많은 이들이 데이터.. 공감수 2 댓글수 2 2010. 12. 15.
검색조건을 동적으로 바꾸어야 할 때 -동적인 조회조건에서 SQL 작성법 -다양한 검색조건에서 SQL 튜닝방법 -쿼리변환의 부정적 측면 해결 아래는 신입사원과 김대리의 대화내용이다. 신입사원이 머리를 긁고 있다. 문제가 어려운 모양이다. 신입사원: 상황에 따라서 조회조건이 달라지는데 어떻게 처리하죠? 김대리: 각각의 상황에 대해 union all로 처리하고 서로 다른 SQL로 처리하면 되. 신입사원: 네 알겠습니다. (조금 후에) 김대리님, 그렇게 하면 SQL이 너무 길어서 복잡해져요. 총 6가지의 조건이 상황에 따라 달라지기 때문이죠. 김대리: 그럼 방법이 없지. Dynamic SQL로 작성해. 단 Dynamic SQL을 쓰되 바인드 변수를 사용해야 돼. 신입사원: 그건 어떻게 사용하죠? 제가 Dynamic SQL 사용법을 몰라서 그럽니다.. 공감수 15 댓글수 1 2010. 12. 14.
3부 - 변경이력 테이블에 종료일자가 필요한가? -변경이력에서 full table scan을 동반하는 대용량 배치의 성능관점 이 글을 이해하기 위해 이전 글들을 먼저 읽기 바란다. 이전 글의 요약 첫 번째 글과 두 번째 글에서 변경이력에 종료일자를 추가하는 것이 성능상 유리하다는 네 가지 주장이 사실과 다름을 증명해 보았다. 즉 시작일자만으로도 종료일자+시작일자 인덱스와 같은 성능을 발휘하며, 때에 따라서는 시작일자 인덱스가 더 빠르기까지 하다. 종료일자를 추가해야 한다는 네 가지 주장을 정리하면 다음과 같다. 1. 비교적 최근 데이터를 구할 때는 종료일자 + 시작일자가 빠르다. 그러므로 종료일자를 추가해야 한다. 2. 특정 시점의 데이터를 보기 위해서는 종료일자 + 시작일자 인덱스를 이용하여 BETWEEN을 쓰면 되므로 시작일자만 사용하는 것에 비해.. 공감수 1 댓글수 8 2010. 12. 3.
2부 - 변경이력 테이블에 종료일자가 필요한가? -변경이력에서 여러 건을 조회 할 때의 해결방법 -변경이력 조회시 rownum의 활용 들어가기 전에 이 글을 읽기 위해서 지난번 글(변경이력 테이블에 종료일자가 필요한가?)을 먼저 읽고 오기 바란다. 그렇지 않으면 이해하기 힘들며 이 글과 어떻게 연결되는지 알 수 없다. 이전 글이 다분히 이론적이었다면 이번에는 실전적인 문제를 다룬다. 이 글에서 언급된 기법을 알지 못하면 실무에서 종료일자가 없이 시작일자만을 사용했을때 성능이 떨어질 것이다. 이 글은 종료일자의 장단점에 대해 충분한 고민후에 사용했던 사람들에 대한 공격이 아님을 일러둔다. 역정규화에 대한 위험성을 알리고, 정규형 또한 빠른 성능을 가졌다는 것을 증명함으로써 종료일자를 사용할 때는 많은 고민이 있어야 한다는 것을 주장하는 것이다. 글의시작.. 공감수 2 댓글수 10 2010. 11. 24.
변경이력 테이블에 종료일자가 필요한가? 테스트에 사용할 이력테이블을 현실에 가깝에 만들어서 테스트 해달라는 요청이 있었습니다. 그래서 첨부파일을 따로 올립니다. 고객번호가 테이블과 인덱스에 추가된것을 제외하고 내용은 대동소이합니다. 2010.11.18 -점이력과 선분이력의 차이는 무엇인가? -선분이력은 언제 필요한가? 주문상품 변경이력 테이블에 종료일시가 보인다. 설계자에게 종료일시가 왜 필요한지 물어보았다. “선분이력을 만들기 위함입니다.” 왠 선분이력? 주문상품 변경이력에 선분이력이 왜 필요한지 다시 물어 보았다. “최근에 변경된 주문 데이터를 가져오려면 주문번호 + 상품번호 + 종료일시 + 시작일시로 PK 인덱스를 구성해야 빠르게 가져올 수 있기 때문입니다. 알만 하신 분이 이런것을 왜 물어봅니까?” 어이쿠 한방 맞았다. 이럴때는 물러나.. 공감수 3 댓글수 30 2010. 11. 17.
Index_desc 힌트와 rownum = 1 조합은 안전한가? 부제 : min/max값을 안전하고 빠르게 구하는 방법 최종일자, 최종순번을 구하기 위한 전통적인 방법은 index desc 힌트와 rownum = 1 조합이었다. 하지만 이것은 대단히 위험한 방법이다. 왜냐하면 튜닝을 하기 전에 값이 맞아야 하며, 성능튜닝은 그 이후의 문제이기 때문이다. 위의 방법은 인덱스의 구성컬럼이 변경 혹은 삭제되거나, 인덱스명이 바뀌면 max 값을 구하지 못한다. 즉 성능을 향상시키기 위해 값이 틀릴 수 있는 가능성을 열어놓은 것이다. 이런 방법은 어떤 이유로도 받아들여져서는 안 된다. 나 또한 예전에 이런 방법을 사용했지만 이는 필자의 명백한 잘못이었다. 올바른 값을 얻어야 하고 성능도 충족해야 하므로 오라클은 first_row(min/max) operation을 내놓았다. .. 공감수 17 댓글수 12 2010. 11. 9.
도대체 말하고 싶은 게 뭐야? 부제: 긴 글을 요약해야 하는 이유 우리는 매일 많은 시간을 투자하며 글을 쓴다. 기획서, 제안서, 보고서, 업무요청서, 분석서, 문제해결서처럼 Business와 관련된 것으로부터 블로그, 이메일, 메신저, 일기처럼 개인적인 것까지 글의 종류는 많다. 그런데 Business와 관련된 글은 대부분 딱딱하고, 복잡하고, 분량이 많아서 보기 힘들다. 업무자체가 딱딱하고, 복잡한 것은 어쩔 수 없지만 글의 분량은 조절 할 수 있다. 아니, 조절해야 한다. 분량을 조절하지 않으면 당신의 글은 읽히지도 않고 휴지통으로 갈 것이다. 왜냐하면 몇 십 페이지 혹은 몇 백 페이지에 달하는 글을 모두 읽은 후 의사를 결정하는 사람은 많지 않기 때문이다. 만약 그 글을 모두 읽었다고 해도 다음과 같은 말을 들을 것이다. “보.. 공감수 2 댓글수 2 2010. 11. 3.
Cardinality Feedback이 위험할 때 부제: Cardinality Feed Back의 개념과 사용예제 이번 글은 난이도가 높으므로 익숙하지 않은 사람은 Cardinality Feedback의 개념 정도만 이해하기 바란다. 물론 이 블로그를 꾸준히 구독한 독자라면 어려움 없이 볼 수 있다. 현재 많은 시스템이 Oracle11g로 옮겨가고 있다. 11g는 새로운 기능이 많이 추가되었다. 하지만 새롭고 좋은 기능이라도 완벽하지 못하면 문제가 될 수 있다. 오늘은 11g의 새 기능 때문에 성능문제가 발생하는 경우를 소개한다. 시스템이 운영 중에 있을 때 가장 곤욕스러운 경우 중 하나는 SQL의 실행계획이 갑자기 바뀌어 성능이 나빠지는 것이다. SQL과 인덱스 그리고 통계정보가 모두 바뀌지 않아도 실행계획은 바뀔 수 있다. 예를 들면 Oracle11.. 공감수 5 댓글수 10 2010. 10. 25.
공지 - Cardinality Feed Back이 위험할 때 블로그가 일주일에 한번만 업데이트 되기 때문에 많은 분들이 어떤 내용이 블로그에 올라올지 궁금해 하시는것 같습니다. 그래서 시간이 허락한다면 블로그에 올라갈 내용을 미리 공지 하겠습니다. 제목: Cardinality Feed Back이 위험할 때 부제목: Cardinality Feed Back의 개념과 사용예제 문서의 목적 1. Oracle11의 새 기능인 Cardinality Feedback의 개념을 알아보고 실행예제를 분석해본다. 2. Cardinality Feedback이 문제가 되는 경우를 살펴보고 해결방법을 제시한다. 목차 1. 서론 2. Cardinality Feedback의 개념: 소제목 예측, 실행, 비교, 그리고 전달 부분 3. Cardinality Feedback의 작동방법: 소제목 C.. 공감수 2 댓글수 1 2010. 10. 22.
union과 union all의 숨겨진 차이점 부제목: view에서 union, minus, intersect를 제거하라 많은 사람들이 union과 union all의 차이점에 대해 알고 있다. 즉 union은 Sort와 중복제거라는 기능으로 인해 UNION ALL에 비하여 성능이 떨어진다는 것이다. 옳은 말이다. 하지만 union대신에 union all을 써야 하는 또 다른 이유가 있다는 것을 아는 사람은 얼마나 될까? 이 사실을 알지 못하면 불필요한 엑세스가 추가될 수 있으므로 성능이 저하된다. 먼저 고객테이블을 이용하여 뷰를 하나 만들고 그것을 이용한 SQL문을 만들어 보자. 환경 : Oracle 11.2.0.1 create or replace view vw_cust5 as select * from customers union --> union.. 공감수 9 댓글수 6 2010. 10. 18.
논증모형은 무엇이며 왜 필요한가 부제목: 논리적인 생각과 글쓰기의 도구- 논증모형(논리모델) The War는 예술성이 부족한 영화인가? 2007년 여름 우리는 심형래 감독의 영화 는 두 가지 이유로 이슈가 되었다. 화려한 컴퓨터그래픽과는 대조적으로 스토리가 엉망이라는 것이다. 일부 인문학계에서는 스토리에 예술성이 더해졌다면 좀더 완벽한 영화가 되었을 것이라고 주장한다. 하지만 예술성이 문제가 아니라 논리적이지 않은 스토리전개가 문제이다. 가장 문제가 되었던 영화의 세 장면을 분석해보자. 1. 조선의 남녀가 아무런 암시도 없이 몇 백 년이 지난 후 미국에서 환생하는 장면 2. 갑자기 하늘에서 떨어진 착한 용의 도움으로 나쁜 용이 제거되는 장면 3. 사랑하는 사이가 아닌 남녀 주인공이 아무런 계기도 없이 바로 키스를 하는 장면 위의 세가지.. 공감수 9 댓글수 5 2010. 10. 13.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.