사용자 도구

사이트 도구


study:oracle:datadb:1week_2

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
study:oracle:datadb:1week_2 [2010/05/06 16:18]
ahmax
study:oracle:datadb:1week_2 [2010/05/06 17:29] (현재)
ahmax
줄 44: 줄 44:
  
 ==== 2.1.2 B-tree 인덱스의 조작(Operation) ==== ==== 2.1.2 B-tree 인덱스의 조작(Operation) ====
-   * **인덱스 생성(Creation)**+===가.인덱스 생성(Creation)===
 {{:study:oracle:datadb:b-tree3.jpg|}} {{:study:oracle:datadb:b-tree3.jpg|}}
       - 테이블을 액새스하여 정렬을 수행.       - 테이블을 액새스하여 정렬을 수행.
줄 54: 줄 54:
  
    * 위와 같은 방법으로 인덱스가 저장되기 때문에 인덱스 블럭에 많은 로우를 담게 될 경우 리프 블럭 감소, 브랜치 블럭 증가 둔화(블럭의 깊이 감소)    * 위와 같은 방법으로 인덱스가 저장되기 때문에 인덱스 블럭에 많은 로우를 담게 될 경우 리프 블럭 감소, 브랜치 블럭 증가 둔화(블럭의 깊이 감소)
-        * 최대한 인덱스 컬럼의 수를 줄인다. + 
-        * 큰 블럭 사이즈(DB_BLOCK_SIZE)를 지정. +== 인덱스 블록에 보다 많은 로우를 담기 위해 취할 수 있는방법 == 
-        * PCTFREE를 최소로 정의. +   * 최대한 인덱스 컬럼의 수를 줄인다. 
-        * 압축을 활용하는 방법 +   * 큰 블럭 사이즈(DB_BLOCK_SIZE)를 지정. (데이터베이스 전체, 혹은 테이블스페이스에 대한 정의이다.) 
 +   * PCTFREE를 최소로 정의. (0으로 해도 무관함) 
 +   * 압축을 활용하는 방법 
  
   CREATE INDEX ord_customer_idx   CREATE INDEX ord_customer_idx
줄 64: 줄 66:
  
 :------------------------------------------------------------------------------------------------------ :------------------------------------------------------------------------------------------------------
-   * **인덱스 블럭의 분할(SPILT)**+===나.인덱스 블럭의 분할(SPILT)===
       * 인덱스 로우는 정렬이 되어 저장 되어야 하는 이유 때문에 이미 생성된 구조에 새로운 로우가 삽입되면 기존의 위치에 파고 들어가는 문제 발생       * 인덱스 로우는 정렬이 되어 저장 되어야 하는 이유 때문에 이미 생성된 구조에 새로운 로우가 삽입되면 기존의 위치에 파고 들어가는 문제 발생
 {{:study:oracle:datadb:b-tree4.jpg|}} {{:study:oracle:datadb:b-tree4.jpg|}}
줄 72: 줄 74:
  
 :------------------------------------------------------------------------------------------------------ :------------------------------------------------------------------------------------------------------
-   * **데이터의 삭제 및 갱신**+===다.데이터의 삭제 및 갱신===
       * 데이터를 삭제했을 경우 테이블의 로우는 제거되지만 인덱스의 로우는 삭제되었다는 표시(flag)만 추가된다.(저장공간낭비와 스캔시 액세스 블럭 증가)       * 데이터를 삭제했을 경우 테이블의 로우는 제거되지만 인덱스의 로우는 삭제되었다는 표시(flag)만 추가된다.(저장공간낭비와 스캔시 액세스 블럭 증가)
       * 한 리프 블럭이 모두 삭제 되었을 경우 브랜치 블럭에 해당 리프 블럭을 가리키는 로우도 삭제 표시가 된다.       * 한 리프 블럭이 모두 삭제 되었을 경우 브랜치 블럭에 해당 리프 블럭을 가리키는 로우도 삭제 표시가 된다.
