테이블 랜덤 액세스
인덱스 ROWID = 논리적 주소
-
물리적으로 직접 연결되지 않고 디스크 상에서 테이블 레코드를 찾아가기 위한 논리적 위치 정보를 담고있기 때문
-
오라클은 테이블 블록이 수시로 버퍼캐시에서 밀려났다가 다시 캐싱되며, 그 때마다 다른 공간에 캐싱되기 때문에 인덱스에서 포인터로 직접 연결할 수 없는 구조
메모리 주소 정보가 아닌 디스크 주소 정보를 이용해 해시 알고리즘으로 버퍼블록을 찾아간다
⇒ 일반 DBMS에서 인덱스 ROWID를 이용한 테이블 엑세스가 생각보다 빠르지 않다
I/O 메커니즘
- 블록을 읽을 때는 디스크로 가기 전에 버퍼캐시부터 찾아본다. 읽고자 하는 DBA를 해시함수에 입력서 해시체인을 찾고 거기서 버퍼 해더를 찾는다
- 캐시에 적재할 때와 읽을 때 같은 해시 함수를 사용하므로 버퍼 헤더는 항상 같은 해시 체인에 연결된다.
- 반면, 실제 데이터가
→ 해싱 알고리즘으로 버퍼 해더를 찾고, 거기서 얻은 포인터로 버퍼 블록을 찾아간다.
인덱스 클러스터링 팩터
-
군집성 계수, 특정 컬럼을 기준으로 같은 값을 갖는 데이터가 서로 모여있는 정도
-
CF가 좋은 컬럼에 생성한 인덱스는 검색 효율이 매우 좋다
→ 테이블 액세스량에 비해 블록 I/O가 적게 발생한다
-
버퍼 Pinning : 인덱스 ROWID로 테이블을 엑세스할 때 오라클은 래치 획득과 해시 체인 스캔 과정을 거쳐 어렵게 찾아간 테이블 블록에 대한 포인터(메모리 주소값)을 바로 해제하지 않고 일단 유지하는 것
인덱스 손익분기점
-
Index Range Scan에 의한 테이블 엑세스가 Table Full Scan보다 느려지는 지점
-
일반적으로 5~20%
-
CF가 나쁜 경우 → 5% 미만 심할때는 1% 미만
CF가 좋은 경우 → 90% 수준까지 상승 -
배치 프로그램에서는 파티션 활용 전략이 매우 중요한 튜닝 요소이고, 병렬처리까지 할 수 있으면 금상첨화
인덱스 컬럼 추가
- 테이블 엑세스 최소화를 위해 가장 일반적으로 사용하는 튜닝 기법
인덱스만 읽고 처리
- 반드시 성능을 개선해야 한다면, 쿼리에 사용된 컬럼을 모두 인덱스에 추가해서 테이블 액세스가 아예 발생하지 않게하는 방법을 고려할 수 있다
- 인덱스만 읽어서 처리하는 쿼리 : Covered 쿼리
- 해당 인덱스 : Covered 인덱스
include index
SQL Server 2005 버전에 추가된 기능
- 인덱스 키 외에 미리 지정한 컬럼을 리프레벨에 함께 저장하는 기능
- 정렬 생락 불가
create index emo_x01 on emp (deptno) include (sal);인덱스 구조 테이블
IOT (Index-Organized Table) ⇒ 랜덤액세스가 아예 발생하지 않도록 인덱스 구조로 생성한 테이블
( MS-SQL Server → 클러스터형 인덱스 )
인덱스 리프 블록이 곧 데이터 블록
create table index_org_t( a number, b varchar(10),
constraints index_org_t_pk primary key (a) ) organization index;-
IOT는 인위적으로 클러스터링 펙터를 좋게 만드는 방법 중 하나이다.
같은 값을 가진 레코드들이 100% 정렬된 상태로 모여 있으므로 랜덤 액세스가 아닌 시퀀셜 방식으로 데이터를 액세스 하므로 BTEWEEN이나 부등호 조건으로 넓은 범위를 읽을 때 유리하다.
클러스터 테이블
1. 인덱스 클러스터
-
클러스터 키 값이 같은 레코드를 한 블록에 모아서 저장하는 구조
-
한 블록에 모두 담을 수 없을 때는 새로운 블록을 할당해서 클러스터 체인으로 연결한다
-
다중 클러스터 : 여러 테이블 레코드를 같은 블록에 저장
⭐ 일반 테이블은 하나의 블록을 여러 테이블이 저장할 수 없다.
-
오라클 클러스터는 키 값이 같은 데이터를 같은 공간에 저장해 둘 뿐, IOT나 SQL Server의 클러스터형 인덱스처럼 정렬하지는 않는다.
-
클러스터 인덱스도 일반 B-Tree인덱스 구조를 사요하지만 테이블 레코드를 일일이 가리키지 않고 해당 키 값을 저장하는 첫 번재 데이터 블록을 가리킨다는 점이 다르다.
-
일반 테이블에서 생성한 인덱스 레코드는 테이블 레코드와 1:1 관계를 갖미나, 클러스트 인덱스는 테이블 레코드와 1:M관계를 갖는다 ⇒ 클러스터 인덱스의 키 값은 항상 Unique하다.
-
클러스터 인덱스를 스캔하면서 값을 찾을 때는 랜덤 액세스가 값 하나당 한 번씩 밖에 발생하지 않는다. 클러스터에 도달해서는 스퀀셜 방식으로 스캔하기 때문에 넓은 범위를 읽더라도 비효율이 없다.
-- 생성
create cluster c_dept# ( deptno number(2) ) **index**;
-- 클러스터에 테이블을 담기 전 번드시 정의
-- => 데이터 검색 용도 뿐만 아니라 데이터가 저장될 위치를 찾을때도 사용하기 때문**
create index c_dept#_idx on cluster c_dept#;2. 해시 클러스터 테이블
- 인덱스를 사용하지 않고 해시 알고리즘을 사용해 클러스터를 찾아간다
-- 생성
create cluster c_dept# ( deptno number(2) ) **hashkeys 4**;