오라클의 개념_13

ㅇ ㅂㅇ


인덱스 관리

인덱스 분류

 인덱스는 테이블에 있는 행을 직접 액세스할 수 있는 트리 구조로서 논리적 설계 또는 물리적 구현에 근거하여 분류할 수 있습니다. 논리적 분류는 인덱스를 응용 프로그램 관점에서 나눈 것이고 물리적 분류는 인덱스 저장 방법에 따라 나눈 것입니다.
 단일열인덱스및연결된인덱스
 단일 열 인덱스는 해당 인덱스 키에 열이 하나만 있는데 예를 들면, 사원 테이블의 사원 번
호 열에 대한 인덱스가 여기에 해당됩니다.
연결된 인덱스는 조합 인덱스라고도 하며 테이블의 여러 열에 대해 생성되는데 이 열은 테
이블의 열과 순서가 동일하거나 인접할 필요가 없습니다. 예를 들어, 사원 테이블의 부서
열과 직위 열에 대한 인덱스가 여기에 해당됩니다.
조합 키 인덱스의 최대 열 수는 32개지만 모든 열을 합친 크기가 데이터 블록에 있는 사용
가능한 데이터 공간의 2분의 1에서 일부 오버헤드를 뺀 값을 넘지 않아야 합니다.
 고유및비고유인덱스
인덱스는 고유 또는 비고유 인덱스일 수 있습니다. 고유 인덱스는 테이블의 두 행 값이 키
열 또는 열에서 중복되지 않도록 합니다. 그러나 비고유 인덱스에서는 열 값에 이러한 제한
을 두지 않습니다.
 함수기반인덱스
함수 기반 인덱스는 인덱스화된 테이블의 열을 하나 이상 포함하는 함수 또는 표현식을 사
용할 때 생성되며 함수 또는 표현식의 값을 미리 계산한 다음 인덱스에 저장합니다. 함수
기반 인덱스는 B 트리 인덱스 또는 비트맵 인덱스로 생성할 수 있습니다.
 도메인인덱스
도메인 인덱스는 인덱스 유형에 따라 제공되는 루틴에 의해 생성, 관리, 액세스되는 응용
프로그램별(텍스트, 공간) 인덱스입니다. 이 인덱스는 응용 프로그램별 도메인에서 데이터
를 인덱스화하므로 도메인 인덱스라고 합니다.
단일 열 도메인 인덱스만 지원됩니다. 데이터 유형이 스칼라, 객체 또는 LOB인 열에 단일
열 도메인 인덱스를 생성할 수 있습니다.
 분할된인덱스및분할되지않은인덱스
분할된 인덱스는 큰 테이블에서 하나의 인덱스에 해당하는 인덱스 항목을 여러 세그먼트
에 저장하는 데 사용하며 이렇게 분할하면 하나의 인덱스를 여러 테이블스페이스에 분산
시켜 인덱스 조회 경합을 줄이고 관리를 용이하게 할 수 있습니다. 분할된 인덱스는 대개
확장성 및 관리 용이성을 향상시키기 위해 분할된 테이블과 함께 사용하는데 각 테이블 분
할 영역마다 하나씩 인덱스 분할 영역을 생성할 수 있습니다.

B 트리 인덱스
모든 인덱스가 B 트리 구조를 사용하고 있지만 B 트리 인덱스라는 용어는 대개 각 키에 대
한 ROWIDS 목록을 저장하는 인덱스와 연관됩니다.
 B 트리인덱스구조
 인덱스의 맨 위에는 루트가 있으며 루트는 인덱스의 다음 레벨을 가리키는 항목을 포함하
고 다음 레벨에는 분기 블록이 있으며 이 블록은 인덱스의 다음 레벨에 있는 블록을 차례로
가리키며 마지막으로 최하위 레벨에는 최하위 노드가 있고 이 노드는 테이블의 행을 가리
키는 인덱스 항목을 포함합니다. 키 값의 내림차순뿐만 아니라 오름차순으로도 인덱스를
쉽게 스캔할 수 있게 최하위 블록은 이중으로 연결합니다.
 인덱스최하위항목형식
