태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'90-10 Split'에 해당되는 글 1건

  1. 2007.12.28 [Oracle is Mad] Index Rebuild를 둘러싼 논쟁 - Part3 (3)

[Oracle is Mad] Index Rebuild를 둘러싼 논쟁 - Part3

오라클 2007.12.28 23:51
Index Rebuild 논쟁을 이해하기 위해 이해해야할 또 하나의 개념이 Index Split이다. Index를 Rebuild한 후에 발생하는 대표적인 부작용이 Split이기 때문이다.

Index Split이란, Leaf Node나 Branch Node가 꽉 찬 상태에서 새로운 키 값이 삽입될 때 공간 확보를 위해서 키 값을 Split하는 것을 말한다. Index Split이 발생하면 새로운 블록을 할당받고, 기존의 키 값들을 기존 블록과 새로운 블록으로 나누어(Split) 저장한다.

Index Split은 보통 50-50 Split과 90-10 Splt으로 구분된다.

1. 50-50 Split은 아래 그림과 같이 중간에 위치한 Leaf Node가 Split되는 경우에 발생한다. 기존 블록과 새로운 블록이 값을 50:50으로 나누어 갖는다고 해서 50-50 Split이라는 이름이 붙여졌다.

사용자 삽입 이미지




















아래에 50-50 Split이 발생한 실제 예가 있다.

(Split 전)
----- begin tree dump
branch: 0x141b81f 21084191 (0: nrow: 3, level: 1)
   leaf: 0x141b837 21084215 (-1: nrow: 69 rrow: 69)
   leaf: 0x141b83d 21084221 (0: nrow: 69 rrow: 69)
   leaf: 0x141b83a 21084218 (1: nrow: 62 rrow: 62)
----- end tree dump

(Split 후)
----- begin tree dump
branch: 0x141b81f 21084191 (0: nrow: 4, level: 1)
   leaf: 0x141b837 21084215 (-1: nrow: 69 rrow: 69)
   leaf: 0x141b83d 21084221 (0: nrow: 40 rrow: 40) 
   leaf: 0x141b834 21084212 (1: nrow: 30 rrow: 30) 
   leaf: 0x141b83a 21084218 (2: nrow: 62 rrow: 62)
----- end tree dump


2. 90-10 Split은 아래 그림과 같이 가장 오른쪽 마지막에 위치한 Leaf Node에 최대값이 Insert되는 경우에 발생
한다. 기본 블록과 새로운 블록이 값을 90:10으로 나누어 갖는다고 해서 90-90 Split이라는 이름이 붙여졌다.
엄밀하게 말하면 90-10이 아니라 99-1이 맞을 것이다. 새로운 블록에는 기존 블록 중 최대 값만이 들어가고 나머지는 모두 기존 블록에 남기 때문이다. 그리고 이 새로운 블록에 새로운 최대값이 추가된다.

최대값이 Insert되는 경우에 한해 90-10 Split을 수행하는 이유는 Split의 회수를 줄이기 위해서이다. 제일 오른쪽 블록에 Insert가 집중되는 경우에 대비해 제일 오른쪽 블록에 여유 공간을 많이 만들기 위한 일종의 트릭이다.

사용자 삽입 이미지




















아래에 90-10 Split이 발생한 실제 예가 있다.

(Split 전)
----- begin tree dump
branch: 0x141b81f 21084191 (0: nrow: 4, level: 1)
   leaf: 0x141b837 21084215 (-1: nrow: 69 rrow: 69)
   leaf: 0x141b83d 21084221 (0: nrow: 40 rrow: 40) 
   leaf: 0x141b834 21084212 (1: nrow: 30 rrow: 30) 
   leaf: 0x141b83a 21084218 (2: nrow: 69 rrow: 69)
----- end tree dump

(Split 후)
----- begin tree dump
branch: 0x141b81f 21084191 (0: nrow: 5, level: 1)
   leaf: 0x141b837 21084215 (-1: nrow: 69 rrow: 69)
   leaf: 0x141b83d 21084221 (0: nrow: 40 rrow: 40)
   leaf: 0x141b834 21084212 (1: nrow: 30 rrow: 30)
   leaf: 0x141b83a 21084218 (2: nrow: 68 rrow: 68) 
   leaf: 0x141b840 21084224 (3: nrow: 2 rrow: 2)   
----- end tree dump


3. Branch Node와 Root Node는 항상 50-50 Split을 수행한다. Root Node가 Split되면 Index의 높이가 높아진다.



Index Split은 Index에 키 값이 추가됨에 따라 발생하는 자연스러운 현상이며 인덱스의 균형(Balance)를 맞추는 과정이기도 하다. 교묘한 Index Split 과정에 의해 Oracle은 Index의 균형을 유지하고, 모든 Leaf Node들이 적절하게 Key를 나누어 가지도록 유도한다.

