Oracle Exadata의 HCC 압축 이란

시간이 지나면서 데이터는 급속하게 증가하고 있다. 데이터가 증가함에 따라 DBMS 에서 관리 되어지는 정보도 급속하게 증가 하고 있다. 이로 인해 저장공간의 부족으로 하드웨어 비용의 증 가와 데이터 처리 성능에 많은 문제 점들이 나타나고 있다.

이러한 문제점들을 해결하고 자 ORACLE 에서는 EXADATA 라는 시스템을 통해 스토리지 공간 부족현상 과 데이터 처리 성능을 향상시키고자 하였다. EXADATA 시스템이란 대용량 데이터베이스에서 디스크 스토리지 시스템에서 데이터베이스 서버로 많은 데이터를 이동 시킬 때 발생하 는 많은 비효율을 하드웨어와 소프트웨어의 조합을 통해 해결 하고자 한 것이 EXADATA 시스템 이라 하는데 HCC (HYBRID COLUMNAR COMPRESSION) 라는 압축 기술을 통해 이와 같은 문제점들을 해결 할 수 있다.

본 장에서는 EXADATA 시스템의 HYBRID COLUMNAR COMPRESSION 압축을 중심으로 이야 기 할 것이다. 데이터 압축의 원리를 알아보고 디스크 공간 절약과 데이터 조회의 성능에 어떤 영향을 미치는지 비교해 보고자 한다.

HCC 란 무엇이며 어떻게 동작하는지 알아 보자.

데이터를 압축을 하게 되면 스토리지 공간을 절약 할 수 있다. 압축에도 여러 가지 방법으로 데이터들을 압축 할 수 있으며 EXADATA 시스템에서는 H CC 라는 압축 방식을 통해 보다 진보된 방식으로 압축을 할 수 있다. HCC 이전에 압축 방식은 BLOCK 안에 중복된 값들을 하나의 값으로 가지고 있고 그 값을 참조하는 주소 값을 통해서 중복 데이터를 접근하는 방식인 ROW 데이 터를 기반으로 하는 압축 방식 이였다.

ROW 기반 압축에서 진보된 형태의 압축이 HCC 압축이라고 할 수 있으며 HCC 압축 방식은 EXADATA 에서만 사용 할 수 있다. HCC(HYBRID COLUMNAR COMPRES SION) 이란 칼럼기반 압축 방식으로 같은 유형의 데이터와 비슷한 칼럼 속성을 인접하여 저장하면 보다 효과적인 압축을 하여 스토리지 공간을 효율적으로 줄일 수 있다. 칼럼과 ROW 의 조합으로 저장공간의 효율성과 좋은 성능을 기대할 수 있는 HYBRID 압축 방식이다.

HCC 압축 방식은 더 이상 ROW 단위로 데이터를 저장하지 않고 CU(COMPRESSION UNIT) 단 위로 저장 된다. 그림 1 과 같이 하나의 CU 을 보통 32K 나 64K 구성 되어 있다. CU 는 여러 개 의 BLOCK 을 가지고 있으며 CU 안에 데이터들은 칼럼으로 다시 재구성된다.

이렇게 구성된 CU 의 장점은 CU 을 한번만 읽으므로 ROW 전체를 읽을 수 있는 장점이 있지만 칼럼 전체를 읽으려면 모든 UN 을 읽어야만 하기 때문에 완벽한 칼럼 기반 압축 방식이라고는 할 수 없다. 완벽한 칼럼 방식으로 구성 되었다면 모든 CU 을 읽지 않고 모든 칼럼들을 읽었을 것이다.

하 지만 HCC 압축은 칼럼 형태의 압축의 장점인 디스크 절약과 ROW 형태의 압축의 장점인 조 회 성능을 모두 만족 시킬 수 있는 HYBRID 압축 이라고 하겠다.

HCC 압축에는 어떤 유형들이 있을까 ?

HCC 방식은 여러 가지 유형이 존재하며 아래 표를 통해서 각 유형들의 특징을 볼 수 있다. 아래 표를 참고하여 테스트를 통해 압축 유형들의 특징들을 구체적으로 알아 보도록 하자.

