인덱스 구조
- Branch Node , Leaf Node
- split 발생 및 overflow area 에 저장
장점
- 인덱스와 테이블 간의 랜덤 엑세스가 제거되어 효율적으로 넓은 범위를 처리
단점
- 인덱스에 모든 컬럼이 같이 저장되므로 인덱스 입장에서는 낮은 밀도로저장
- 인덱스만 스캔할 경우에는 불리
- split 이 발생하면 최초의 저장 위치를 유지할수 없음
- 엑세스 형태가 다양하게 나타나는 테이블에는 적용하기 어려움
Logical row ID 와 Physical guess
- Rowid 의 변경으로 인해 발생하는 문제점을 해결하기 위한 방안
- Secondary 인덱스는 논리적 Rowid 와 physical guess 를 보유
- 분리형에서 부담이던 rowid 로 랜덤 엑세스 하는 것보다 더 비효율적인 방식
일체형 테이블의 활용기준
- 전자 카달로그, 키워드 검색용 테이블, 코드성 테이블, 색인 테이블 , 공간 정보 관리용테이블 , OLAP 의 디멘젼 테이블 등에 적용
- 대부분 기본키로 엑세스 되는 테이블이면서 로우의 길이가 비교적 짧고, 트랜젝션이 빈번하지 않은 테이블에 적용
overflow 의 영역
- 인덱스와 함께 저장될 컬럼의 길이를 줄이고, split 발생 감소효과
- 상대적으로 빈번하게 엑세스 되지 않는 것들을 오버플로우 영역에 저장
- 오버플로우 영역에 대한 전략적인 접근이 필요
(자주 사용되는 컬럼을 오버플로우 영역에 저장을 하게 되면 우리가 피하고자 했던 랜덤 엑세스를 피하지 못하게 되는 결과를 낳지만 자주 사용되지 않는 것들만 오버플로우 영역에 저장하면 일체형이 가진 상당부분의 단점을 해소할수 있다는 것을 의미 )
- 현재 및 향후의 엑세스 패턴을 분석
(모든 정보는 컬럼들 간에 친밀도를 가지고 있으며 또한 중요도 차이가 있으므로 어느정도 미래에 대한 예측이 가능)
secondary key column | primary key | logical row id | physical guess
1. 물리적 위치정보를 사용하지 않은 경우
- 인덱스를 엑세스 하여 기본키 정보를 얻는다
- 기본키로 데이터 블록을 엑세스 한다.
2. 물리적 위치정보를 사용하는 경우
- 인덱스를 엑세스 하여 물리적 위치정보를 참조한다
- 물리적 위치정보로 데이터 목록을 엑세스 한 후 비교
- 기본키 값이 같으면 정상 종료
- 다르면 기본키로 엑세스 하여 데이터 블록을 가져온다.
- leaf 블록에는 4byte 데이터 베이스 블록 어드레스 정보 (DBA) 를 가지고 있다.
- secondary 인덱스가 만들어 지는 순간에는 정확한 값이 생성되지만 오버플로우 되어 split 되는 순간은 변경된다.
- row 이동이 빈번하게 일어난 정도에 따라 선택적으로 optimizer 에 의하여 선택할수 있다.
일체형 테이블의 적용 기준
- 중간에 값이 계속 적으로 삽입되지 않는 경우 사용
- 로우의 길이가 너무 길지 않을것
- 다양한 엑세스 형태를 가지지 않을것
- 주로 키 컬럼으로 랜덤 엑세를 하거나 범위 처리를 하는 경우
- 코드성 테이블 처럼 변화가 적고, 길이가 짧으며, 랜덤 엑세스 위주인 테이블
일체형 테이블 생성을 정의하는 키워드
- organization index
인덱스 영역이 저장될 테이블 스페이스를 지정 storage 파라미터도 사용가능
-tablespace data01
인덱스 블록 내에 예약된 공간의 백분율을 저장
- pct threshold
테이블 행을 인덱스와 오버플로우 영역으로 나눌 기준 컬럼을 지정
- including contents
- 적용시점은 로우가 최초로 입력될때이며 그이후는 pct threshold 에 의하여 인덱스 영역과 오버플로우 영역이 나누어짐
지정됨 임계값을 초과한 로우가 위치할 테이블스페이스를 지정
-overflow tablespace idx01;
일체형에서는 사용자가 체인을 결정할 수 있으며, 그결과에 따라 엑세스 성능에 차이
이 체인은 리프노드의 저장밀도를 높이기 위한 전략
인덱스 영역과 오버플로우 영역을 전약적으로 구분하여 엑세스 효율성 향상 (엑세스 형태 분석필요)
댓글 없음:
댓글 쓰기