인덱스 항목은 다음 구성 요소로 이루어집니다.
 • 항목 헤더는 열 수 및 잠금 정보를 저장합니다.
 • 키 열의 길이 및 값 쌍은 키 열의 크기 및 열의 값을 정의합니다. (이러한 쌍의 수는 인
덱스에 있는 최대 열 수와 동일합니다.)
 • 행의 ROWID는 키 값을 포함합니다.
 인덱스최하위항목특성
분할되지 않은 테이블의 B 트리 인덱스:
 • 인덱스가 압축되지 않은 경우 여러 행이 동일한 키 값을 갖고 있을 때는 키 값이 반복됩니다.
 • 모든 키 열의 값이 NULL인 행에 해당하는 인덱스 항목은 없습니다. 따라서 NULL을 지정하는 WHERE 절은 항상 전체 테이블 스캔을 수행합니다.
 • 모든 행이 동일한 세그먼트에 속해 있기 때문에 제한된 ROWID를 사용하여 테이블의 행을 가리킵니다.
인덱스에대한DML 작업효과:
테이블에서 DML 작업을 수행할 경우에는 Oracle 서버가 모든 인덱스를 유지 관리하며 다
음은 인덱스에 대한 DML 명령 효과에 관한 설명입니다.
 • 삽입 작업을 수행하면 하나의 인덱스 항목이 해당 블록에 삽입됩니다.
 • 행을 삭제하면 해당 인덱스 항목이 논리적으로만 삭제되며 삭제된 행에서 사용하던 공간은 해당 블록의 모든 항목을 삭제할 때까지 새 항목용으로 사용할 수 없습니다.
 • 키 열을 갱신하면 논리적으로 삭제되고 인덱스에 삽입되는데 PCTFREE 설정은 생성 시를 제외하고는 인덱스에 영향을 미치지 않으므로 PCTFREE에서 지정한 것보다 공간이 적더라도 새 항목을 인덱스 블록에 추가할 수 있습니다.

B 스타 트리 인덱스의 예제

리버스 키에 대해서

인덱스의 증가에 대해서

> leaf 노드간 붉은 색 화살표는 노드간의 링크를 뜻함 링크는 where절에서 between 조건 시 시작 값이 있는 leaf 노드를 찾고 찾은 leaf 노드의 링크를 통해 끝 값을 마저 찾음 , Leaf 노드에 인덱스가 정렬되어 들어감, Branch, Root에는 노드에 관련된 정보가 들어가 있음

> pin point query : 컬럼 값을 하나씩 모두 조회 하여 찾는 것

 ex) where no is (1,2)

> range query : 범위로 값을 모두 조회 하여 찾는 것

 ex) where no between 1 and 2

비트맵 인덱스
 다음 상황에서는 비트맵 인덱스가 B 트리 인덱스보다 유리합니다.
 • 테이블에 수 백만 개의 행이 있고 키 열에 낮은 기수가 있을 때, 즉 해당 열의 구분 값이 극소수일 경우. 예를 들어, 여권 레코드를 포함하는 테이블의 성별 및 결혼 여부 열에서는 B 트리 인덱스보다 비트맵 인덱스를 선호할 수 있습니다.
 • 질의가 OR 연산자를 포함하는 여러 WHERE 조건을 조합하여 사용할 경우
 • 읽기 전용 또는 키 열에 대한 갱신 작업이 저조할 경우
비트맵인덱스구조
 비트맵 인덱스도 B 트리와 같이 구성하지만 최하위 노드는 ROWIDS 목록 대신 각 키 값에
대한 비트맵을 저장합니다. 비트맵 내의 각 비트는 가능한 ROWID와 대응하며 비트가 설정
되어 있으면 해당 ROWID가 있는 행이 키 값을 포함하고 있음을 의미합니다.
도표와 같이 비트맵 인덱스의 최하위 노드는 다음 내용을 포함합니다.
 • 항목 헤더, 열 수 및 잠금 정보를 포함합니다.
 • 각 키 열의 길이 및 값 쌍으로 이루어진 키 값(예제에서 키는 단 하나의 열로 구성되어 있고 첫째 항목의 키 값은 Blue입니다.)
 • 시작 ROWID, 예제에서는 파일 번호 3, 블록 번호 10, 행 번호 0 등을 포함하고 있습니다.
 • 끝 ROWID, 예제에서는 블록 번호 12 및 행 번호 8을 포함합니다.
 • 비트 문자열로 이루어진 비트맵 세그먼트(비트는 해당 행이 키 값을 포함하고 있을 때 설정하고 해당 행이 키 값을 포함하고 있지 않을 때는 설정을 해제하며 Oracle 서버는 고유 압축 기술을 사용하여 비트맵 세그먼트를 저장합니다.)