표 1 – 1 에서 살펴본 압축 유형들을 통해 각각의 특징들을 테스트를 통해 살펴 보도록 하자.

테스트 테이블 생성 스크립트

CREATE TABLE HCC_TEST AS SELECT * FROM DBA_OBJECTS;

INSERT INTO HCC_TEST AS SELECT * FROM HCC_TEST ; — 10번 반복

— 테스트 테이블의 SEGMENT SIZE

SELECT SUM(BYTES)/1024/1024 BYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST’;

BYTES

———

1600

— HCC 레벨1

CREATE TABLE HCC_TEST_HCC1 COMPRESS FOR QUERY LOW AS SELECT * FROM HCC_TEST ;

SQL Execution Time > 00:00:20.031

SQL> SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_HCC1′;

MBYTES

———

200

— HCC 레벨2

CREATE TABLE HCC_TEST_HCC2 COMPRESS FOR QUERY HIGH AS SELECT * FROM HCC_TEST ;

SQL Execution Time > 00:00:40.794

SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_HCC2′;

MBYTES

———

104

— HCC 레벨3

CREATE TABLE HCC_TEST_HCC3 COMPRESS FOR ARCHIVE LOW AS SELECT * FROM HCC_TEST ;

SQL Execution Time > 00:00:40.108

SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_HCC3′;

MBYTES

———

104

— HCC 레벨4

CREATE TABLE HCC_TEST_HCC4 COMPRESS FOR ARCHIVE HIGH AS SELECT * FROM HCC_TEST ;

SQL Execution Time > 00:04:01.146

SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_HCC4′;

MBYTES

———

72

압축 유형에 따른 테스트 결과

표 1 압축 유형 테스트 결과를 살펴보면 압축 단계가 높을 수록 압축률이 높아 진다. 압축 레 벨이 높을수록 스토리지 공간을 절약 할 수가 있다. QUERY HIGH 을 보면 QUERY LOW 비해 압축률이 7 배 정도 좋아졌지만 적재 시간도 2 배 정도 소 요 되었다. ARCHIVE LOW 보면 QUERY HIGH 와 거의 차이를 보이지 않고 있다. ARCHIVE HIGH 을 보면 압축률이 ARCHIVE LOW 비해 7 배 정도 좋아 졌지만 시간은 4 배 정도 더 느려졌다. 

결과적으로 레벨의 단계가 높을 수록 압축률은 좋아 졌지만 적재는 더 많은 시간을 요구 하고 있 다. 또한 압축 하는 동안 많은 시간이 소요 된다면 시스템 자원도 오랜 시간 동안 사용 해야 할 것이다.

HCC 압축과 QUERY 성능과의 관계

H CC 압축과 QUERY 의 성능을 알아보려고 한다. 여기서 2 가지 테스트를 해 보겠다. I/O 집약 적인 QUERY 성능 테스트와 CPU 작업 집약적인 QUERY 성능 테스트를 해 보겠다. 이렇게 테스트를 하는 이유는 쿼리에 상황에 따라서 성능에 차이를 보이기 때문이다.

Java.lang.OutOfMemoryError : Java heap spaceI/O 집약적인 QUERY

SQL> select sum(OBJECT_ID) from HCC_TEST;

SUM(OBJECT_ID)

————–

7.4e+011

SQL Execution Time > 00:02:51.123

SQL> select sum(OBJECT_ID) from HCC_TEST_HCC1;

SUM(OBJECT_ID)

————–

7.4e+011

SQL Execution Time > 00:01:31.967

SQL> select sum(OBJECT_ID) from HCC_TEST_HCC2;

SUM(OBJECT_ID)

————–

7.4e+011

SQL Execution Time > 00:01:13.045

SQL> select sum(OBJECT_ID) from HCC_TEST_HCC3;

SUM(OBJECT_ID)

————–

7.4e+011

SQL Execution Time > 00:01:14.014

SQL> select sum(OBJECT_ID) from HCC_TEST_HCC4;

SUM(OBJECT_ID)

————–

7.4e+011