하지만 Index Split은 성능면에서는 매우 불리한 것이다.

- Index Split은 새로운 블록을 할당받고 Key을 옮기는 등의 복잡한 작업을 수행한다. 이 과정들이 모두 Redo에 기록되어야 하기 때문에 많은 량의 Redo를 유발한다.
- Index Split이 이루어지는 동안 해당 블록에 대해 키값이 변경되면 안되기 때문에 DML이 블로킹된다. 이 과정에서 enq: TX - index contention, RAC환경에서는 gc current split 대기 이벤트가 발생한다.

Index Split은 Index Rebuild의 부작용을 언급할 때 반드시 등장하는 개념이다. 이 글을 통해 최소한의 필요한 개념을 익히기를 바래본다. 이 시리즈의 추후 글들에서 다시 한번 이에 대해 언급하게 될 것이다.

다음 글에서는 본격적으로 Index Rebuild와 Index Scan의 성능에 대해 논의하게 될 것이다.

참조) Index Split에 의한 enq: TX - index contention 이벤트와 gc current split 이벤트 현상의 원인과 해결책은 아래 책에 상세히 나와있다.(내가 적은 책을 쓸려니 어색하기 하지만...)

http://book.interpark.com/product/BookDisplay.do?_method=Detail&sc.shopNo=0000400000&sc.dispNo=&sc.prdNo=11505916
http://book.interpark.com/product/BookDisplay.do?_method=Detail&sc.shopNo=0000400000&sc.dispNo=&sc.prdNo=200701633




신고
Trackback 0 : Comments 3
  1. hoho 2008.05.20 08:04 신고 Modify/Delete Reply

    좋은글 잘 읽었습니다~
    "다음 글에서는 본격적으로 Index Rebuild와 Index Scan의 성능에 대해 논의하게 될 것이다.
    다음글은 언제 나오나요?
    넘 궁금~~

  2. 욱짜 2008.05.20 14:30 신고 Modify/Delete Reply

    어떻게 하다 보니까 완결을 못지었네요. 다만 다음 URL에서 제가 세미나에서 사용하는 교재의 온라인 버전이 있습니다. 필요하신 분은 참조하세요.
    http://wiki.ex-em.com/index.php/Oracle_is_mad#Index_Rebuild_.EB.85.BC.EC.9F.81

  3. 욱짜 2009.01.11 00:35 신고 Modify/Delete Reply

    혼란을 일으킬 의도는 당연히 없습니다. ^^

    사실 가이드라인이라는게 무의미합니다. 어떤 곳에서는 Index Rebuild를 한번도 하지 않았는데도 문제없이 운영되는 곳도 있고, 어떤 곳에서는 매우 자주 Index Rebuild를 하는 곳도 있습니다. 어떤 곳에서는 문제가 전혀 없는데도 Index의 크기가 기준치 이상 커지면 자동으로 Rebuild하는 곳도 있습니다.

    제가 의도하는 것은 왜 이런 일이 발생하는가? 이것을 좀 더 체계적으로 논의하고자 하는 것입니다. 이런 표현을 하셨죠.

    ------------------------------------------------------
    이것은 실무가 테스트 처럼 단순하지 않기 때문에
    delete된 공간을 계속 재사용 하지 못해서 늘어나겠죠..
    이런 상황이 계속 이어지다 보면 결국 index의 속도는 느려지게 되어 있습니다.
    ------------------------------------------------------

    왜 Delete된 공간이 재사용되지 못할까요? 이것은 실무와 테스트의 문제가 아니라 Oracle의 동작 방식에 관한 문젭니다. 어떤 경우에는 Oracle은 재사용을 매우 잘하는데, 어떤 경우에는 전혀 재사용을 못하는 것처럼 보입니다.

    또 index의 속도가 느려진다고 하셨는데, index를 scan하는 방식은 다양합니다. 그 중에 정확하게 어떤 Operation이 문제가 되고 있는 것일까요?

    제가 의도하는 역할은 그 메커니즘을 이해하자는 것이고
    현재 실제 운영하고 있는 시스템에서 Index 크기 문제와 그로 인한 성능 저하 현상이 어떻게 발생하며 어떻게 해결하는지는 철저하게 담당자의 몫이라고 생각합니다.

    결국 온라인에서 제가 할 수 있는 일은 의사로 말하면 과학적인 의학 상식을 공유하는 것이고, 실제 병을 어떻게 예방하고 치료하는 가는 개개인의 몫이거나 만일 전담의사(지원 엔지니어나 컨설턴트)가 있다면 그 분들의 몫이 될겁니다.

Write a comment

티스토리 툴바