시작 ROWID는 비트맵의 비트맵 세그먼트가 가리키는 첫번째 행의 ROWID이며 비트맵의
첫번째 비트는 첫번째 ROWID에 해당하고 비트맵의 두번째 비트는 블록의 다음 행에 해당
하며 마지막 ROWID는 비트맵 세그먼트에 포함된 테이블의 마지막 행에 대한 포인터입니
다. 비트맵 인덱스는 제한된 ROWID를 사용합니다.
비트맵인덱스사용
B 트리는 주어진 키 값의 비트맵 세그먼트를 포함하는 최하위 노드를 찾는 데 사용하며 시
작 ROWID 및 비트맵 세그먼트를 사용하여 사용 키 값을 포함하는 행을 찾습니다.
테이블의 키 열을 변경하면 비트맵을 수정해야 하며 관련 비트맵 세그먼트는 잠급니
다. 전체 비트맵 세그먼트를 잠가야 하므로 첫번째 트랜잭션이 끝날 때까지는 해당 비트맵
에 포함된 행을 다른 트랜잭션에서 갱신할 수 없습니다.

> 비트맵에서 0,1로 이루어진 수들은 테이블의 행의 수와 동일함, 테이블에 행을 추가 할 시 모든 키의 비트맵이 하나씩 늘어 나므로 insert 하는 트랜잭션 하나만 제외하고 모든 사용자는 사용 불가(lock 상태 이므로)

B트리인덱스와 비트맵 인덱스 비교
 낮은 기수 열과 함께 사용할 때는 비트맵 인덱스가 B 트리 인덱스보다 크기가 작습니다.
비트맵 인덱스는 비트맵 세그먼트 수준의 잠금을 사용하기 때문에 비트맵 인덱스의 키 열을 갱신하면 더 많은 비용이 들지만 B 트리 인덱스에서는 테이블의 각 행에 해당하는 항목을 잠급니다.
비트맵 인덱스는 비트맵 부울 같은 연산을 수행하는 데 사용할 수 있으며 Oracle 서버는 두
비트맵 세그먼트를 사용하여 비트 방식 부울 연산을 수행하고 결과 비트맵을 얻을 수 있으며 부울 술어를 사용하는 질의에서 비트맵을 효과적으로 사용할 수 있습니다.
요약하면 동적 테이블을 인덱스하기 위한 OLTP
환경에서는 B 트리 인덱스가 더 적합하고
대형 정적 테이블에서 복합 질의를 사용하는 데이터 웨어하우스 환경에서는 비트맵 인덱스
가 더 적합합니다.

일반 B 트리 인덱스 생성
인덱스는 해당 테이블을 소유하는 사용자의 계정 또는 다른 계정에서 생성할 수 있으며 일
반적으로 테이블과 동일한 계정에서 생성합니다.
위의 명령문은 LAST_NAME 열을 사용하여 EMPLOYEES 테이블에 인덱스를 생성합니다.

