오라클 INDEX(인덱스) 작성시 주의사항

1. 인덱스 개요

 1) 스키마 객체이다.

 2) Oracle 서버가 포인터를 사용하여 행 검색 속도를 높이는 데 사용된다.

 3) 신속한 경로 액세스 방식을 사용하여 데이터를 빠르게 찾아 디스크 I/O를 줄일 수 있다.

 4) 인덱스하는 테이블과 무관하다.

 5) Oracle 서버에서 자동으로 사용되고 유지 관리된다.

 6) Oracle 서버 인덱스는 포인터를 사용하여 행 검색 속도를 높일 수 있는 스키마 객체이다. 명시적으로 또는 자동으로 인덱스를 생성할 수 있다.  

     열에 인덱스가 없으면 전체 테이블 스캔이 수행된다.

 7) 인덱스를 사용하면 테이블의 행에 직접 빠르게 액세스할 수 있다. 인덱스는 인덱스화된 경로를 사용하여 데이터를 신속하게 찾음으로써 필요한 디스크 I/O 

     를 줄이는 데 그 목적이 있다. 인덱스는 Oracle 서버에서 자동으로 사용되고 유지 관리된다. 인덱스가 생성된 후에는 유저가 직접 조작할 필요가 없다.

 8) 인덱스는 논리적, 물리적으로 인덱스의 대상인 테이블과 무관하다. 즉, 인덱스는 언제든지 생성하고 삭제할 수 있으며 기본 테이블이나 다른 인덱스에 영향 

     을 미치지 않는다.

 9) 테이블을 삭제하면 해당 인덱스 또한 삭제된다.

 

 

2. 인덱스의 UNIQUE SCAN의 예 

 

 

3. 인덱스의 RANGE SCAN의 예

 

 

4. INDEX의 주요 고려사항

 1) 대량의 Data가 날짜별, Sequence별 증가되는(INSERT) 형태의 INDEX는 B*Tree Index의 오른쪽 Index Split 빈번한 발생. 8개의 INDEX  

     가 모두 TRD_DT로 되어 있을 경우 8배의 Index Split빈도 예상. Application의 Resource부족에 의한 Lock 및 Deadlock 예상.

 2) INDEX는 Leading컬럼이 중요. 8개의 Index가 모두 TRD_DT로 나온다는 것은 INDEX로서의 기본적 구성이 잘못됨. 최소의 INDEX구성으로     

     가능한 모든 조건으로 들어 오는 Query조건을 만족시켜야 함.

 

 

 

 4) INDEX는 다양한 사용자의 검색조건에 대한 Access효율과 많은 프로세스의 동시 접근에 대한 경합까지도 고려되어야 한다.

 

 

 5) 날짜의 INDEX의 구성이 있지만 효율적인 INDEX구성 예

 6) 계좌식별ID가 Leading컬럼으로 나왔다. DISTINCT#가 높으므로 Access효율도 좋을 뿐 아니라 INDEX의 Split의 분상에 의한 경합분산의     

     효과도 동시에 얻을 수 있다.