Index

INDEX 인덱스

'어떤 데이터의 주소는 어디다', 데이터의 주소값을 가지고 있는 것

ROWID Format

- Extended ROWID Format = 확장된 ROWID

ROWID 란 데이터의 주소

ROWID를 모아둔 것이 INDEX

ROWID의 총 길이는 80비트 = 10 BYTES

- Restricted ROWID Format

Restricted ROWID, 제한적 ROWID는 7버전 까지만 썼고, 이제는 쓰지 않기 때문에 생략

B-tree Index

- Root를 기준으로 왼쪽과 오른쪽 Balance가 맞을 때 성능이 가장 좋음

- 더 자세한 내용은 http://hayleyfish.tistory.com/48 를 참고.

- B-tree index 생성하기

CREATE INDEX 인덱스명

ON 테이블명(칼럼명)

PCTFREE *

STORAGE(INITIAL * NEXT * PCTINCREASE * MAXEXTENTS *)

TABLESPACE T/S명 ;

- PCTUSED 옵션은 index는 지워지지 않기 때문에 필요 없음

- STORAGE 행은 ASSM일 경우 알아서 자동적으로 설정되기 때문에 신경 쓸 필요는 없다.

※INDEX 생성시 주의할 점※

1. Place in Separate Tablespace

테이블과 인덱스가 같은 테이블스페이스에 있으면 안된다. 성능 저하!, 전용 인덱스 테이블스페이스를 사용할 것!

2. Consider NOLOGGING for large indexes

index 생성시 redolog에도 기록이 되는데 인덱스가 클 경우 시간이 너무 오래걸리기 때문에 생성시 nologging 옵션을 줘서 기록이 되지 않게 함

Bitmap Index

- B-tree index와 마찬가지로 root, branch, leaf 로 구성되어 있지만 leaf 가 bitmap으로 구성되어 있음.

- 0 과 1를 사용해서 해당 데이터가 있는 자리를 '1'로 표시하고 없으면 '0'으로 표시

- 새 데이터로 update 되거나 insert 될 경우 bitmap index는 다시 다 만들어야 함

  그래서 대부분 데이터가 잘 바뀌지 않는 테이블에 bitmap index를 생성 eg.OLAP(Online Analytical Processing, 통계형)

- Bitmap index 생성하기

CREATE BITMAP INDEX 인덱스명

ON 테이블명(칼럼명)

PCTFREE *

STORAGE(INITIAL * NEXT * PCTINCREASE * MAXEXTENTS *)

TABLESPACE T/S명 ;

B-tree와 Bitmap 비교

B-tree	Bitmap
Cardinality가 높은 칼럼에 적합 (값의개수가 많은 칼럼)  = 골고루 분포되어 있고, 선택할 수 있는 옵션이 많은 칼럼   = 분포도 넓고, 선택도가 높음  eg. 이름칼럼 같은거.	Cardinality가 적은 칼럼에 적합 (값의 개수가 적은 칼럼)  = 데이터가 한쪽으로 치우침, 선택 할수 있는 옵션이 적은 칼럼  = 분포도 낮고, 선택도 낮음  eg. 성별칼럼 같은거.
KEY 의 갱신 비용이 적음	KEY 의 갱신 비용이 높음  = update 나 insert시 index 다시 생성
OR 사용 쿼리에 비효율적임	OR 사용 쿼리에 효율적이다.
OLPT (Online Transaction Process)에 효과적 = 실시간 입력	OLAP (Online Analytical Processing) 에 효과적 = 통계

Index Space 관리하기

- index도 segment, 데이터들의 rowid 정보를 별도의 세그먼트에 넣어 저장하니까. 

- Allocation: 미리 인덱스 공간을 할당

ALTER INDEX 인덱스명

ALLOCATE EXTENT

(SIZE * DATAFILE '경로') ;

- Deallocation: 할당된 공간을 취소해줌

ALTER INDEX 인덱스명

DEALLOCATE UNUSED ;

Index REBUILD

ALTER INDEX 인덱스명 REBUILD

TABLESPACE T/S명 ;

- 인덱스는 입력만 되고 삭제는 되지 않음

- 인덱스는 한번 만들어 놓으면 영구적으로 잘 작동하는 것이 아니라 생성 후에도 꾸준하게 관리해줘야 한다

- 대량의 DML 작업을 수행후에는 인덱스 밸런싱 상태를 조사해 REBUILD 작업을 통해 수정해주기. 

(밸런싱 상태 조회와 REBUILD 실습은 http://hayleyfish.tistory.com/48 를 참고)

- 테이블을 다른 테이블스페이스로 옮긴 후에는 기존 인덱스로 쓸수가 없기 때문에 INDEX REBUILD를 해줘야함

- REBUILD 작업은 부하가 많이 발생하는 작업이기 때문에 사람들이 안쓰는 시간, 밤 때 작업 해야함

- REBUILD 동안에는 인덱스를 사용할 수 없음 하지만,

   ALTER INDEX 인덱스명 REBUILD ONLINE ; 

   이렇게 ONLINE 옵션을 붙이면 REBUILD 동안에도 인덱스 사용 가능하지만 작업하는 시간이 오래걸린다.

P319 - P320까지 실습 첨부

Index 상태조회

ANALYZE INDEX 인덱스명

VALIDATE STRUCTURE ;

- 인덱스 상태를 조회해서 문제가 있는지 없는지 확인 가능

- '0' 에 가까울수록 좋은 상태를 의미하고 30% 밸런싱이 망가진 상태면 REBUILD 작업을 해주는 것이 좋다

- 테이블에 update가 많이 일어났을 때만 작업해주기 (why? ANALYZE 명령어 자체가 부하가 많이 걸리기 때문에 함부로 사용 NO!)

DROP

DROP INDEX 인덱스명 ;

- 인덱스 안쓰는건 DROP 해주기

- 안쓰는지 쓰는지 어떻게 아느냐? 

Index 사용여부

ALTER INDEX 인덱스명 MONITORING USAGE ; --> 모니터링 시작

ALTER INDEX 인덱스명 NOMONITORING USAGE ; --> 모니터링 중단

- 사용유무 확인할 때는

SELECT index_name, used

FROM v$object_usage

WHERE index_name='대문자인덱스명' ;

- 하지만 너무 믿지는 말자.