SQL Execution Time > 00:01:58.043

CPU 집약적인 QUERY

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(‘UNIONE’, ‘HCC_TEST’,METHOD_OPT =>’ for all columns size 1′);

PL/SQL executed.

SQL Execution Time > 00:00:13.054

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(‘UNIONE’, ‘HCC_TEST_HCC1′, METHOD_OPT =>’ for all columns size 1′);

PL/SQL executed.

SQL Execution Time > 00:00:16.911

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(‘UNIONE’, ‘HCC_TEST_HCC2′, METHOD_OPT =>’ for all columns size 1′);

PL/SQL executed.

SQL Execution Time > 00:00:19.859

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(‘UNIONE’, ‘HCC_TEST_HCC3′, METHOD_OPT =>’ for all columns size 1′);

PL/SQL executed.

SQL Execution Time > 00:00:19.891

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS (‘UNIONE’, ‘HCC_TEST_HCC4′, METHOD_OPT =>’ for all columns size 1′);

PL/SQL executed.

SQL Execution Time > 00:00:33.322

HCC 압축과 QUERY 성능 테스트 결과

표 2 – 2 을 보면 I/O 집약적인 QUERY 와 CPU 집약적인 QUERY 에 대해 성능에 차이가 존재한 다. I/O 집약적인 작업일 경우에는 HCC 압축 전화 후를 비교해 보면 각 HCC 압축 레벨마다 조 금의 차이는 보이지만 압축 하기 전보다 모두 좋은 성능을 보였지만 CPU 집약적 작업은 압축 하 기 전 보다 모두 더 나쁜 성능을 보였다.

이렇게 QUERY 의 형태 (I/O 집약적인 QUERY 와 CPU 집약적인 QUERY) 에 따라서 실행 결과 가 달라진 이유는 I/O 집약적인 작업은 QUERY 조회 시 압축해제에 따른 CPU 사용보다 HCC 압 축으로 읽어야 할 BLOCK 수의 감소 효율이 더 좋았기 때문이고 CPU 집약적 작업이 압축 전 데 이터 보다 좋지 못한 성능을 보인 이유는 압축해제에 사용된 CPU 리소스 사용과 통계정보 생성 에서 사용한 CPU 사용 리소스가 HCC 압축으로 읽어 야 할 BLOCK 수의 감소 효율 보다 좋지 못 했기 때문이다. 따라서 압축된 데이터는 각 QUERY 상황에 따라서 성능이 달라질 것이다.

DML(INSERT, UPDATE) 사용시 HCC 압축 방법과 유의점

INSERT 시 HCC 압축하기

INSERT 통해 데이터 압축을 할 경우 DIRECT PATH LOAD 일 때만 HCC 형태로 압축이 이루어 진다.

아래 테스트를 통해 확인해 보도록 하자.

INSERT HCC 압축 하기

SQL> TRUNCATE TABLE HCC_TEST;

ALTER TABLE HCC_TEST NOCOMPRESS;

INSERT INTO HCC_TEST SELECT * FROM HCC_TEST_HCC1;

COMMIT;

SQL> SELECT ROUND(SUM(BYTES)/1024/1024) FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST’;

ROUND(SUM(BYTES)/1024/1024)

—————————

1600

SQL> TRUNCATE TABLE HCC_TEST;

Statement Processed.

SQL Execution Time > 00:00:01.982

ALTER TABLE HCC_TEST COMPRESS FOR ARCHIVE LOW ;

INSERT INTO HCC_TEST SELECT * FROM HCC_TEST_HCC1;

COMMIT;

SQL> SELECT ROUND(SUM(BYTES)/1024/1024) FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST’;

ROUND(SUM(BYTES)/1024/1024)

—————————

1536

SQL> TRUNCATE TABLE HCC_TEST;

Statement Processed.

SQL Execution Time > 00:00:01.982

ALTER TABLE HCC_TEST COMPRESS FOR ARCHIVE LOW ;

INSERT /*+APPEND*/ INTO HCC_TEST SELECT * FROM HCC_TEST_HCC1;

COMMIT;