줄 79: 줄 81:
       * 데이터처리(DML)가 많이 수행되는 테이블은 정기적으로 재생성을 할 필요가 있다.       * 데이터처리(DML)가 많이 수행되는 테이블은 정기적으로 재생성을 할 필요가 있다.
 :------------------------------------------------------------------------------------------------------ :------------------------------------------------------------------------------------------------------
-    * ** 인덱스를 경유한 검색**+===라.인덱스를 경유한 검색===
 {{:study:oracle:datadb:b-tree5.jpg|}} {{:study:oracle:datadb:b-tree5.jpg|}}
    * lmc는 브랜치 블럭의 첫 번째 로우의 값보다 적은 값을 갖는 하위의 블럭의 주소정보(dba:data block address)를 말한다.    * lmc는 브랜치 블럭의 첫 번째 로우의 값보다 적은 값을 갖는 하위의 블럭의 주소정보(dba:data block address)를 말한다.
-   루트 블록을 찾는다. + 
-   주어진 값보다 같거나 최소값을 찾는다.(찾는값 >= 인덱스값) +   1.루트 블록을 찾는다.    
-   - 찾는 값 < 인덱스 값 (Lmc에 있는 dba로 이동)  +   2.주어진 값보다 같거나 최소값을 찾는다.(찾는값 >= 인덱스값) 
-   - 찾는 값 = 인덱스 값 (해당 dba로 이동)  +      찾는값 < 인덱스 값 (Lmc에 있는 dba로 이동)  
-   - 찾는 값 > 인덱스 값 (검색 후 찾는 값 = 인데스 값이면 해당 dba로 이동 그렇지 않으면, 찾는 값 < 인데스 값을 만족하는 인덱스 최소값) +      찾는 값 = 인덱스 값 (해당 dba로 이동)  
-   리프 블록을 찾을 때까지 ② 의 단계를 반복해서 수행. +      찾는 값 > 인덱스 값  
-   리프 블록에서 주어진 값을 가진 키를 찾아 존재하면 ROWID를 이용해 테이블을 액세스하고, 그렇지 않으면 'No Data found'로 결과 반환 만약, col2의 조건을 'ACC'가 아닌 'AC%'로 바꾸면 Col1 = 'B'이면서 Col2 = 'AC'보다 같거나 큰 것에서 스캔을 시작, 'AD' 보다 작으면 테이블을 액세스하고, 그렇지 않으면 종료한다.+         (검색 후 찾는 값 = 인데스 값이면 해당 dba로 이동 그렇지 않으면,  
 +         찾는 값 < 인데스 값을 만족하는 인덱스 최소값) 
 +   3.리프 블록을 찾을 때까지 ② 의 단계를 반복해서 수행. 
 +   4.리프 블록에서 주어진 값을 가진 키를 찾아 존재하면 ROWID를 이용해 테이블을 액세스하고, 
 +     그렇지 않으면 'No Data found'로 결과 반환 만약, col2의 조건을 'ACC'가 아닌 'AC%' 
 +      바꾸면 Col1 = 'B'이면서 Col2 = 'AC'보다 같거나 큰 것에서 스캔을 시작, 'AD' 보다  
 +      작으면 테이블을 액세스하고, 그렇지 않으면 종료한다.
  
 :------------------------------------------------------------------------------------------------------ :------------------------------------------------------------------------------------------------------
  
-=== B-tree인덱스의 문제점 ===+=== 마.B-tree인덱스의 문제점 ===
    * B-TREE인덱스에서는 실제 컬럼 값을 인덱스에도 보관하고 있어야 한다는 점이 대용량 데이터를 관리할 때 부담이 된다.    * B-TREE인덱스에서는 실제 컬럼 값을 인덱스에도 보관하고 있어야 한다는 점이 대용량 데이터를 관리할 때 부담이 된다.
    * B-TREE인덱스 컬럼값의 분포도가 좋아야 한다는 점    * B-TREE인덱스 컬럼값의 분포도가 좋아야 한다는 점
