========================
Index Rebuild
========================
수 시로 일어나는 delete, update에 위해 인덱스 공간이 낭비(delete, update시 인덱스에 존재하는 값들은 실제 delete, update를 수행안함) 될 수 있으며 기존 인덱스를 다른 Tablespace로 이동하거나 역전환 인덱스(reverse key index)로 변경, 테이블을 move하는 경우에 인덱스를 재구성(rebuild) 해야 합니다.
ROW가 delete되는 경우 해당 인덱스에서 인덱스 컬럼의 값을 제거하지 않고 단지 Link정보만 제거하므로 저장공간이 낭비되게 되구요, update 역시
실제 인덱스 컬럼을 update 하는 것이 아니라 delete, insert를 행하므로 저장공간이 낭비되겠죠...
B*Tree 인덱스의 경우 최초 생성되었을때는 좌우 대칭인 모양이 되지만 ROW가 지워지고 입력되는 과정에 의해 비대칭인 모양을 가지게 되므로 B*Tree
인덱스의 장점을 이용할 수 없게 됩니다. 그러므로 인덱스를 재구성 해야 하는데...
Index Rebuild 형식은 다음과 같습니다.
SQL>alter index idx_emp_ename
tablespace users_idx1
online
parallel 5;
tablespace users_idx1<-- 테이블스페이스 옵션을 이용하여 테이블스페이스를 변경 가능
online <-- 온라인 상태에서 인덱스 리빌드 진행(일반적인 경우 인덱스 재구성시 실제 TABLE에 DML 사용을 못하지만 online 옵션을 사용하는 경우 DML이 가능, 그러나! 성능 저하 우려됨)
parallel 5 <-- 동시에 5개의 프로세스가 인덱스를 재구성
인 덱스를 재구성 하는 동안 성능이 떨어지는데... 얼마마다 한번식 할지는 잘 판단해야 할것 같습니다. 인덱스 Rebuild로 인해 시스템이 지연되어서는 안되며 인덱스를 사용하는 데도 성능이 많이 떨어지는 경우에만 Rebuild를 하시면 좋을것 같습니다.!!
참고로 일반적인 인덱스 재구성의 시기를 찾는 방법이 있는데...
아래를 참고 하세요...
인 덱스에 대한 자세한 정보는 INDEX_STATS VIEW를 통해 알 수 있는데 인덱스 정보(INDEX_STATS)를 보면 blevel(Branch Level) 컬럼이 있는데 이는 Index Tree의 Depth입니다. 트리에서 Depth 잘아시죠^^ LEAF BLOCK은 인덱스 트리 구조에서 최하위 레벨의 블럭 수를 나타내죠... 가운데 있는 블럭은 LEAF BLOCK을 찾기 위한 BRANCH BLOCK이라 하구요... INDEX 강좌를 읽어보시면 설명이 나와 있습니다...
일반적으로 인덱스값을 빨리 Access하기 위해서는 blevel값이 작아야 하구요,,, 일반적으로 blevel값이 4이상이면 인덱스 rebu ild작업을 통해 Index Rebuild를 수행해야 한다고 볼 수 있습니다...
기 타 인덱스 정보를 자세히 얻을려면... 아래처럼 Analyze 명령을 사용 합니다. 예를들면 알마나 많은 ROW가 삭제되었는지 등등...(삭제된 ROW가 많다면 TREE가 비대칭일 확률이 높겠죠...) 생성된 정보는 INDEX_STATS VIEW를 통해 확인 합니다.
analyze index 인덱스이름 validate structure
SQL> SELECT LF_ROWS,
DEL_LF_ROWS,
DEL_LF_ROWS*100/decode(LF_ROWS, 0, 1, LF_ROWS) PCT_DELETED,
FROM INDEX_STATS
WHERE NAME= 인덱스이름
일반적으로 위에서 구한 PCT_DELETED 값이 20%를 넘는 경우 Rebuild 대상으로 판정하기도 합니다...
감사합니다~
Index Rebuild
========================
수 시로 일어나는 delete, update에 위해 인덱스 공간이 낭비(delete, update시 인덱스에 존재하는 값들은 실제 delete, update를 수행안함) 될 수 있으며 기존 인덱스를 다른 Tablespace로 이동하거나 역전환 인덱스(reverse key index)로 변경, 테이블을 move하는 경우에 인덱스를 재구성(rebuild) 해야 합니다.
ROW가 delete되는 경우 해당 인덱스에서 인덱스 컬럼의 값을 제거하지 않고 단지 Link정보만 제거하므로 저장공간이 낭비되게 되구요, update 역시
실제 인덱스 컬럼을 update 하는 것이 아니라 delete, insert를 행하므로 저장공간이 낭비되겠죠...
B*Tree 인덱스의 경우 최초 생성되었을때는 좌우 대칭인 모양이 되지만 ROW가 지워지고 입력되는 과정에 의해 비대칭인 모양을 가지게 되므로 B*Tree
인덱스의 장점을 이용할 수 없게 됩니다. 그러므로 인덱스를 재구성 해야 하는데...
Index Rebuild 형식은 다음과 같습니다.
SQL>alter index idx_emp_ename
tablespace users_idx1
online
parallel 5;
tablespace users_idx1<-- 테이블스페이스 옵션을 이용하여 테이블스페이스를 변경 가능
online <-- 온라인 상태에서 인덱스 리빌드 진행(일반적인 경우 인덱스 재구성시 실제 TABLE에 DML 사용을 못하지만 online 옵션을 사용하는 경우 DML이 가능, 그러나! 성능 저하 우려됨)
parallel 5 <-- 동시에 5개의 프로세스가 인덱스를 재구성
인 덱스를 재구성 하는 동안 성능이 떨어지는데... 얼마마다 한번식 할지는 잘 판단해야 할것 같습니다. 인덱스 Rebuild로 인해 시스템이 지연되어서는 안되며 인덱스를 사용하는 데도 성능이 많이 떨어지는 경우에만 Rebuild를 하시면 좋을것 같습니다.!!
참고로 일반적인 인덱스 재구성의 시기를 찾는 방법이 있는데...
아래를 참고 하세요...
인 덱스에 대한 자세한 정보는 INDEX_STATS VIEW를 통해 알 수 있는데 인덱스 정보(INDEX_STATS)를 보면 blevel(Branch Level) 컬럼이 있는데 이는 Index Tree의 Depth입니다. 트리에서 Depth 잘아시죠^^ LEAF BLOCK은 인덱스 트리 구조에서 최하위 레벨의 블럭 수를 나타내죠... 가운데 있는 블럭은 LEAF BLOCK을 찾기 위한 BRANCH BLOCK이라 하구요... INDEX 강좌를 읽어보시면 설명이 나와 있습니다...
일반적으로 인덱스값을 빨리 Access하기 위해서는 blevel값이 작아야 하구요,,, 일반적으로 blevel값이 4이상이면 인덱스 rebu ild작업을 통해 Index Rebuild를 수행해야 한다고 볼 수 있습니다...
기 타 인덱스 정보를 자세히 얻을려면... 아래처럼 Analyze 명령을 사용 합니다. 예를들면 알마나 많은 ROW가 삭제되었는지 등등...(삭제된 ROW가 많다면 TREE가 비대칭일 확률이 높겠죠...) 생성된 정보는 INDEX_STATS VIEW를 통해 확인 합니다.
analyze index 인덱스이름 validate structure
SQL> SELECT LF_ROWS,
DEL_LF_ROWS,
DEL_LF_ROWS*100/decode(LF_ROWS, 0, 1, LF_ROWS) PCT_DELETED,
FROM INDEX_STATS
WHERE NAME= 인덱스이름
일반적으로 위에서 구한 PCT_DELETED 값이 20%를 넘는 경우 Rebuild 대상으로 판정하기도 합니다...
감사합니다~
[출처] [#INDEX]인덱스 재구성(Index Rebuild) |작성자 오라클러
'OraclE' 카테고리의 다른 글
linux에서 자동 exp스크립 (0) | 2009.01.16 |
---|---|
Win오라클 export 자동 백업,삭제 배치파일 만들기 (0) | 2009.01.16 |
log_archive_dest (0) | 2009.01.05 |
EM port 변경 (0) | 2008.12.30 |
control file 재생성 (0) | 2008.12.12 |