1.2. 인덱스 일체형 테이블(Index-Organized Table)

테이블과 인덱스가 일체형으로 되어 있다는 것은 인덱스와 다른 일반 컬럼들이 모두 같은 위치에 저장된는 형태를 말한다
일체형 테이블은 분리형 테이블과 달리 인덱스와 테이블간의 랜덤액세스가 없다

1.2.1 분리형과 일체형의 비교

1.2.2 일체형 테이블의 구조 및 특징

• 인덱스와 테이블이 나누어져 있는 분리형 테이블과 달리 인덱스와 테이블이 데이터를 모두 가지고 있다
• 각 인덱스로우마다 임의의 위치에 흩어져 있는 테이블에 랜덤액세스하는 부담이 거의 없다
• 인덱스에 데이블데이터도 포함되어 인덱스만 스캔하는 경우 더 많은 블럭을 스캔해야 한다.
  기본적으로 기본키로 접근
  추가인덱스(Secondery Index)를 사용해도 기본기를 이용해야 한다
• 기본키로 이용해 만든 인덱스를 통해 다른 액세스형태를 가능하게 한다는 정도

추가적 인덱스가 적용가능한 경우
Secondery Index사용이 빈번하지 않거나 처리범위가 넓지 않은 경우 처럼 부담이 없는 경우 충분히 적용가능..
로우길이에 따라 발생할 수 있는 오버플로우
일체형 구조는 일반컬럼은 모두 보유하고 있기 때문에 길이가 증가할 확률이 매우 크다.

• 테이블 생성 시 적절한 파라미터를 지정함으로서 단점을 어느정도 해소할 수 있음.

• 장점
  인덱스와 칼럼들이 같이 저장되어 있기때문에 저장및 엑세스 효율이 증가(단 효과는 없음)
• 단점
  유연성이 부족
  인덱스와 컬럼들이 같이 있기 대문에 데이터 갱신시 로우들의 길이가 변하므로 발샐할수 있는 오버플로우 발생 즉 저장형태는 b-tree와 같은 구조이나 리프트노드에 데이터를 같이 저장하기 대문에 길이의 변화가 생기면 새로운 노드에 이관이 되기때문에 영구적인 주소가 될수 없다

1.2.3 논리적 ROWID와 물리적 주소(Physical guess)

논리적ROWID의 개념
분리형 테이블에서는 인덱스의 분할이 발생하더라도 테이블의 rowid는 변하지 않는데 반해 일체형은 인덱스자신이 테이블이므로 인덱스의 분할에 따라 rowid가 변할 수 있으므로 어떤 키값이 동일한 노드에 지속적으로 저장될 수 없다.
인덱스로우가 생성될 때 만들어져서 키분할에 의해 데이터블록의 위치가 달라져도 변경되지 않는다

• 키분할에 의해 해당 로우의 위치가 변경되었다면 논리적ROWID로 찾았을 경우 다른 로우가 존재할 수 있다는것.
• 그 로우가 존재할 가능성이 높은 주소를 나타내기 때문에 이것을 Physical Guess혹은 Guess라고 한다
• 데이터를 액세스할 때 값(ROWID)이 부정확한 값이라고 판명되면 그 때는 기본키를 이용한 액세스를 하게 된다(부정확한 값이 높다면 아예 사용되지 않느다.)
  논리적ROWID를 사용하는 이유
• 물리적 위치정보와 기본키가 상호보완작용을 하여 논리적으로 완벽한 ROWID역할을 수행
• Physical Guess가 완벽한 ROWID는 아니지만 극히 일부는 제외하고는 유효하다면 언제나 기본키로 액세스하는 것보다는 훨씬 유리
• ROWID를 이용한 적중률이 지나치게 저하되는 경우는 이미 일체형구조를 사용하지 않을것
  일체형 구조에서 Secondery Index사용 시
  물리적 위치정보가 정확하다면 일반적인 인덱스 스캔과 동일하지만, 적중률이 낮다면 오히려 기본키를 이용하여 액세스하는 것이 더 효율적이다
  물리적 위치정보를 사용하지 않는 경우
  1. Secondery Index를 액세스하여 기본키정보를 얻는다
  2. 기본키로 데이터블록을 액세스
  물리적 위치정보를 사용하는 경우
  1. 추가적인 인덱스를 액세스하여 물리적 위치정보를 참조한다
  2. 참조한 물리적 위치정보를 이용하여 데이터블록을 액세스한 후에 비교한다. 이때 기본키 값이 같으면 물리적 위치정보가 유효한 것으로 간주하여 액세스를 종료한다.
  3. 만약 유효하지 않다면 다시 기본키로 액세스하여 데이터 블록을 가져온다
  일체형 구조의 적용가능 예시
