1. 1.2. 인덱스 일체형 테이블(Index-Organized Table)
   1. 1.2.1 분리형과 일체형의 비교
   2. 1.2.2 일체형 테이블의 구조 및 특징
   3. 1.2.3 논리적ROWID와 물리적 주소(Physical Guess)
   4. 1.2.4 오버플로우 영역(Overflow Area)
   5. 1.2.5 일체형 테이블의 생성

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

• 가장 일반적인 B-Tree 인덱스 구성은 "인덱스 컬럼 + ROWID"
• B-Tree형태의 인덱스를 경유하여 테이블을 엑세스 할 경우 두번의 논리적인 엑세스 발생
  • 1.인덱스 세그먼트 엑세스
  • 2.ROWID를 이용하여 데이터 세그먼트 엑세스

• 테이블과 인덱스가 일체형으로 되어 있다는 것은 인덱스와 다른 일반 컬럼들이 모두 같은 위치에 저장되어 있는 형태를 말함.
• 질의가 기본키를 스캔하고, 기본키의 길이가 로우에서 높은 비율을 차지한다면 일체형으로 구성하는 것이 저장 구조의 절약과 엑세스 효율도 개선됨.
• 분리형 구조에서는 처리 범위가 넓어지면 부담이 증가

• 테이블을 찾는 랜덤 엑세스 때문에 부담이 증가 (ROWID를 이용하여 임의의 위치에 있는 테이블 로우를 엑세스 하기 때문에 한 건을 엑세스 하기 위해 매번 새로운 블록을 엑세스 할 수도 있음)
  

1.2.1 분리형과 일체형의 비교

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

• 인덱스와 테이블이 나누어져 있는 분리형 테이블과 달리 인덱스와 테이블이 데이터를 모두 가지고 있음.
• 각 인덱스 로우마다 임의의 위치에 흩어져 있는 테이블에 랜덤 액세스하는 부담이 거의 없음.
• 인덱스에 데이블 데이터도 포함되어 인덱스만 스캔하는 경우 더 많은 블럭을 스캔해야 함.

기본적으로 기본키로 접근

• 추가인덱스(Secondary Index)를 사용해도 기본기를 이용해야 함.
• 기본키로 이용해 만든 인덱스를 통해 다른 액세스형태를 가능하게 함
  
  

추가적 인덱스가 적용 가능한 경우

• Secondary Index사용이 빈번하지 않거나 처리범위가 넓지 않은 경우처럼 부담이 없는 경우 충분히 적용가능.

로우길이에 따라 발생할 수 있는 오버플로우

• 일체형 구조는 일반 컬럼은 모두 보유하고 있기 때문에 길이가 증가할 확률이 매우 큼.
• 테이블 생성 시 적절한 파라미터를 지정하여 단점을 어느 정도 해소할 수 있음.

장점

• 인덱스와 칼럼들이 같이 저장되어 있기 때문에 저장 및 엑세스 효율이 증가(단 효과는 없음)

단점

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

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

논리적ROWID의 개념

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

• 키분할에 의해 해당 로우의 위치가 변경되었다면 논리적ROWID로 찾았을 경우 다른 로우가 존재할 수 있음.
• 그 로우가 존재할 가능성이 높은 주소를 나타내기 때문에 이것을Physical Guess혹은 Guess라고 함.
• 데이터를 액세스할 때 값(ROWID)이 부정확한 값이라고 판명되면 그 때는 기본키를 이용한 액세스를 하게 됨.(부정확한 값이 높다면 아예 사용되지 않는다.)

논리적ROWID를 사용하는 이유

• 물리적 위치정보와 기본키가 상호보완작용을 하여 논리적으로 완벽한ROWID역할을 수행
• Physical Guess가 완벽한ROWID는 아니지만 극히 일부는 제외하고는 유효하다면 언제나 기본키로 액세스하는 것보다는 훨씬 유리
• ROWID를 이용한 적중률이 지나치게 저하되는 경우는 이미 일체형구조를 사용하지 않을 것

일체형 구조의 적용가능

• 전자 카탈로그나 키워드 검색용 테이블
• 코드성 테이블
• 색인 테이블
• 공간 정보 관리용 테이블
• 대부분 기본키로 검색되는 테이블
• OLAP의 디멘젼 테이블
• 로우의 길이가 비교적 짧고, 트랜젝션이 빈번하게 발생되지 않는 테이블

• 일체형 구조에서 추가적인 Index사용 시 물리적 위치정보가 정확하다면 일반적인 인덱스 스캔과 동일하지만, 적중률이 낮다면 오히려 기본키를 이용하여 액세스하는 것이 더 효율적

물리적 위치정보를 사용하지 않는 경우

• Secondery Index를 액세스하여 기본키정보를 얻는다
• 기본키로 데이터블록을 액세스

물리적 위치정보를 사용하는 경우

1. 추가적인 인덱스를 액세스하여 물리적 위치정보를 참조한다
2. 참조한 물리적 위치정보를 이용하여 데이터블록을 액세스한 후에 비교한다. 이때 기본키 값이 같으면 물리적 위치정보가 유효한 것으로 간주하여 액세스를 종료한다.
3. 만약 유효하지 않다면 다시 기본키로 액세스하여 데이터 블록을 가져온다

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

일체형 테이블의 부담요소

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

부담을 줄일 수 있는 방법

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

일체형의 체인

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

1.2.5 일체형 테이블의 생성

ORGANIZATION INDEX

• 일체형 테이블 생성을 정의하는 키워드

TABLESPACE

• 인덱스영역이 저장될 테이블 스페이스를 지정 (STORAGE 파라미터 사용도 가능)

PCTTHRESHOLD

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

INCLUDING

• INCLUDING이후에 선언된 컬럼들은 오버플로우 영역에 저장
• INCLUDING이 지정되지 않고, 로우의 크기가 PCTTHRESHOLD 초과하면 기본키 컬럼을 제외한 모든 컬럼이 오버플로우 영역으로 이동
• INCLUDING절이 적용되는 시점은 처음 로우가 저장될 때 로우인서트 시 인클루드에 선언된 컬럼을 NULL로 넣고 이후 UPDATE시 선언된 컬럼에 값을 입력하면
• PCTTHRESHOLD를 초과하지 않는 한도 내에서 {color:#0000ff}인덱스영역에 저장된다.

OVERFLOW TABLESPACE

• 지정한 PCTTHRESHOLD값을 초과한 로우의 일부가 저장될 테이블스페이스 지정
• 이 절을 지정하지 않으면 임계값을 초과한 로우들은 입력이 거부됨.

로우의 체인이 발생하면 데이터 액세스 효율은 떨어짐

• 일반테이블 : 사용자가 체인을 결정할 수 없음
• 일체형 : 사용자가 체인을 결정 할 수 있음, 결과에 따라 액세스 성능이 달라짐.

• 액세스 패턴을 분석하여 미래에 대한 예측이 가능하면 일체형을 선택하고 그렇지 않다면 사용하지 않는 것이 좋음.