3.1 테이블 액세스 최소화

테이블 랜덤 액세스

인덱스 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**;