구문옵션
UNIQUE: 고유 인덱스 지정에 사용합니다 기본값은 Nonunique입니다.)
Schema: 인덱스/테이블 소유자입니다.
Index: 인덱스 이름입니다.
Table: 테이블 이름입니다
Column: 열 이름입니다.
ASC/DESC: 인덱스가 오름차순으로 생성되는지 내림차순으로 생성되는지 여부를 나타냅니다.
TABLESPACE: 인덱스를 생성할 테이블스페이스를 식별합니다.
PCTFREE: 새로운 인덱스 항목을 수용하기 위해 생성 시 각 블록에 예약되는 공간의 양(전체 공간에서 블록 헤더를 뺀 백분율)입니다.
INITRANS: 각 블록에서 미리 할당하는 트랜잭션 항목의 수를 나타냅니다 . (기본값과 최소값은 2입니다.)
MAXTRANS: 각 블록에 할당될 수 있는 트랜잭션 항목의 수를 제한합니다. (기본값은 255입니다.)
STORAGE 절: 인덱스에 확장 영역 할당하는 방법을 결정하는 저장 영역 절을 식별합니다.
LOGGING: 인덱스의 생성 및 인덱스에 대한 이후 작업을 리두 로그 파일에 기록함을 나타냅니다. (기본값입니다.)
NOLOGGING: 생성 및 특정 유형의 데이터 로드를 리두 로그 파일에 기록하지 않음을 나타냅니다.
NOSORT: 데이터베이스에 행이 오름차순으로 저장되므로 인덱스 생성 시 Oracle 서버가 행을 정렬하지 않아도 됨을 나타냅니다.

> PCTFREE 용량을 현재는 지정하지 않는 이유는 segment space management 가 auto이기 때문
> STORAGE 용량을 현재 설정하지 않는 이유는 local management가 auto이기 때문

인덱스 생성 : 지침
인덱스 생성 시 다음 사항을 고려합니다.
 • 인덱스를 사용하면 질의 성능 속도는 빨라지지만 DML 작업 속도는 느려지며 휘발성 테이블에 필요한 인덱스 수는 항상 최소화합니다.
 • 실행 취소 세그먼트, 임시 세그먼트 및 테이블을 포함하는 테이블스페이스가 아닌 별도의 테이블스페이스에 인덱스를 둡니다.
 • 큰 인덱스의 경우 리두 생성을 방지하면 성능을 상당히 향상시킬 수 있으므로 큰 인덱스를 생성할 경우에는 NOLOGGING 절을 사용하는 것이 좋습니다.
 • 인덱스 항목은 자신이 인덱스하는 행보다 작기 때문에 인덱스 블록은 블록마다 많은 항목을 포함하며 일반적으로 해당 테이블보다 인덱스에 대한 INITRANS가 더 높아야 합니다.
인덱스및 PCTFREE:
 인덱스에 대한 PCTFREE 매개변수는 테이블의 PCTFREE 매개변수와 다릅니다. 즉, 이 매개변수는 동일한 인덱스 블록에 삽입할 인덱스 항목의 공간을 예약하기 위해 인덱스 생성시에만 사용합니다. 인덱스 항목은 갱신되지 않으며 키 열이 갱신될 때 인덱스 항목의 논리적 삭제 및 삽입이 발생합니다.

 시스템이 생성한 송장 번호와 같이 차례대로 증가하는 열의 인덱스에는 낮은 PCTFREE를 사용합니다. 이러한 경우에는 항상 새로운 인덱스를 기존 인덱스 뒤에 추가하므로 새 항목을 기존의 두 인덱스 항목 사이에 삽입할 필요가 없습니다.
삽입하는 행의 인덱스화된 열 값이 임의의 값, 즉 현재 값의 범위에 포함되는 값일 수 있는 경우에는 높은 PCTFREE를 제공해야 합니다. 높은 PCTFREE를 필요로 하는 인덱스의 예로 송장 테이블의 고객 코드 열에 대한 인덱스를 들 수 있는데 이러한 경우에는 다음 공식에서구한 값으로 PCTFREE의 값을 지정하는 것이 좋습니다.

 Maximum number of rows – Initial number of rows x 100
------------------------------------------------------------------
                  Maximum number of rows

최대값은 1년과 같은 특정 기간을 참조할 수 있습니다.

> 보통 전체 데이터의 10% 만을 사용(but 화면에 200~300개 출력해 쓰는 것을 권장)
> 몇 만개 단위시 index를 쓰지 않음.
> index size < table size

비트맵 인덱스 생성
 구문
