Science of Database

매뉴얼 참조: Estimating the Space Use of a Table

위의 글을 해석해보면 성능 향상을 위한 목적임을 알 수 있다. 즉, 처음에 8MB 만큼 공간을 미리 할당하면, 추후에 INSERT가 들어올 때 공간을 다시 할당할 필요가 없으므로 속도가 좋아진다는 것. 그리고 자잘한 extent로 쪼개짐을 방지하여 쿼리의 성능을 높이자는 것이다. 이를 partition large extent 라고 한다. 이론적으로는 무모한 결정이 아님을 알 수 있다.

성능 때문에 용량 문제가 발생해도 좋은가?

하지만 이 개념 때문에 파티션 개수가 많은 테이블을 생성하지 못하는 문제가 생긴다. 즉 빈 공간이 90 기가 바이트라고 해도, 파티션 개수가 많은 테이블들은 몇 개도 생성하지 못한다는 결론이 나온다. 이런 기능을 성능이 빨라진다고 해서 오라클이 무조건 적용 할 수 있을까? 오라클은 무언가 믿는 구석이 있었기 때문에 자신 있게 적용할 수 있었다. 그것이 무엇일까? 11.2 매뉴얼을 읽어본 사람이라면 추측 할 수 있을 것이다.

빗나간 예측
Understand Deferred Segment Creation의 note 부분을 참조하면 오라클이 자신감 있게 파티션 마다 8MB를 할당할 수 있었던 이유가 나온다. Deferred Segment Creation(이하 DSC)이라는 기능 때문이다. DSC 기능 덕분에 테이블이 생성될 때는 물리적인 Disk 공간을 차지하지 않는다. 다시 말해, 테이블을 만들 때 공간을 할당하는 것이 아니라, 추후에 데이터가 insert 될 때 각 파티션에 대해 8MB씩 할당한다. DSC는 버전 11.2.0.2 부터 일반테이블 뿐만 아니라, 파티션 테이블에도 적용이 가능해졌다. 오라클은 파티션마다 8MB씩 할당해야 되지만 DSC 기능이 있으므로, 파티션을 생성할 때는 용량문제가 없을 것이라고 생각했을 것이다.

하지만, 항상 문제가 되는 것은 이론이 아니라 현실에서 발생한다. 현실에서는 여러 가지 버그 때문에 DSC를 사용할 수 없다. 따라서 해당 파라미터인 DEFERRED_SEGMENT_CREATION을 False로 놓을 수 밖에 없다. DSC를 사용할 수 없으므로 테이블을 만들 때 각 파티션마다 물리적인 디스크 공간을 8MB씩 차지하게 된다. 따라서, 파티션 개수가 많은 테이블을 만들 때 DSC 기능이 꺼져 있다면 용량부족 현상이 발생할 수 밖에 없다. 오라클로서도 어쩔 수 없는 일이다. 버그를 예상할 수는 없는 노릇 아닌가? DSC의 버그가 해결되면 이런 문제는 자연스럽게 사라질 것이다.

DSC에 관한 버그는 조동욱 님의 글 Deferred Segment Creation의 재미있는 두가지 버그를 참고하기 바란다.

해결방법

DSC는 현재 버그가 있으므로, 기능을 사용하지 못한다. 따라서 무조건 각 파티션에 8MB씩 할당이 되므로 엄청난 Disk 공간이 필요한 것이다. 파티션 테이블을 11.2.0.2 이상에서 생성할 계획이라면 수동으로 STORAGE (INITIAL 65536) 를 주면 된다. 이렇게 하면 처음에 8MB가 아니라 64KB만 공간을 차지한다. 이렇게 설정하면 이전 버전 11.2.0.1처럼 사용하는 것이다.

관련 파라미터

_partition_large_extents의 Default 값은 True이다. True로 되어있으면 각 파티션에 64kb가 아니라 8MB가 할당된다. 이 파라미터는 버전 11.2.0.1의 cell_partition_large_extents 파라미터를 대체한다. _index_partition_large_extents 도 위의 파라미터와 같은 역할을 한다. 다만 파티션이 아니라 파티션 인덱스라는 점만 다르다. 두 가지 파라미터 _partition_large_extents와 _index_partition_large_extents는 모두 11.2.0.2에서 소개되었다.

결론

11.2.0.2에서 버그 때문에 DSC 기능을 막아 놓았다면, 파티션 테이블을 생성할 때 STORAGE 절에 적절한 INITIAL 값을 주기 바란다. 그렇지 않으면 Disk 공간을 많이 차지하게 된다. 특히 각 파티션당 용량이 많지 않지만 관리목적상 파티션을 하는 경우는 INITIAL 값을 주는 것이 유리하다. 이렇게 하면 저장공간을 낭비하지 않고 테이블을 관리 할 수 있다. 또한 개발 DB는 운영 DB에 비해 Disk가 부족하므로 이런 사실을 잘 알아야 에러가 나더라도 당황하지 않는다. 개인적인 목적으로 PC나 노트북등에 오라클을 설치하는 경우도 Disk가 넉넉하지 않을 것이므로 마찬가지이다.

오라클 매뉴얼은 여러 번 보아야 한다. 예를 들어 11.2.0.1 매뉴얼을 이미 정독한 사람은 11.2.0.2 매뉴얼을 볼 필요가 없다고 생각 할 수 있다. 결코 그렇지 않다. 이 글에서 나타난 문제만 보아도 11.2.0.2 매뉴얼을 보았다면 전혀 문제가 되지 않을 것이다. 따라서 이전 매뉴얼을 정독 했더라도 11.2.0.2 버전의 새로운 기능은 익혀야 한다. 물론 매뉴얼 전체를 다시 볼 필요는 없다. 예를 들어 Admin가이드의 경우 매뉴얼의 첫 부분인 What's New in Oracle Database Administrator's Guide? 만 참조하면 무슨 기능이 추가된 것인지 쉽게 파악 할 수 있다. 어디에 무슨 내용이 있는지 안다면, 문제의 절반은 해결한 셈이다.

관련문서