아래와 같이 dbms_space_admin 패키지를 활용하면 테이블스페이스를 재생성하지 않고도 DMT -> LMT 전환이 가능합니다.

문제는 아래와 같이 변환하면 단점이 있습니다.

아래 방법은 단순히 Data Dictionary의 UET$, FET$를 쓰는 대신에 데이타파일의 비트맵을 이용한 Extents 관리 방식의 장점을 취하는 것만 가능할 뿐이지...

LMT의 관리 방식의 장점까지 얻을 수는 없습니다.

(즉, 이미 들어있던 Extents까지 LMT에 맞도록 재구성이 되는게 아닙니다.)

BEGIN
   SYS.DBMS_SPACE_ADMIN.tablespace_migrate_to_local ('USERS');
END;

위와 같이 변환하면 순식간에 변환이 이루어지지만 LMT의 관리 방법의 장점(Extents를 자동으로 관리해주는...)는 취할 수 없습니다.

그러니까 여전히... create table시 Storage 절을 지정해준다거나 하는 일을 해주어야 합니다. initial, next, pctincrease, maxextents 파라미터도 여전히 설정해주어야 합니다.

변환하기 전후로 아래 쿼리를 실행해보면... extent_management 만 DICTIONARY에서 Local로 변환되었을 뿐... Allocation_type은 여전히 User로 되어있을겁니다.

진정한 LMT는 Uniform이나 System이어야 합니다.

select tablespace_name, extent_management, allocation_type from dba_tablespaces;

결론

가능은 하지만... 가급적... 새로 테이블스페이스를 생성해서 alter table ... move tablespace ... 명령어로 이동시키는 방법을 사용하는게 진정한 LMT의 강점을 100% 활용하는 방법입니다.

윗분 말씀대로 100%로 LMT 의 기능은 다 사용 못하며, DMT에서 LMT로의 변환 과정및 변환 후에 버그가 약간씩 있으니 주의하셔야 합니다.

8i 라면 정확한 버전이 어떻신지요? 버전에 따라서 지원여부를 잘 확인하셔야 합니다. 815 는 변환이 불가 한 것으로 알고 있습니다.

 그리고 system tablespace 영역의 변환은 불가 하며, temporary tablespace 의 변환도 불가 합니다. 단 temporary tablespace 의 경우 drop 후 locally managed 방식으로 다시 생성해 주면 됩니다.

 그리고 데이터 화일에 비트맵정보를 담기 위한 충분한 공간이 필요하니 이 부분들도 체크가 있어야 할거 같습니다.

 윗 분 말씀대로 신규로 생성하여 move 나 기타 export/import 를 이용해서 migration 하는 방식이 가장 깔끔한 방법이라고 생각하네요..

 하지만 LMT 의 효능에 대해서는 충분한 분석이 있어야 할것으로 생각합니다. 물론 저도 8i 에서 locally managed 방식을 사용한 경험이 있으며, 9i release 2 에서는 default tablespace  관리 방식이 모두 LMT 이므로 모두  LMT 를 사용해 봤는데... 제 판단으로는 관리 방식이 편해 졌으며, 성능도 향상은 있었씁니다. 하지만 제가 아는 DBA 분은 8i 에서 LMT 를 지양 하시는 분들도 있답니다.  좋은 기능과 밴더들의 해석들이 항상 상황에 맞는 것은 아니니까요....

 수고하세요..

답변 감사합니다.. alter 하고 move하는편이 좋은것 같습니다.

워낙 초보라..

locally의 장점이 extents 관리방식이라고 했는데

insert나 update가 많은 곳에 적합한가요?