의 
블로그
[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
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
'오라클' 카테고리의 다른 글
| (Oracle 10g) dbms_stats.gather_schema_stats 수행에 시간이 너무 많이 걸려요... (1) | 2008.01.02 |
|---|---|
| db_file_multiblock_read_count 파라미터의 몰락... (3) | 2007.12.30 |
| [Oracle is Mad] Index Rebuild를 둘러싼 논쟁 - Part3 (3) | 2007.12.28 |
| Oracle Upgrade에 의한 실행 계획 이상과 Stored Outline (0) | 2007.12.27 |
| [Oracle is Mad] Index Rebuild를 둘러싼 논쟁 - Part2 (4) | 2007.12.24 |