성능고도화 1-6 IOT 클러스터 테이블 활용

IOT 

 - 인덱스 리프 블록이 곧 데이터 블록 

 - 오라클 IOT는 PK 컬럼 순으로만 정려할 수 있다. 

IOT 장단점 

 - IOT 장점 

   ● 인위적으로 클러스터링 팩터를 좋게 만드는 방법 중 하나 

   ● random 엑세스가 아닌 Sequential 방식으로 데이터를 엑세스 

   ● 넓은 범위를 엑세스 할 때 유리 

   ● PK 인덱스를 위한 별도의 세그먼트를 생성하지 않아도 됨 

  - IOT 단점 

   ● 데이터 입력시 느리다. ( 그러나, PK 인덱스를 두고 비교해 보면 차이가 거의 없다.) 

   ● 인덱스 분할 발생량 차이로 인한 성능차이가 크다. 

   ● Direct Path Insert 가 작동하지 않음 

IOT 사용 시기 

  - 크기가 작고 NL 조인으로 반복 룩업하는 테이블 

    (그러나, PK이외의 속성 크기 때문에 인덱스 높이가 증가한다면 역효과) 

  - 폭이 좁고 긴 테이블 

    (M:M 관계를 해소하기 위한 테이블) 

  - 넓은 범위를 주로 검색하는 테이블 

   ● Between, Like 같은 조건으로 넓은 범위를 검색하는 테이블 

       ( PK 이외 컬럼이 별로 없는 통계성 테이블에는 최적의 솔루션 ) 

       ( PK 구성 컬럼이 많은 통계성 테이블이 분석 관점과 엑세스 경로가 아주 다양할 시 

         BTree 결합 인덱스를 계속 추가는 저장공간이나 DML 부하 측면에 문제가 많아

         그럴 때 테이블을 IOT로 구성하면 효과적 )  

  - 데이터 입력과 조회 패턴이 서로 다른 테이블 

IOT 테이블의 정렬 순서 

  - 자주 사용하는 등치 조건을 선두에 구성하여 생성 

파티션 IOT

  - 파티션 IOT 구성시 컬럼 순서 중요 

Overflow 

  - PK 이외 컬럼이 많은 테이블일수록 인덱스 분할에 의한 DML 부하는 물론, 

    검색을 위한 스캔량도 늘어나기 때문이다. 

     (인덱스 분할에 의한 DML 부하는 인덱스 분할의 부하로 인하여 발생하는가 ?)  

  - 이 부분의 영역은 값은 저장해 두지만 출력이나 조회조건으로 거의 사용되지 않는다. 

  - 오라클은 PCTthreshold 또는 Including 둘 중 하나를 만족하는 컬럼을 Overflow 영역에 저장

  - overflow 영역을 읽을 때도 건건이 Random 엑세스가 발생한다.

  - overflow 영역에도 buffer pinning 효과가 나타난다. 

Secondary 인덱스 

 - 결론은 IOT는 Secondary 인덱스 추가 가능성이 크지 않을 때만 선택하는 것이 바람직하다. 

 - IOT Secondary 인덱스 

   ● logical rowid = PK + Physical Guess

   ● PCT_Direct_Access 가 100 일 때 physical Guess를 사용할 수 있다.  

 - 오라클은 secondary 인덱스의 Logical Rowid가 인덱스 키와 중복되면 이를 제거하고 

    그 밖의 컬럼만 저장한다.

인덱스 클러스터 테이블 

 - 클러스터 키 값이 같은 레코드가 한 블록에 모이도록 저장하는 구조

   한 블록에 모두 담을 수 없을 때는 새로운 블록을 할당해 클러스터 체인으로 연결

   ( 여러 테이블 레코드가 물리적으로 같이 저장될 수도 있다.)

 - 클러스터 테이블을 생성하려면 클러스터와 클러스터 인덱스가 필요하다 

 - 클러스터 인덱스의 키 값은 항상 Unique하며 1:M 관계를 갖는다. 

    이런 특성 때문에 Random 엑세스가 값 하나당 한 번씩 밖에 발생하지 않는다.

 - 클러스터 인덱스는 클러스터를 공유하는 테이블들이 공유해서 사용한다. 

 - 클러스터 테이블은 넓은 범위를 검색할 때 유용하다

인덱스 클러스터 테이블 종류

 - 단일 테이블 인덱스 클러스터 

 - 다중 테이블 인덱스 클러스터

클러스터 테이블과 관려된 성능 이슈

 - DML 성능이 다소 떨어지고 전에 없던 값을 입력할 때는 새로운 블록 할당 받아야 하기 때문에 

   더 느리다. 

    ( 클러스터를 만들지 않고 인덱스를 생성했을 경우는 비슷하다. 

      클러스터로 인하여 기존 인덱스를 두세게 없앨 수 있다면 DML부하가 줄 수있다. 

           - 아직 테스트 못해봄 )

 - data 삭제시 

    ● truc 사용할 수 없음

    ● drop 발생시에도 내부적으로 건건이 delete 작업 발생 

    ● 클러스터 자체를 지우는 것이 가장 빠르지만 클러스터를 지우면 

        클러스터링 된 테이블 모두 삭제 됨

DML 부하 외에 클러스터 테이블 관련한 성능 이슈 

 - Direct Path Loading을 수행할 수 없다. 

 - 파티셔닝 기능을 함께 적용할 수 없다. IOT의 경우는 Partitioned IOT가 가능하다. 

 - 다중 테이블 클러스터를 Full Scan 할 때는 다른 테이블 데이터까지 스캔하기 때문에 불리하다.

SIZE 옵션 

 - 하나의 블록에 담을 최대 클러스터 키 개수를 결정 

 - SIZE 옵션은 공간을 미리 예약해 두는 것일 뿐 그 크기를 초과했다고 

   값을 저장하지 못하도록 하지 않는다.

 - SIZE 옵션 때문에 데이터 입력이 방해 받지 않지만 대부분 클러스터 키 값이 한 블록씩을 

   초과한다면 굳이 이 옵션을 두어 클러스터 체인이 발생하도록 할 이유는 없다. 

해시 클러스터 테이블   

 - 해시 함수에 반환된 값이 같은 데이터를 물리적으로 함께 저장하는 구조 

 - 해싱 알고리즘을 이용해 클러스터 키 값을 데이터 블록 주소로 변환 

 - 가장 큰 제약은 등치조건 '=' 검색만 가능하다. 

 - 물리적인 인덱스를 따로 갖지 않기 때문에 해시 클러스터키로 검색할 때는 그만큼 블록I/O가 

   덜 발생한다는 이점이 생긴다.