줄 111: 줄 119:
    * 루트 블록이나 브랜치 블록은 B-tree인덱스와 같은 구조로 되어 있으나 리프블록은 비트맵으로 구성되어 있다.    * 루트 블록이나 브랜치 블록은 B-tree인덱스와 같은 구조로 되어 있으나 리프블록은 비트맵으로 구성되어 있다.
 {{:study:oracle:datadb:bitmap1.jpg|}} {{:study:oracle:datadb:bitmap1.jpg|}}
- +{{:study:oracle:datadb:k-4.jpg|}}
-=== 생성절차 === +
-   인덱스를 생성하고자 하는 컬럼의 값들을 찾기 위해 테이블 스캔을 한 후  +
-   - bitmap generator에 의해 컬럼값, start rowid, end rowid , bitmap을 갖는 인덱스 엔트리를 생성한다.  +
-   - 2단계에서 생성된 Bitmap들을 B-tree구조에 넣기 쉽도록 key값과 start rowid 순으로 정렬한다. +
-   - 마지막 단계에서는 정렬된 인덱스 엔트리들을 단순히 B-tree구조로 삽입한다.+
  
 === 특성 === === 특성 ===
줄 124: 줄 127:
       * 수정이 빈번하게 발생하는 컬럼은 인덱스의 크기가 크게 증가하고 블록레벨 잠금(Block Level Locking)으로 인해 많은 부하가 유발될 수 있다.       * 수정이 빈번하게 발생하는 컬럼은 인덱스의 크기가 크게 증가하고 블록레벨 잠금(Block Level Locking)으로 인해 많은 부하가 유발될 수 있다.
       * 데이터 웨어하우스 업무에 주로 활용된다.       * 데이터 웨어하우스 업무에 주로 활용된다.
 +
 +** >> 데이터 웨어하우스 ** [[http://100.naver.com/100.nhn?docid=717310]] 
 +
 +=== 생성절차 ===
 +   - 인덱스를 생성하고자 하는 컬럼의 값들을 찾기 위해 테이블 스캔을 한 후 
 +   - bitmap generator에 의해 컬럼값, start rowid, end rowid , bitmap을 갖는 인덱스 엔트리를 생성한다. 
 +   - 2단계에서 생성된 Bitmap들을 B-tree구조에 넣기 쉽도록 key값과 start rowid 순으로 정렬한다.
 +   - 마지막 단계에서는 정렬된 인덱스 엔트리들을 단순히 B-tree구조로 삽입한다.
  
 === 제한사항 == === 제한사항 ==
줄 144: 줄 155:
    - COL3 < 100 인 비트맵을 읽어 머지(BITMAP MERGE)를 수행하여 하나의 비트맵을 만든다.    - COL3 < 100 인 비트맵을 읽어 머지(BITMAP MERGE)를 수행하여 하나의 비트맵을 만든다.
    - **2**와 **3**에서 수행한 결과에 대해 OR연산(BITMAP OR)을 수행하여 조건을 만족하는 최종결과 비트맵을 만들고 ROWID로 변형하여 테이블을 엑세스 한다.    - **2**와 **3**에서 수행한 결과에 대해 OR연산(BITMAP OR)을 수행하여 조건을 만족하는 최종결과 비트맵을 만들고 ROWID로 변형하여 테이블을 엑세스 한다.
- 
-   * **제한사항** 
-      *  파티션테이블에서 Global Index에는 비트맵인덱스를 만들 수 없다. 
-      * 비트맵인덱스는 RBO(Rule Base optimizxer) mode에서는 사용될 수 없다. 
  
 ===== B-Tree 인덱스와 비트맵(Bitmap)인덱스의 비교 ===== ===== B-Tree 인덱스와 비트맵(Bitmap)인덱스의 비교 =====
study/oracle/datadb/1week_2.1273130292.txt.gz · 마지막으로 수정됨: 2010/05/06 16:18 저자 ahmax