다음 명령을 사용하여 비트맵 인덱스를 생성합니다.
 CREATE BITMAP INDEX [schema.] index
 ON [schema.] table
 (column [ ASC | DESC ] [ , column [ASC | DESC ] ] ...)
 [ TABLESPACE tablespace ]
 [ PCTFREE integer ]
 [ INITRANS integer ]
 [ MAXTRANS integer ]
 [ storage-clause ]
 [ LOGGING| NOLOGGING ]
 [ NOSORT ]
 비트맵 인덱스는 고유할 수 없습니다.

CREATE_BITMAP_AREA_SIZE매개변수
초기화 매개변수인 CREATE_BITMAP_AREA_SIZE는 비트맵 세그먼트를 메모리에 저장하
는 데 사용하는 공간의 양을 결정하며 기본값은 8MB입니다. 값이 클수록 인덱스를 빨리 생
성할 수 있고 기수가 아주 작은 경우에는 이 값을 작은 값으로 설정할 수 있습니다. 예를 들
어, 기수가 겨우 2이면 값을 MB가 아닌 KB 순서로 나열하며 일반적으로 기수가 높은 경우
에는 메모리가 충분해야 최적의 성능을 낼 수 있습니다.

인덱스 저장 영역 매개변수 변경
일부 저장 영역 매개변수 및 블록 활용 매개변수는 ALTER INDEX 명령을 사용하여 수정합니다.

구문
  ALTER INDEX [schema.]index
   [ storage-clause ]
   [ INITRANS integer ]
   [ MAXTRANS integer ]

 인덱스 저장 영역 매개변수를 변경한 결과는 테이블 저장 영역 매개변수를 변경한 결과와동일하며 이러한 변경은 주로 인덱스의 MAXEXTENTS를 늘리는 데 사용합니다.
인덱스 블록의 동시성 레벨을 높이기 위해 블록 활용 매개변수를 변경하는 경우도 있습니다.

> 위 구문은 Local management 가 auto 이기 때문에 storage를 설정 해주지 않음

인덱스 공간 할당 및 할당 해제
인덱스에수동으로공간할당:
 테이블에 대한 대량의 삽입 작업 기간 전에 인덱스에 확장 영역을 추가해야 할 수 있으며
확장 영역을 추가하면 인덱스가 동적으로 확장되어 성능 저하를 방지할 수 있습니다.
인덱스에서수동으로공간할당해제
 ALTER INDEX 명령의 DEALLOCATE 절을 사용하여 인덱스에서 고수위 이상의 사용되지 않은 공간을 해제합니다.

구문
다음 명령을 사용하여 인덱스 공간을 할당하거나 할당을 해제합니다.
 ALTER INDEX [schema.]index
 {ALLOCATE EXTENT ([SIZE integer [K|M]]
  [ DATAFILE ‘filename’ ])
  | DEALLOCATE UNUSED [KEEP integer [ K|M ] ] }
수동의 인덱스 공간 할당 작업 및 수동의 할당 해제 작업은 테이블에서 이 명령을 사용할
경우와 동일한 규칙을 따릅니다.

인덱스 재구축
인덱스 재구축에는 다음 특성이 있습니다.
 • 기존 인덱스를 데이터 소스로 사용하여 새 인덱스를 구축합니다.
 • 기존 인덱스를 사용하여 인덱스를 구축할 경우에는 정렬이 필요하지 않으므로 성능이 향상됩니다.
 • 새 인덱스를 구축하고 나면 이전 인덱스는 삭제되며 재구축 중에는 이전 인덱스 및 새 인덱스를 각 테이블스페이스에 모두 수용할 수 있는 충분한 공간이 필요합니다.
 • 결과 인덱스는 삭제한 항목을 포함하지 않으므로 이 인덱스는 공간을 더 효율적으로 사용합니다.
 • 새 인덱스를 구축하는 동안에는 질의에서 기존 인덱스를 계속 사용할 수 있습니다.

