Home 덤프파일 Import시 Tablespace의 여유공간이 미치는 영향
Post
Cancel

덤프파일 Import시 Tablespace의 여유공간이 미치는 영향

업무 특성상 오라클DB의 덤프파일을 import/export하는 일이 종종 있다.
다른 곳에서 덤프파일을 받아서 로컬에 설치된 오라클에다가 import하고, 해당 데이터를 처리하는 프로그램을 작성하여 처리한 후, 다시 덤프파일을 export해서 덤프파일을 가져온 곳으로 다시 돌려놓는게 일반적인 루틴이다.

이 때, 로컬에서 덤프파일을 import할 때 다음의 절차를 따른다.

테이블스페이스 생성 → USER생성 → 생성된 USER에 full import

여기에서 테이블스페이스를 만들 때 처음부터 공간을 만들어 두고 작업하는 것과 AUTOEXTEND 설정으로 공간을 자동생성 하는 것에 성능차이가 있을지 궁금하여 실험해 본다.

지금까지는 테이블스페이스 공간을 미리 만들어두고 시작했다. 덤프파일을 import했을때 예상 오라클 용량이 900GB라고 한다면, 30GB정도의 데이터파일 30개정도를 미리 만들어 두고 시작하는 형태였다.
왜냐하면, 테이블스페이스를 작게 만들어두고 AUTOEXTEND로 확장하게 할 경우에는 import를 하면서 계속 남은 여유공간을 체크하고 확장하는 데에 시간이 많이 걸릴 것으로 예상했기 때문이다. 물론 테이블스페이스를 크게 만든 후에 import가 끝난 후 실제 크기와 비슷하게 데이터파일의 용량을 줄여주면 되지만, 휴먼 에러를 최소화하고 가장 안정적인 작업 루틴을 만들기 위해 약간의 시간손해를 감수할만한 지 오차를 측정해 보는 것이 좋다고 생각했다.
그래서 위의 방법대로 충분한 공간을 개설해두고 import하는 것과, 작은 공간으로부터 import를 시작하는 경우의 시간차이를 비교해보고자 한다.

충분한 공간 확보후 IMPORT하는 경우

1

위와 같이 30GB정도의 데이터파일을 30개 만들어 둔 후에 import를 수행했다.

2 3

데이터 파일은 410GB, import후 테이블스페이스 용량은 900GB중 584GB정도 사용되었다.
디스크 공간을 확보하는 데에는 약 33분이 걸렸고, import시간은 1시간 23분이 소요되었다.

AUTOEXTEND(100MB)

4

기본용량을 100MB로 잡아두고 100MB씩 AUTOEXTEND하도록 설정했다.

5 6

테이블스페이스는 약 610GB정도 되었고, 1시간 34분이 소요되었다.

AUTOEXTEND(10MB)

7

기본용량을 10MB로 잡아두고 10MB씩 AUTOEXTEND하도록 설정했다.

8 9

테이블스페이스는 약 612GB정도 되었고, 1시간 34분이 소요되었다.

AUTOEXTEND(1byte)

10

기본용량을 10MB로 잡아두고 1byte씩 AUTOEXTEND하도록 설정했다.

11 12

테이블스페이스는 약 586GB정도 되었고, 1시간 35분이 소요되었다.

요약 및 결론

자동확장단위실제데이터 용량점유용량소요시간
자동확장 하지않음584GB900GB1시간 56분(33분 + 1시간 23분)
100MB584GB610GB1시간 34분
10MB584GB612GB1시간 34분
1byte585GB586GB1시간 35분

예상 외로 AUTOEXTEND일때 오히려 성능이 더 좋은 것을 확인할 수 있었다.
자동확장의 크기에 대해서는 별 차이가 없었고, 자동확장을 사용하냐 사용하지 않느냐의 여부가 중요한 성능에 큰 영향을 미치는 것 같다.
특별한 경우가 아니라면 자동확장을 이용하여 공간을 확보하도록 하는게 더 나을 것 같다.

왜 이런 결과가 나온것일지에 대해서 생각해보던 도중에 ChatGPT에게 물어보았는데, 자동확장을 하지 않을 경우에 자동확장을 할 때보다 단편화(fragmentation)부분에서 장점이 있다고 한다.
그래서 단편화와 관련된 조사를 해봤지만 자동확장으로 import했을때 단편화가 특히 더 심하다는 근거를 발견하지는 못했다.

이 부분에 대해서는 추후에 더 조사를 해봐야겠다.

해당 실험은 다음의 환경에서 수행되었다.

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
Samsung SSD 870 evo 2TB
PK, 색인, 트리거 등을 제외한 순수 데이터만 import

This post is licensed under CC BY 4.0 by the author.

Db User의 스키마를 쉽게 비교하는 방법

Ssd성능과 Db성능의 연관성