음...

 

전자는 extent관리에 연관되는 것은 db내에

 

tablespace관리, 또는 공간관리와 연관되는겟죠...

 

8i이전 버전이라면 이것을 고려하시고..

 

8i이후 버전이라면 locally managed ts으로 ts을 생성해서 잊어버리는게 좋겟습니다.

 

----------------------------

LOCALLY MANAGED TABLESPACES

 

Locally managed tablespace는 자신이 보유, 관리하는 각 extent들에 대한

freed, used 여부를 bitmap형태로 각 구성 datafile들에 저장한다. Bitmap내의

각 bit들은 하나의 block 또는 block의 묶음에(extent) 대한 status를 표시한다.

만약 이들 extent들을 free하거나 할당받아서 사용하게 되면 각각의 extent에

해당하는 bitmap값들이 변경되게 된다. 이러한 변경사항들은 data dictionay

table들에 update작업을 수행하지 않는 관계로 rollback정보를 생성하지 않는다.

 

이렇게 local로 관리되는 경우 인접한 각 free extent들에 대한 정보가

자동적으로 추적가능하기 때문에 free extent를 coalesce할 필요성이 없어진다.

 

Locally managed tablespace는 동일한 size의 extent들을 가지도록 설정할 수도

있고, system이 알아서 그 extent의 size를 결정하도록 할 수도 있다.

Tablespace생성시의 UNIFORM 또는 AUTOALLOCATE option을 이용하여 이를

결정한다.

 

system tablespace는 locally managed tablespace로 생성할 수 없다.

 

===========================================

 

rebuild 문제는 음..

 

이거 전문적으로 해주는 모듈도 있죠 ..

 

quest의 live reorg인가..!

 

머 비싸니강 그냥 시퀄로 스크립트 처리해서

 

한적한 시간에 돌려주는 경우 도 있습니다..만...

 

....

 

먼저 인덱스 경우 .. 에 이놈은 검색속도의 증진이외에 타 목적으로 생성되는게 아니므로

 

검색속도를 증진하겟다고 테이블에 모든 칼럼에 인덱스를 다는 분도 잇는데 이렇게 달아놓으면

 

insert나 update, delete에는 인덱스로 인한 부하도 걸리겟지요.. 그러니 무턱대도 많은 달아놓는것도 지양..

 

각설하고 이렇게 많은 (여러번) 대량의 자료을 입력,

삭제, 수정 등..의 dml을 처리햇을 경우 인덱스는

 

리빌딩의 필요성이 대두되는데 그 시기는 단정짓기는

 

글세요.. 구체적인 추천되는 수치를 보지는 못햇습니다. 다만 대량의 dml을 하고 나서 여유가 된다면 리빌딩을 하라고 하는데 이거야 머.. 극히 주관적이니..

 

저 경우는 테이블의 레코드 갯수가 100만개 이상이 되는 테이블을 추려서 한테이블에 인덱스가 3개이상 걸려있는 녀석들은 한달에 한번씩 리빌딩해줍니다.

(지극히 개인적인 취향일뿐..~.`)

 

리빌딩할때 옵션을 잘 선택해서 속도를 빠르게 하소소.. 날 샙니다........

 

=======================================

 

1000cc

 

cf) 병합(무지 어려운 고급영어단어같아요)은 글세요.. 8.0.5 쓸때 사용해봣는데 효과를 눈에 띄게

 

나오지 않아서 별로 사용안한거 같습니다.