재구축이 필요한 상황
다음 상황일 때 인덱스를 재구축합니다.
 • 기존 인덱스를 다른 테이블스페이스로 이동해야 할 경우로 인덱스가 테이블과 동일한 테이블스페이스에 있거나 객체를 디스크에 재분배해야 할 경우에는 이 작업이 필요할 수 있습니다.
 • 인덱스에 삭제한 항목이 많이 포함되어 있는 경우로 이러한 현상은 완료된 주문은 삭제하고 새로운 주문을 높은 번호로 테이블에 추가하는 주문 테이블의 주문 번호 인덱스와 같이 변하는 인덱스에서 나타나는 일반적인 문제입니다. 오래된 소수의 주문을아직 처리하지 않은 경우 항목 일부만 삭제한 인덱스 최하위 블록이 몇 개 있을 수도있습니다.
 • 기존의 일반 인덱스를 역방향 키 인덱스로 변환해야 할 경우로 이전 릴리스의 Oracle 서버에서 응용 프로그램을 이전할 경우 재구축할 수 있습니다.
 • 인덱스의 테이블을 ALTER TABLE ... MOVE TABLESPACE 명령을 사용하여 다른 테이블스페이스로 이동한 경우

구문
다음 명령을 사용하여 인덱스를 재구축합니다.
 ALTER INDEX [schema.] index REBUILD
  [ TABLESPACE tablespace ]
  [ PCTFREE integer ]
  [ INITRANS integer ]
  [ MAXTRANS integer ]
  [ storage-clause ]
  [ LOGGING| NOLOGGING ]
  [ REVERSE | NOREVERSE ]
 ALTER INDEX ... REBUILD 명령은 비트맵 인덱스를 B 트리 인덱스로 바꾸거나 또는 그 반대인 경우 사용할 수 없으며 REVERSE 키워드 또는 NOREVERSE 키워드는 B 트리 인덱스에만 지정할 수 있습니다.

> 테이블의 move와 동일함

온라인으로 인덱스 재구축
 인덱스 구축 또는 재구축 작업은 테이블이 아주 큰 경우 시간이 많이 걸리는 작업이며 Oracle8i 이전에는 인덱스를 생성 또는 재구축할 경우 테이블을 잠궈야 했고 동시 DML 작업을 할 수 없었습니다.
 Oracle9i는 인덱스를 생성 또는 재생성하면서 기본 테이블에 대한 동시 작업을 수행할 수
있지만 이러한 절차 중에는 큰 DML 작업을 수행하지 않는 것이 좋습니다.

> 계속해서 DML 문이 잠겨 있으면 온라인 인덱스 구축 중에 다른 DDL 작업을 수행할 수 없음을 의미합니다.

제한사항
 • 임시 테이블의 인덱스는 재구축할 수 없습니다.
 • 분할된 인덱스 전체는 재구축할 수 없으므로 분할 영역 또는 서브 분할 영역을 각각 재구축해야 합니다.
 • 사용되지 않은 공간은 할당을 해제할 수 없습니다.
 • 해당 인덱스에 대한 PCTFREE 매개변수의 값을 전체적으로 변경할 수 없습니다.

> 대게 온라인 상태로 재구축을 하지 않음.
> 기존 인덱스는 두고 새로운 인덱스는 만드는 것 (원래 방식은 기존 인덱스를 지우고 새로 만드는 방법)

인덱스 병합
 인덱스 단편화가 있는 경우 해당 인덱스를 재구축 또는 병합할 수 있으며 이러한 작업을 수행하기 전에 먼저 각 옵션의 비용 및 이익을 고려하여 자신의 상황에 가장 적합한 작업을 선택해야 합니다. 인덱스 병합은 온라인에서 수행되는 블록 재구축입니다.
 재사용을 위해 공간을 늘릴 수 있는 B 트리 인덱스 최하위 블록이 있는 상황에서는 다음 SQL 문을 사용하여 이 최하위 블록을 병합할 수 있습니다.
   SQL> ALTER INDEX hr.employees_idx COALESCE;
 위 그림은 hr.employees_idx 인덱스에 대한 ALTER INDEX ∼ COALESCE의 영향을 보여 주고 있습니다. COALESCE 작업을 수행하기 전 첫번째 두 개의 최하위 블록은 50%가 채워진 상태입니다. 이것은 인덱스가 단편화되었으므로 병합되어 첫번째 블록을 모두 채 울 수 있고 단편화를 줄일 수 있다는 의미입니다.