• 전자 카탈로그나 키워드 검색용 테이블
• 코드성 테이블
• 색인 테이블
• 공간 정보 관리용 테이블
• 대부분 기본키로 검색되는 테이블
• OLAP의 디멘젼 테이블
• 로우의 길이가 비교적 짧고, 트랜젝션이 빈번하게 발생되지 않는 테이블

1.2.4 오버플로우 영역(Overflow Area)

• 일체형 테이블의 부담요소
  인덱스와 모든 컬럼이 같은 장소에 저장된다는 것은 저장공간의 분할이 발생한다든지 저장 밀도가 나빠지는 등의 부담이 증가한다

• 부담을 줄일 수 있는 방법
• 가장 쉽고 확실한 방법은 같이 적재할 컬럼을 줄이는 것
• 즉 오버플로우 영역에 상대적으로 빈번하게 액세스되지 않는 것들을 옮겨두는 것
• 따라서 테이블 생성 시 컬럼을 지정할 때 순서를 잘 결정할 필요가 있다.

• 일체형의 체인
  IOT테이블 생성시 include와 pctthreshold를 이용하여 결정되며 일체형 체인은 전략적으로 사용할 수 있다.
  일체형의 체인은 단순히 체인되었다는 의미보다는 인덱스영역의 저장밀도를 향상시킬 수 있는 전략이라고 볼 수 있다.

1.2.5 일체형 테이블의 생성

CREATE TABLE iottab
(test_id VARCHAR2(5),
title_name VARCHAR2(150),
author VARCHAR2(20),
contents VARCHAR2(2048),
status VARCHAR2(2),
CONSTRAINT pk_testiot PRIMARY KEY (test_id) )
ORGANIZATION INDEX          ----①
TABLESPACE tbs_1            ----②
PCTTHRESHOLD 20             ----③
INCLUDING contents          ----④
OVERFLOW TABLESPACE indx    ----⑤

① ORGANIZATION INDEX : 일체형 테이블 생성을 정의하는 키워드

② TABLESPACE : 인덱스영역이 저장될 테이블 스페이스를 지정한다.STORAGE파라미터사용도 가능하다

③ PCTTHRESHOLD : 인덱스블록 내의 예약된 공간의 비율을 백분율로 지정한다.
단일 로우 크기가 (PCTTHRESHOLD/100)/*DB_BLOCK_SIZE보다 크게 되면 이 범위 이내의 크기 까지 인덱스 영역에 남겨두고 나머지 컬럼들은 모두 OVERFLOW영역으로 이동된다.
OVERFLOW를 지정하지 않았을 경우 데이터 입력이 실패한다.

④ INCLUDING : INCLUDING이후에 선언된 컬럼들은 오버플로우 영역에 저장된다
만약 INCLUDING이 지정되지 않았을때 로우의 크기가 PCTTHRESHOLD를 초과하면 오버플로우 영역에 저장된다
(특이한 점 : INCLUDING절이 적용되는 시점은 처음 로우가 저장될 때만이다. 로우인서트 시 인클루드에 선언된 컬럼을 NULL로 넣고 이후 UPDATE시 선언된 컬럼에 값을 입력하면 PCTTHRESHOLD를 초과하지 않는 한도내에서 인덱스영역에 저장된다.)

⑤ OVERFLOW TABLESPACE : 지정한 PCTTHRESHOLD값을 초과한 로우의 일부가 저장될 테이블스페이스를 지정

문서에 대하여

• 이 문서는 오라클클럽 대용량 데이터베이스 스터디 모임에서 작성하였습니다.
• {*}이 문서의 내용은 이화식님의 새로쓴 대용량 데이터베이스 솔루션을 참고했습니다.*
• 이 문서를 다른 블로그나 홈페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^\^