SQL> SELECT ROUND(SUM(BYTES)/1024/1024) FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST’;

ROUND(SUM(BYTES)/1024/1024)

—————————

104

CREATE TABLE HCC_TEST_HCC3 COMPRESS FOR ARCHIVE LOW AS SELECT * FROM HCC_TEST ;

SQL Execution Time > 00:00:40.108

SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_HCC3′;

MBYTES

———

104

테이블을 생성 후 ALTER 명령어를 통해 테이블 형태를 ARCHIVE LOW 형태의 압축 형태로 테 이블로 변경 하였다. 테이 블은 압축 형태로 변경 되었지만 DIRECT PATH LOAD 발생하지 않은 상태에서 데이터 적재와 원본 테이블의 SEGMENT 차이는 거의 없었다. 하지만 DIRECT PATH LOAD 발생한 데이터 적재는 HCC 형태의 ARCHIVE LOW 형태의 압축이 이루어 졌다.

UPDATE 시 HCC 압축하기

HCC 가 이루어진 데이터에 대해서 UPDATE 가 발생하게 되면 압축은 해제 된다.
아래 테스트를 통해서 알아 보도록 하자.

DROP TABLE HCC_TEST_UPDATE PURGE;

CREATE TABLE HCC_TEST_UPDATE NOLOGGING AS SELECT * FROM HCC_TEST_HCC1 WHERE ROWNUM < 200000;

SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_UPDATE’;

MBYTES

———

24

EXEC DBMS_STATS.GATHER_TABLE_STATS (‘UNIONE’, ‘HCC_TEST_UPDATE’, METHOD_OPT =>’ for all columns size 1′)

SELECT TABLE_NAME, BLOCKS,CHAIN_CNT FROM DBA_TABLES WHERE TABLE_NAME = ‘HCC_TEST_UPDATE’;

TABLE_NAME BLOCKS CHAIN_CNT

—————————— ——— ———

HCC_TEST_UPDATE 2963 0

ALTER TABLE HCC_TEST_UPDATE MOVE COMPRESS FOR ARCHIVE LOW ;

SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_UPDATE’;

MBYTES

———

2

EXEC DBMS_STATS.GATHER_TABLE_STATS (‘UNIONE’, ‘HCC_TEST_UPDATE’, METHOD_OPT =>’ for all columns size 1′)

SELECT TABLE_NAME, BLOCKS, CHAIN_CNT FROM DBA_TABLES WHERE TABLE_NAME = ‘HCC_TEST_UPDATE’;

TABLE_NAME BLOCKS CHAIN_CNT

—————————— ——— ———

HCC_TEST_UPDATE 176 0

SELECT ROWID, OBJECT_ID FROM HCC_TEST_UPDATE WHERE OBJECT_ID =100 ;

ROWID OBJECT_ID

——————- ———

AABUaUAAHAABC+4Asp 100

UPDATE HCC_TEST_UPDATE SET TIMESTAMP = SYSDATE ;

199999 rows Updated.

SQL Execution Time > 00:00:15.897

COMMIT;

SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_UPDATE’;

MBYTES

———

9

UPDATE 이후에 테스트 결과를 보면 HCC 압축 이전에 비해 SEGMENT 값과 BLOCK 수가 증가 한 것을 볼 수 있지만 압축 전 데이터 보다는 SEGMENT 값과 BLCOK 이 줄어든 것을 볼 수 있 다. 그렇다면 왜 SEGMENT 값과 BLCOK 수는 압축 전으로 돌아가지 않았을까 ?

정확히 말해서 기존 HCC 압축형태에서 OLTP 형태의 압축으로 다운그레이드가 된 것이다. OLTP 압축 형식은 DIRECT PATH LOAD 가 발생하지 않은 상태에서도 압축이 가능하며 HCC 동작 방식에서 HCC 동작방식에서 잠시 언급한 ROW 기반의 BLOCK 단위 압축 방식이다. OLTP 형태의 압축은 HCC 압축 형태의 테이블에서 HCC 압축을 할 수 없는 경우 ( 비 DIRECT PATH LOAD ) HCC 압축에 대한 보안 압축 방식인 것이다.

