아래 와 같은 기술로 그렇게 할수 있다고 하네요..

--=========================================

 

 

index 생성이나 rebuild 중에 발생하는 data의 변경에 대해서 temporary

journal table을 만들어서 그 변경 사항을 기록하게 된다.

journal은 IOT (Index Organized Table) table 형태로 만들어진다.

 

index 생성이나 rebuild가 끝나면 만들어진 index 내에 journal table의

record를 merge시킨다. merge시킬 때 journal table을 각각의 row 별로 scan을

하는데 20건에 한번 씩 commit을 수행한다. lock이 걸려 있는 row는 skip을

하게 되므로 완전한 merge를 위해서는 journal table을 여러번 내부적으로

scan하게 된다.

 

이러한 이유로 해당 table에 대해서, 트랜잭션이 매우 많이 발생하는 때에는

index 생성이나 rebuild를 하지 않도록 권하고 있다.

--=============================================

언제 인덱스 또는 테이블을 rebuild하는게 좋은가?

 

를 아래의 홍길동님이 질문에 그런대로 괜찮은 것이

 

나서 몇자 적습니다.

 

--==========================================

리빌딩 시기 : 대량의 dml을 한 후에 ...

 

라고 햇는데 (사실 이게 정답같지만...)

 

개발자가 dba에게 일일이 보고 하는것도 아니고

최종사용자가 일일이 보고하는것도 아니고...

 

그래서 update와 delete을 많이 실행되엇던

 

테이블을 찾아내면 그녀석이 몇번 수행되었나을

 

파악해서 리빌딩을 할지를 고려하면 될거 같습니다.

 

mark gurry의 튜닝경험을 빌리자면..

--===================================

select substr(sql_text,1,50),executions

from v$sqlarea

where UPPER(sql_text) like 'UPDATE%'

--or UPPER(sql_text) like 'DELETE%'

order by executions desc

--===================================

위 녀석을 돌려봅니다.

 

or를 풀고 돌리면 보기가 힘듭니다.

 

따로 따로 (update와 delete를 ) 돌려봅니다.

 

delete을 많이 테이블 top 10,

update를 많이 테이블 top 10을

 

을 알아냅니다.

 

그래서 그 테이블의 정의서를 봐서..(그 테이블안에

인덱스 정보도 있겟죠),... 문서 얘기임..

 

중구난방으로 개발하시는분은 그냥 시퀄로 일일이 뒤져 보겟지만...(저는 문서뒤져보는게 실어서 시퀄날립니다.히)

 

하여간 위 선택된 테이블과 테이블관련 정보를 가지고 인덱스 전략(리빌딩도 포함) 세웁시다.

 

--=============================

참고로...

 

테이블에 인서트를 하면 인덱스에 새 항목이 추가됩니다.

 

테이블에 업데이트를 하면 인덱스에는 논리적으로 delete처리하고 새 항목을 추가합니다.(물리적으로 남아있음)

 

테이블에 delete을 날리면 인덱스는 논리적으로 delete처리합니다.(물리적으로 공간은 차지합니다.)

 

그러보면 table에 update를 하면 인덱스에 공간을 많이 차지 하겟죠.. ...

 

이렇게 delete와 update는 인덱스 공간도 불필요하게 늘어나고 인덱스때문에 작업수행도 추가작업이 필요하겟죠..

 

그러니 테이블에 인덱스 줄줄이 달아 놓지는 마시길..

 

--===========물론 죽어도 필요하다면 달아야겟지만=

 

from: 1000cc