인덱스튜닝 - 테이블 액세스 최소화

- 인덱스 ROWID는 데이터 파일상 테이블 레코드를 찾아가기 위한 논리적 주소

- 인덱스를 아무리 재생성해도 클러스터링 팩터는 좋아지지 않는다. 인덱스 컬럼 순으로 재생성 해야한다.

- 클러스터링 팩터가 좋으면 같은양의 데이터 추출에도 나쁠때보다 소요시간이 줄어든다 > 버퍼 피닝으로 인해 블록 방문횟수가 감소

- 일정량 이상의 데이터를 읽을때 인덱스 효율이 낮은 이유는 테이블액세스가 랜덤액세스에다가 single block I/O라서

- 어플리케이션 영향도 고려한 튜닝을하라고하면

  인덱스 마지막에 컬럼추가, 신규인덱스 자제(DML성능 부하)
  

인덱스 스캔하고서 얻은 건수 266476(인덱스 스캔 단계 왼쪽에 나타난수치)
그건수만큼 테이블을 랜덤액세스했는데, 그단계에서 265,957(=266,968-1,011)개 블록을 읽었다.
이는 전체 블록 I/O의 99.6% 총소요시간은 49
(블록I/O는 각 오퍼레이션 우착괄호안에있는CR항목)

문제는 테이블을 266476번 방문했지만 최종결과집합이 1909번
테이블을 방문하고서 자동로밍여부='N'조건을 체크하는과정에서 대부분 걸러진것.

2번답처럼 로밍렌탈_N2인덱스에 자동로밍여부 컬럼을 추가하면 테이블 액세스는 정확히 1909번만 발생하므로 총 블록 I/O는 인덱스스캔과정에서 읽는 블록포함 3000여개(1909+1011)

1번은 가장최적이지만 선두컬럼을 변경했으므로 로킹렌탈_N2 인덱스 사용하던 쿼리를 모두 수집해 성능영향도 검토 필요

3 은 인덱스 스캔효율은 좋아지지만 테이블랜덤엑세스줄이는데는 도움안됨.

4 신규인덱스도좋은방법이지만 DML성능이 나빠진다

CR : 읽은블록수(누적)
ROWS : 테이블방문횟수

테이블 랜덤엑세스문제를 해결하기위한방법

1. 인덱스 컬럼 추가를 최우선 고려
2. IOT(인덱스 구조 테이블)이 가장 효과적이나 테이블구조변경에 따른부담, IOT부작용 고려필요
3. 인덱스순 테이블 정렬 재생성 > 클러스터링 팩터향상으로 랜덤엑세스 줄임.

배치 I/O

• 블록마다 건건이 I/O CALL을발생시키는 비효율을 줄이기 위한기능
• 테이블 블록에대한 디스크 I/O CALL을 미뤘다가 읽을 블록이 일정량 쌓이면 한번에 처리
• 데이터 정렬순서가 매번다를수 있음 > ORDER BY지정으로 순서보장가능
• 디스크 I/O가 발생하지않으면 성능차이는 없음
• 배치 I/O가 동작하더라도 시행계획에 SORT ORDER BY가 없으면 부분처리 가능 > ORDER BY 명시하면 부분처리 불가