TableSpace AutoExtend 안하는것이 좋다

퍼포먼스를 고려할때~

규모가 좀 크고, 지속적으로 데이터가 증가하는 상황이라면 AutoExtend 는 사용하지 않는 것이 좋겠다.

 

규모가 있다면 테이블 스페이스를 업무별로 여러개로 나누고, 각 스페이스별로 여러개의 datafile 로 구성하는데

이때 테이블스페이스의 데이터파일에 아래와 같이 MAXSIZE를 지정할수 있기도 하다.

1) SIZE  400M AUTOEXTEND ON NEXT 100M MAXSIZE 1000M; <== MAXSIZE 지정

2) SIZE  400M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED; <== UNLIMITED

 

이렇게 될 경우 왜 퍼포먼스에 좋지 않을까?

 

A. 바람직한 케이스

SALE_D01 스페이스가 있다면

SALE_D01_1 파일로 2기가 정도 쓰다가 다 써가면

SALE_D01_2 파일을 새로 2기가 만들어서 쓴다.

 

B. 바람직하지 않은 케이스

SALE_D01 스페이스가 있다면

SALE_D01_1 파일을 1기가로 만들어서 쓰고, AUTOEXTEND 200M 에 MAXSIZE 2000M 로 설정한다.

그리고 SALE_D01_1 이 차면, SALE_D01_2 를 새로 만든다.

 

DISK IO 관점에서 B가 A보다 분산되는 정도가 더 높을것이다. 여기 봤다 저기 봤다 ~~

쉽게 설명하면 ( 맞는 설명인지 모르겠으나 )

B 의 경우 200M 파일이 차지하는 블록이 여의도로 되었다가 또 200M 다음에 만들때는 일산이 되었다가 이런식으로 될 것이다.

즉, A 의 상황에선 여의도와 반포와 용산만 왔다갔다 하면 되는데,

B의 상황에선 여의도, 일산, 하남, 평촌, 정릉, 신촌, 구리 등등 여기저기 땀뻘뻘 흘리며 왔다갔다 해야 할 것이다.

( 전기세도 더 들겠군 ^^;; )

 

이와 같이AutoExtend 를 걸지 않을 경우 SMS 와 연계한 자동 모니터링이나 수동 모니터링 등으로

TABLESPACE 부족으로 인한 장애를 미연에 방지해야 할 것이다.

 

P.S.

단, 규모가 작은 시스템이고, 향후 데이터 발생량이 적을 경우에는 AutoExtend 를 사용해도 무리가 없을 것이다.

( 이때도 물론 MAX 값 설정 정도의 최소한의 장치는 해두는 것이 좋을것 같고, 수동 모니터링이라도 정기적으로 해줘야할 것이다 )

 

이 글은 스프링노트에서 작성되었습니다.