데이터베이스를 운영하다보면 이 같은 상황을 한번쯤은 겪었을 것이다. 많은 이들이 이에 대한 해결책으로 스토리지를 추가할 것이다. 그러나 이 경우에는 그럴 수 없기에 해당 테이블스페이스의 테이블 중 용량이 큰 테이블을 다시 생성하는 작업을 해야만 했다.

테이블을 압축하기 위해 COMPRESS 옵션을 사용했는데 그 효과가 상당히 만족스러웠다. 일반적으로 테이블에 COMPRESS를 사용하면 데이터의 압축 효과 덕분에 크기가 줄어든다. 그러나 OLTP 환경에서는 DML(특히 업데이트)가 많이 일어나는데, 이러한 테이블에 적용하면 역효과가 날 수 있다. 물론 DW 환경에서는 보편적으로 사용하고 있지만 OLTP 환경에서도 이러한 효과를 얻을 수 있다는 보장은 없다.

COMPRESS

최근 데이터 크기가 증가함에 따라 데이터를 저장하는 물리적인 공간인 스토리지에 대한 지출도 증가하고 있다. 이에 오라클에서는 테이블 COMPRESS 기법을 이용해 대용량 데이터의 압축을 지원하고 있다. 이러한 압축 기술은 자원 사용율을 효율화해 전체 자원의 요구량과 비용을 줄여준다.

지피지기백전백승

적을 알고 나를 알면 백번 싸워 백번 이길 수 있다는 고사성어가 있다. OLTP 환경에서 아무 테이블에나 COMPRESS를 적용하면 더 큰 화를 부를 수도 있다.

그러므로 COMPRESS를 적용 전에는 반드시 테이블의 속성을 먼저 파악해야 한다. DBA_TAB_MODIFICATIONS 딕셔너리뷰(Dictionary View)를 확인하면 해당 테이블의 DML 이력을 알 수 있다.

• [리스트 1] DML 이력 확인

• SELECT INSERTS, UPDATES, DELETES
    FROM DBA_TAB_MODIFICATIONS 
   WHERE TABLE_NAME = 'AAA';
  ------------ ----------- ------- -------- -------
  TABLE_OWNER  TABLE_NAME  INSERTS  UPDATES  DELETES
  TEST         AAA          302905       25   119403
  

[리스트 1] 을 통해 해당 테이블의 DML 이력을 보면, 테이블의 사용 목적을 쉽게 알 수 있다. 예컨대 로그 테이블, 히스토리 테이블 등의 이력과 관련된 테이블들은 INSERT나 DELETE가 빈번히 일어나지만 UPDATE의 경우 거의 일어나지 않는다.

반면 가격 테이블, 상품 정보 테이블 등의 운영 테이블은 DML 작업이 모두 빈번하게 일어난다. 재차 강조하지만 COMPRESS를 적용하고자 하는 테이블의 속성을 먼저 파악한 다음 DML 이력을 확인하는 것이 중요하다.

COMPRESS의 사용 범위

COMPRESS의 사용 범위는 다양한데, 적용 가능한 대표적인 환경으로 DW를 꼽을 수 있다. DW 환경의 특성상 대량 데이터에서 INSERT와 SELECT가 자주 일어나는데, COMPRESS를 잘 사용하면 동일한 블록에 더 많은 데이터를 저장할 수 있다.

게다가 블록 I/O의 감소 효과를 볼 수 있는 동시에 SELECT의 성능도 기대할 수 있다. 그렇다면 OLTP 환경은 어떠할까?

서두에서도 말했지만 OLTP에서도 테이블에 대한 분석만 잘 한다면 얼마든지 COMPRESS의 효과를 기대할 수 있다.

COMPRESS 옵션

COMPRESS 옵션은 일반 힙 테이블, 파티션, 테이블, 인덱스 등 다양하다. COMPRESS 옵션의 사용법은 [리스트 2]와 같다.

• [리스트 2] COMPRESS 옵션 적용

• CREATE TABLE [테이블명]
    (COL1 VARCHAR(30))
    COMPRESS;
  
  CREATE UNIQUE INDEX COMPRESS_UNIQUE_EMP ON EMP(ENAME, EMPNO) COMPRESS;
  
  ALTER TABLE [테이블명] MOVE COMPRESS;
  ALTER TABLE [테이블명] MOVE PARTITION TABLESPACE [테이블스페이스명] COMPRESS;
  ALTER INDEX [인덱스명] REBUILD PARTITION TABLESPACE [테이블스페이스명] COMPRESS;
  
  [해제]
  ALTER TABLE [테이블명] MOVE NOCOMPRESS;
  ALTER INDEX [인덱스명] REBUILD NOCOMPRESS;
  

• - COMPRESS(9i~) : 기본 압축 기능 제공(Default : No Compress)
• - COMPRESS FOR ALL OPERATIONS(11gR1), COMPRESS FOR OLTP(11gR2) : 모든 DML에서의 압축 가능

이처럼 OLTP 환경에서도 COMPRESS를 사용할 수 있도록 오라클 11g 이후 버전부터 옵션이 추가돼 있다

COMPRESS와 자원 활용의 상관관계

DBA가 스토리지 증설을 위해 서버 엔지니어에게 요청을 한다면 그 이유는 분명 테이블스페이스 공간이 부족하거나 OS상의 볼륨 공간이 부족하기 때문일 것이다.

필자가 COMPRESS를 사용해 테이블을 다시 생성한 앞의 사례에서 100GB 용량의 테이블을 3GB까지 줄일 수 있었다. 물론 데이터의 생명 주기를 토대로 데이터의 보존 기간이 지난 데이터를 제거하고, 테이블 재생성을 통해 테이블 크기가 줄어든 것도 영향이 있을 것이다.

이를 감안하더라도 COMPRESS의 영향을 무시할 수는 없다. 이 상황만 보더라도 90GB의 용량을 확보할 수 있었다. 이처럼 적합한 테이블을 찾아 COMPRESS를 하면 DBA에게 뿐 아니라 서버 엔지니어에게도 큰 도움이 될 것이다. 스토리지를 추가로 구매하지 않아도 되는 만큼 비용까지 절감할 수 있다.

COMPRESS의 단점

COMPRESS의 강점은 분명하지만 단점도 존재한다. COM PRESS의 단점은 다음과 같다.

• - UPDATE 성능 저하
• - 운영 중 COMPRESS,NOCOMPRESS 수행으로 인한 CPU 부하
• - 운영 중 COMPRESS,NOCOMPRESS 수행으로 인한 LOCK 발생
• - 블록 저장 구조가 변경되므로 해당 테이블의 인덱스를 다시 빌드해야 함

지금까지 오라클에서 제공하는 COMPRESS에 대해 살펴봤다. 물론 이 글을 읽는 독자 중에서도 DW 환경이나 OLTP 환경에서 운영 업무를 수행하는 분이 많을 것이다.

필자는 OLTP 환경에서 COMPRESS를 사용하는 것이 바람직하지 않다는 기존의 인식을 이제 버려야 한다고 생각한다. 어느 환경이든 본인이 해당 테이블에 대한 목적과 속성을 잘 파악하고 있다면 COM PRESS 기능만으로 운영 업무에 큰 도움이 될 것이다.

물론 데이터베이스뿐 아니라 OS 파일시스템의 공간을 효율적으로 관리하는 것뿐 아니라 서버 엔지니어에게도 도움을 되기 때문에 일석이조라고 할 수 있다.