테스트를 통해 자세히 알아 보도록 하자.

ALTER TABLE HCC_TEST_UPDATE MOVE COMPRESS FOR ARCHIVE LOW ;

SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME=’HCC_TEST_UPDATE’;

MBYTES

———

2

SELECT ROWID, OBJECT_ID FROM HCC_TEST_UPDATE WHERE OBJECT_ID =100;

ROWID OBJECT_ID

——————- ———

AABUaUAAHAABC+4Asp 100

UPDATE HCC_TEST_UPDATE SET TIMESTAMP = SYSDATE WHERE OBJECT_ID =100;

1 rows Updated.

COMMIT;

SELECT ROWID, OBJECT_ID FROM HCC_TEST_UPDATE WHERE OBJECT_ID =100;

ROWID OBJECT_ID

——————- ———

AABUaUAAHAAAC/HABS 100

— UPDATE 이전 ROWID 조회

SELECT ROWID, OBJECT_ID FROM HCC_TEST_UPDATE WHERE ROWID = ‘AABUaUAAHAABC+4Asp’

ROWID OBJECT_ID

——————- ———

AABUaUAAHAABC+4Asp 100

UPDATE 이후에 테이블에 ROWID 정보를 보면 ROWID 가 변경되어 이주 된 것을 볼 수 있다.

UPDATE 하기 전에 ROWID 을 조회해 보면 역시 이주한 ROWID 와 동일한 OBJECT_ID 가 존 재하며 이렇게 ROWID 가 이주하여 2 개의 ROWID 을 가지는 이유는 OLTP 압축 형태가 DIRECT PATH LOAD 가 아닌 경우 (DIRECT PATH LOAD 인 경우는 ROWID 에 대한 값이 하나만 존재) 에는 데이터를 적재하면서 압축을 하는 것이 아니라 압축되지 않은 데이터가 적재 되 다가 더 이상 BLOCK 에 데이터가 적재 될 공간이 없으면 그때 압축을 한다.

압축 후에 빈 공간 은 FREE LIST 에 반환하고 압축 되지 않은 데이터를 다시 적재하다가 다시 BLOCK 에 적재 할 공간이 없을 때 압축되지 않은 데이터를 압축하게 된다.

이 과정에서 한 ROW 값에 대해서 일부 분은 압축된 형태로 적재되어 있고 같은 ROW 에 대한 일부 데이터는 압축 되어 있지 않은 형태 의 데이터로 존재하게 되면서 ROWID 가 1 개 이상 존재 하게 된다.

다시 말해 HCC 형태의 압축된 공간에서 UPD ATE 가 발생하게 되면 OLTP 압축으로 다운그레이드가 되는데 한 ROW 에 대해서 UPDATE 되어 변경된 값은 압축되지 않은 형태로 존재하게 되고 UPDATE 가 발생하지 않은 ROW 는 압축된 형태로 존재하게 되어 ROWID 가 1 개 이상 존재 하는 것이다.

현재 필자가 지원하고 있는 고객사에서 기존 DB2 시스템에서 통계 관련 일부 업무를 EXADATA 시스템으로 구축하였는데 HCC 압축을 하고자 하는 대상에 테이블에 대해서 UPDATE 업무를 모 두 DELE TE 후 INSERT 업무로 변경하였다.

HCC 압축 시 유의 사항

시스템 초기에는 데이터가 많지 않을 것이다. 시간이 지남에 따라 데이터들이 증가 할 것이고 변경되지 않은 이력의 성격들을 가지고 있는 테이블 들은 HCC 압축으로 스토리지 공간을 절약 할 수 있다. 그러나 트랜잭션이 많은 온라인 시간에 HCC 압축을 하게 된다면 HCC 압축을 하는 동 안 DML 트랜잭션들은 테이블 LOCK (enq : TM – contention) 이 발생하여 시스템에 악 영향을 미치게 되기 때문이다.

위에 상황을 테스트로 확인해 보자.

— SESSION 1

CREATE TABLE HCC_LOCK_TEST NOLOGGING AS SELECT * FROM HCC_TEST_HCC1 ;