인덱스 및 유효성 검사
인덱스를 분석하여 다음을 수행합니다.
 • 모든 인덱스 블록에 대해 손상된 블록이 있는지 확인합니다. 이 명령을 수행해도 인덱스 항목이 테이블의 데이터에 대응되는지 여부는 확인되지 않습니다.
 • INDEX_STATS 뷰를 인덱스 정보로 채웁니다.
구문
   ANALYZE INDEX [ schema.]index VALIDATE STRUCTURE
 이 명령을 실행한 후 다음 예제에 나타난 대로 INDEX_STATS를 질의하여 인덱스 정보를 얻습니다.

SQL> SELECT blocks, pct_used, distinct_keys
  2    lf_rows, del_lf_rows
  3    FROM index_stats;

BLOCKS    PCT_USED    LF_ROWS   DEL_LF_ROWS
----------   -----------   -----------   -----------------
25             11             14            0
1 row selected.
인덱스에 삭제된 행의 비율이 높은 경우 해당 인덱스를 재구성합니다. 예를 들어,
DEL_LF_ROWS와 LF_ROWS의 비율이 30%를 초과하는 경우가 이에 해당합니다.

> 특정 Table의 딕셔너리 정보를 갱신 시켜줌
> DDL 명령어 (create, alter, drop, ..) -> 딕셔너리에 바로바로 정보를 갱신
> DML 명령어 (insert, delete, ....) -> 딕셔너리에 정보를 갱신 하지 않음

인덱스 삭제
 다음 시나리오에서는 인덱스를 삭제해야 할 필요가 있습니다.
 • 응용 프로그램에서 더 이상 사용하지 않는 인덱스는 삭제할 수 있습니다.
 • 대량 로드를 수행하기 전에 인덱스를 삭제할 수 있으며 데이터를 대량으로 로드 하기 전에 인덱스를 삭제하고 로드한 다음 다시 생성하면 다음 결과를 얻을 수 있습니다.
  – 로드 성능이 향상됩니다.
  – 인덱스 공간을 더 효율적으로 사용할 수 있습니다.
 • 주기적으로만 사용하는 인덱스가 특히 휘발성 테이블에 기반을 두고 있을 경우에는 불필요하게 유지 관리하지 않아도 되며 대개 연말 또는 분기 말의 검토 회의에 사용할 정보를 모으기 위해 임시 질의를 생성하는 OLTP 시스템의 경우에는불필요하게 유지 관리하지 않아도 됩니다.
 • 로드 작업 같은 특정 유형의 작업 중에 인스턴스 실패가 발생하는 경우에는 인덱스를 INVALID로 표시하는데 이러한 경우에는 인덱스를 삭제하고 다시 생성해야 합니다.
 • 인덱스가 훼손된 경우
 제약 조건에 필요한 인덱스는 삭제할 수 없으므로 종속된 제약 조건을 비활성화하거나 삭
제해야 합니다.

사용되지 않은 인덱스 식별
 Oracle9i부터는 인덱스 사용에 대한 통계를 수집하여 V$OBJECT_USAGE에 표시할 수 있습니다. 수집된 정보를 통해 인덱스가 사용되지 않았다는 것이 확인되면 해당 인덱스를 삭제할 수 있습니다. 또한 사용되지 않은 인덱스를 제거하면 Oracle 서버가 DML에 대해 수행해야 하는 오버헤드를 방지할 수 있으므로 성능이 향상됩니다. MONITORING USAGE 절이 지정될 때마다 V$OBJECT_USAGE가 지정된 인덱스에 대해 재설정됩니다. 이전 정보는 지워지거나 재설정되고 새로운 시작 시간이 기록됩니다.
V$OBJECT_USAGE 열
INDEX_NAME: 인덱스 이름입니다.
TABLE_NAME: 해당 테이블입니다.
MONITORING: 모니터를 ON으로 설정할지 OFF로 설정할지 여부를 나타냅니다.
USED: 모니터하는 동안 인덱스가 사용되었는지 여부를 YES 또는 NO로 나타냅니다.
START_MONITORING: 인덱스에 대한 모니터의 시작 시간을 나타냅니다.
END_MONITORING: 인덱스에 대한 모니터의 중지 시간을 나타냅니다.