*인덱스 생성
CREATE UNIQUE INDEX EXP_XOSL2_D_P.INDX_P_LINK_EVENT_PK
ON EXP_XOSL2_D_P.P_LINK_EVENT(O__NUM, O__ST)
TABLESPACE INDX_XOSL2_D_P ;
CREATE INDEX EXP_XOSL2_D_P.INDX_P_LINK_EVENT_L_EVT
ON EXP_XOSL2_D_P.P_LINK_EVENT(L_EVT)
TABLESPACE INDX_XOSL2_D_P ;
CREATE INDEX EXP_XOSL2_D_P.INDX_P_LINK_EVENT_L_LINK
ON EXP_XOSL2_D_P.P_LINK_EVENT(L_LINK_EVT)
TABLESPACE INDX_XOSL2_D_P ;
*Oracle Table에 Assign되어 있는 Index 조회
SELECT Idx.uniqueness,
Col.*
FROM ALL_INDEXES Idx,
ALL_IND_COLUMNS Col
WHERE Idx.index_name = Col.index_name
AND Idx.table_name=upper('P_LINK_EVENT');
*인덱스 생성 지침
1. 인덱스를 사용하면 질의 속도는 빨라지지만 DML 속도는 느려지므로 이 둘의 균형을 이룰 수 있도록 꼭 필요한 인덱스만 생성하도록 한다.
2. 인덱스는 다른 종류의 세그먼트를 포함하는 테이블스페이스가 아닌 별도의 스페이스에 두도록 한다.
3. 단편화를 최소화하기 위해 DB_BLOCK_SIZE의 5배인 표준 익스텐트 크기를 사용한다.
4. 큰 인덱스 생성시에는 성능향상을 위해 NOLOGGING 절을 사용하는 것이 좋다.
5. 새로운 키 값이 현재 범위 안에 있을 것 같으면 높은 PCTFREE 값을 설정한다.
6. 인덱스 항목은 자신이 인덱스하는 행보다 작기 때문에, 인덱스 BLOCK은 BLOCK마다 많은 항목을 포함하며 일반적으로 해당 테이블보다 인덱스에 대한 INITRANS가 더 높아야 한다.
7. 인덱스 및 PCTFREE
- 인덱스에 대한 PCTFREE Parameter는 테이블의 PCTFREE Parameter와 다르게 작동된다. 즉, 이 Parameter는 동일한 인덱스 BLOCK에 삽입할 인덱스 항목의 공간을 에약하기 위해 인덱스 생성 시에만 사용한다. 인덱스 항목은 갱신되지 않으며, 키 컬럼이 갱신될 때 인덱스 항목의 논리적 삭제 및 삽입이 발생한다.
*인덱스 재구축(Rebuild)-삭제된 항목을 제거하여 공간 활용 향상
ALTER INDEX order_id_idx REBUILD TABLESPACE exp_xlso2_indx;
1)인덱스 재구축의 특성
- 기존 인덱스를 Data 소스로 사용하여 새 인덱스를 구축한다.
- 기존 인덱스를 사용하여 인덱스를 구축할 경우에는 정렬이 필요하지 않으므로 성능이 향상된다.
- 새 인덱스를 구축하고 나면 이전 인덱스는 삭제되며, 재구축 중에는 이전 인덱스 및 새 인덱스를 각 Tablespace에 모두 수용할 수 있는 충분한 공간이 필요하다.
- 결과 인덱스는 삭제한 항목을 포함하지 않으므로 이 인덱스는 공간을 더 효율적으로 사용한다.
- 새 인덱스를 구축하는 동안에는 Query에서 기존 인덱스를 계속 사용할 수 있다.
2)인덱스 재구축이 필요한 상황
- 기존 인덱스를 다른 Tablespace로 이동해야 할 경우로 인덱스가 테이블과 동일한 Tablespace에 있거나 Object를 디스크에 재분배해야 할 경우에는 이 작업이 필요할 수 있다.
- 인덱스에 삭제한 항목이 많이 포함되어 있는 경우로, 이러한 현상은 완료된 주문은 삭제하고 새로운 주문을 높은 번호로 테이블에 추가하는 주문 테이블의 주문 번호 인덱스와 같이 변하는 인덱스에서 나타나는 일반적인 문제이다. 오래된 소수의 주문을 아직 처리하지 않은 경우 항목 일부만 삭제한 인덱스 최하위 BLOCK이 몇 개 있을 수도 있다.
- 기존의 일반 인덱스를 역방향 키(REVERSE KEY) 인덱스로 변환해야 할 경우로, 이전 릴리스의 Oracle Server의 응용 프로그램을 이전할 경우 재구축할 수 있다.
- 인덱스의 테이블을 ALTER TABLE ... MOVE TABLESPACE 명령을 사용하여 다른 Tablespace로 이동한 경우
3)Online으로 인덱스 재구축
ALTER INDEX order_id_idx REBUILD ONLINE;
- 인덱스 구축 또는 재구축 작업은 테이블이 아주 큰 경우 시간이 많이 걸리는 작업이며, Oracle 8i 이전에는 인덱스를 생성 또는 재구축할 경우 테이블을 locking해야 했고, 동시에 DML 작업을 할 수 없었다.
- Oracel 9i는 인덱스를 생성 또는 재생성하면서 기본 테이블에 대한 동시 작업을 수행할 수 있지만, 이러한 절차 중에는 큰 DML 작업을 수행하지 않는 것이 좋다.
*인덱스 유효성 검사
ANALYZE INDEX order_id_idx VALIDATE STRUCTURE;
- 이 명령을 수행해도 인덱스 항목이 테이블의 Data에 대응되는지 여부는 확인되지 않는다.
- INDEX_STATS 뷰를 인덱스 정보로 채운다.
- 모든 인덱스 BLOCK에 대해 손상된 BLOCK이 있는지 확인한다.
- 인덱스에 삭제된 행의 비율이 높은 경우 해당 인덱스를 재구성한다.
SELECT blocks, pct_used, distinct_keys, lf_rows, del_lf_rows FROM index_stats;
*인덱스 삭제
DROP INDEX order_id_idx
1)인덱스를 삭제하는 경우
- 인덱스가 더 이상 필요하지 않을 때
- 인덱스가 부적합하게 되어 재생성하기 전에 삭제할 필요가 있을 때
- 다른 테이블스페이스로 이 인덱스를 이동하고자 할 때
- 테이블에 대한 폭 넓은 DML 문장처리를 수행하고 있을 때
- 인덱스가 훼손되었을 때
2)인덱스 삭제 시나리오
- 응용 프로그램에서 더 이상 사용하지 않는 인덱스는 삭제할 수 있다.
- 대량 로드를 수행하기 전에 인덱스를 삭제할 수 있으며 Data를 대량으로 로드하기 전에 인덱스를 삭제하고 로드한 다음 다시 생성하면 다음 결과를 얻을 수 있다.
하나, 로드 성능이 향상된다.
두울, 인덱스 공간을 더 효율적으로 사용할 수 있다.
- 주기적으로만 사용하는 인덱스가 특히 휘발성 테이블에 기반을 두고 있을 경우에는 불필요하게 유지 관리하지 않아도 되며, 대개 연말 또는 분기 말의 검토 회의에 사용할 정보를 모으기 위해 임의의 Query를 생성하는 OLTP 시스템의 경우에는 불필요하게 유지 관리하지 않아도 된다.
- 로드 작업 같은 특정 유형의 작업 중에 Instance Failure가 발생하는 경우에는 인덱스를 INVALID로 표시하는데, 이러한 경우에는 인덱스를 삭제하고 다시 생성해야 한다.
- 인덱스가 훼손된 경우