ALTER TABLE HCC_LOCK_TEST MOVE COMPRESS FOR ARCHIVE HIGH ;

— SESSION 2 (DML 수행)

SELECT OWNER,OBJECT_NAME,OBJECT_ID,DATA_OBJECT_ID,OBJECT_TYPE FROM HCC_LOCK_TEST WHERE ROWNUM =1 ;

OWNER OBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE

——————– ———————— ——— ————– ———–

SYS WARNING_SETTINGS$ 254 254 TABLE

UPDATE HCC_LOCK_TEST SET TIMESTAMP=SYSDATE WHERE ROWNUM < 1000;

— SESSION 3 ( TM LOCK 발생)

SQL> SELECT SID,SERIAL#,USERNAME,MACHINE,EVENT FROM V$SESSION WHERE STATUS=’ACTIVE’ AND USERNAME=’UNIONE’;

SID SERIAL# USERNAME MACHINE EVENT

——— ——— ——— ———————– ———————

4726 1017 UNIONE WORKGROUP\PARADISE-PC Enq: TM – contention

하지만 HCC 압축을 하고자 하는 대용량 테이블은 날짜를 기준으로 월이나 일별 압축을 하려고 할 것이다. 그렇다면 과거 달에 대해서 HCC 압축을 한다면 위와 같은 문제는 발생하지 않 겠지만 여전히 HCC 압축을 하기에는 많은 어려움이 존재한다.

과거 파티션에 대해서 ALTER MOVE 명령어로 HCC 압축을 하게 되면 ROWID 값이 변경되어 기존에 인덱스를 사용할 수 없게 된다. HCC 압축 이후에 INDEX REBUILD 을 해야만 한다. 인 덱스 REBUILD 시간 동안은 HCC 한 파티션은 FULL SCAN 을 하게 될 것이며 이로 인해 많은 시스템의 부하를 발생 시킬 것이다. 이러한 문제점들을 해결 하기 위해 파티션 EXCHAN GE 을 사용하여 HCC 압축을 적용 할 수 있다. 단 변경이 발생하지 않는 과거 파티션 테이블에서만 가 능하다.

테스트를 통해서 알아 보도록 하자.

— 테스트 데이터 생성

drop table HCC_PART_EXCH purge;

create table HCC_PART_EXCH

PARTITION BY RANGE (LAST_DDL_TIME)

( PARTITION HCC_PART_EXCH_201709 VALUES LESS THAN (TO_DATE(‘2017-10-01′,’yyyy-mm-dd’))

, PARTITION HCC_PART_EXCH_201710 VALUES LESS THAN (TO_DATE(‘2017-11-01′,’yyyy-mm-dd’))

, PARTITION HCC_PART_EXCH_201711 VALUES LESS THAN (TO_DATE(‘2017-12-01′,’yyyy-mm-dd’))

)

as select * from DBA_OBJECTS where LAST_DDL_TIME is not null

UNION ALL

select * from DBA_OBJECTS where LAST_DDL_TIME is not null;

CREATE INDEX HCC_PART_EXCH_IX1 ON HCC_PART_EXCH (OWNER,OBJECT_NAME) LOCAL;

ALTER TABLE HCC_PART_EXCH MOVE PARTITION HCC_PART_EXCH_201709 COMPRESS FOR ARCHIVE LOW ;

— ALTER MOVE 명령어로 HCC 일부 파티션 압축

SELECT TABLE_OWNER,TABLE_NAME,PARTITION_NAME,COMPRESSION,COMPRESS_FOR FROM

DBA_TAB_PARTITIONS WHERE TABLE_NAME=’HCC_PART_EXCH’;

TABLE_OWNER TABLE_NAME PARTITION_NAME COMPRESSION COMPRESS_FOR

————– —————– ————————- ———– ———-

UNIONE HCC_PART_EXCH HCC_PART_EXCH_201709 ENABLED ARCHIVE LOW

UNIONE HCC_PART_EXCH HCC_PART_EXCH_201710 DISABLED

UNIONE HCC_PART_EXCH HCC_PART_EXCH_201711 DISABLED

— 인덱스 UNUSABLE 상태

SELECT INDEX_NAME, PARTITION_NAME, STATUS FROM DBA_IND_PARTITIONS WHERE

INDEX_NAME=’HCC_PART_EXCH_IX1′;

INDEX_NAME PARTITION_NAME STATUS

————————- ————————- ——–

HCC_PART_EXCH_IX1 HCC_PART_EXCH_201709 UNUSABLE

HCC_PART_EXCH_IX1 HCC_PART_EXCH_201710 USABLE

HCC_PART_EXCH_IX1 HCC_PART_EXCH_201711 USABLE

— 파티션 TEMP 테이블 생성

CREATE TABLE HCC_PART_EXCH_201710_TMP NOLOGGING COMPRESS FOR ARCHIVE LOW

AS SELECT * FROM HCC_PART_EXCH PARTITION(HCC_PART_EXCH_201710);

SQL Execution Time > 00:00:01.560

CREATE INDEX HCC_PART_EXCH_201710_TMP_IX ON HCC_PART_EXCH_201710_TMP (OWNER,OBJECT_NAME);

SQL Execution Time > 00:00:00.015

— 파티션 EXCHANGE

ALTER TABLE HCC_PART_EXCH EXCHANGE PARTITION HCC_PART_EXCH_201710 WITH TABLE HCC_PART_EXCH_201710_TMP INCLUDING INDEXES WITHOUT VALIDATION ;

SQL Execution Time > 00:00:00.015

SQL> SELECT TABLE_OWNER,TABLE_NAME,PARTITION_NAME,COMPRESSION,COMPRESS_FOR FROM DBA_TAB_PARTITIONS WHERE TABLE_NAME=’HCC_PART_EXCH’;

TABLE_OWNER TABLE_NAME PARTITION_NAME COMPRESSION COMPRESS_FOR

—————- —————– —————————— ———– ————

UNIONE HCC_PART_EXCH HCC_PART_EXCH_201709 ENABLED ARCHIVE LOW

UNIONE HCC_PART_EXCH HCC_PART_EXCH_201710 ENABLED ARCHIVE LOW

UNIONE HCC_PART_EXCH HCC_PART_EXCH_201711 DISABLED

SQL> SELECT INDEX_NAME,PARTITION_NAME,STATUS FROM DBA_IND_PARTITIONS WHERE

INDEX_NAME=’HCC_PART_EXCH_IX1′;

INDEX_NAME PARTITION_NAME STATUS

—————————— —————————— ——–

HCC_PART_EXCH_IX1 HCC_PART_EXCH_201709 UNUSABLE

HCC_PART_EXCH_IX1 HCC_PART_EXCH_201710 USABLE

HCC_PART_EXCH_IX1 HCC_PART_EXCH_201711 USABLE

결론

시간이 지남에 따라 데이터가 점점 많아지면서 DBMS 시스템의 조회 성능의 문제와 스토리지 공간의 증가로 많은 비용이 발생하고 있다. 이러한 문제를 해결하기 위한 대안 중에 하나가 바로 데이터를 압축하는 것이다. 특히 EXADATA 시스템에서는 HCC 라는 진화된 압축 방법으로 스토리지 절약과 조회 성능을 최적화 시킬 수 있다.

하지만 이러한 압축 방식을 잘 이해하지 못하고 사용 한다면 시스템에 여러 가지 문제가 발생 할 수 있다. 또한 압축하고자 하 는 대상도 잘 선별 해야만 한다. 갱신이 많은 테이블에 HCC 압축을 적용 한다면 스토리지 공간 절감에 최대 효과를 볼 수 없다. 따라서 갱신이 많이 일어나지 않은 데이터에 대해서 압축 대상으로 선정하는 것이 좋다. 자주 갱신되는 데이터 아닌 변화가 적은 데이터에 대해서 HCC 압축 기술을 사용 한다면 BIG DATA 시대에 하드웨어 비용의 절감과 데이 터 처리 성능에 대해 여러 가지 시너지 효과를 얻을 수 있을 것이다.