oracle exadata hcc 압축방식 이해하기_wh oracle

248│2013 기술백서 White Paper

ORACLE EXADATA HCC 압축방식 이해하기

㈜엑셈 컨설팅본부/DB컨설팅팀 김 철환

개요

시간이 지나면서 데이터는 급속하게 증가하고 있다. 데이터가 증가함에 따라 DBMS에서 관리

되어지는 정보도 급속하게 증가 하고 있다. 이로 인해 저장공간의 부족으로 하드웨어 비용의 증

가와 데이터 처리 성능에 많은 문제 점들이 나타나고 있다.

이러한 문제점들을 해결하고자 ORACLE 에서는 EXADATA라는 시스템을 통해 스토리지 공간

부족현상과 데이터 처리 성능을 향상시키고자 하였다. EXADATA시스템이란 대용량 데이터베

이스에서 디스크 스토리지 시스템에서 데이터베이스 서버로 많은 데이터를 이동 시킬 때 발생하

는 많은 비효율을 하드웨어와 소프트웨어의 조합을 통해 해결 하고자 한 것이 EXADATA 시스템

이라 하는데 HCC (HYBRID COLUMNAR COMPRESSION) 라는 압축 기술을 통해 이와 같은

문제점들을 해결 할 수 있다.

본 장에서는 EXADATA 시스템의 HYBRID COLUMNAR COMPRESSION 압축을 중심으로 이야

기 할 것이다. 데이터 압축의 원리를 알아보고 디스크 공간 절약과 데이터 조회의 성능에 어떤

영향을 미치는지 비교해 보고자 한다.

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

데이터를 압축을 하게 되면 스토리지 공간을 절약 할 수 있다. 압축에도 여러 가지 방법으로 데

이터들을 압축 할 수 있으며 EXADATA 시스템에서는 HCC 라는 압축 방식을 통해 보다 진보된

방식으로 압축을 할 수 있다. HCC 이전에 압축 방식은 BLOCK 안에 중복된 값들을 하나의 값으

로 가지고 있고 그 값을 참조하는 주소 값을 통해서 중복 데이터를 접근하는 방식인 ROW 데이

터를 기반으로 하는 압축 방식 이였다.

Part 1 ORACLE │249

ROW 기반 압축에서 진보된 형태의 압축이 HCC 압축이라고 할 수 있으며 HCC 압축 방식은

EXADATA에서만 사용 할 수 있다. HCC(HYBRID COLUMNAR COMPRESSION) 이란 칼럼기

반 압축 방식으로 같은 유형의 데이터와 비슷한 칼럼 속성을 인접하여 저장하면 보다 효과적인

압축을 하여 스토리지 공간을 효율적으로 줄일 수 있다. 칼럼과 ROW 의 조합으로 저장공간의

효율성과 좋은 성능을 기대할 수 있는 HYBRID 압축 방식이다.

[그림1] COMPRESSION UNIT의 배치 구조

HCC 압축 방식은 더 이상 ROW 단위로 데이터를 저장하지 않고 CU(COMPRESSION UNIT) 단

위로 저장 된다. 그림 1과 같이 하나의 CU 을 보통 32K나 64K 구성 되어 있다. CU는 여러 개

의 BLOCK 을 가지고 있으며 CU 안에 데이터들은 칼럼으로 다시 재 구성된다.

이렇게 구성된 CU의 장점은 CU을 한번만 읽으므로 ROW 전체를 읽을 수 있는 장점이 있지만

칼럼 전체를 읽으려면 모든 UN을 읽어야만 하기 때문에 완벽한 칼럼 기반 압축 방식이라고는

할 수 없다. 완벽한 칼럼 방식으로 구성 되었다면 모든 CU을 읽지 않고 모든 칼럼들을 읽었을

것이다.

하지만 HCC 압축은 칼럼 형태의 압축의 장점인 디스크 절약과 ROW 형태의 압축의 장점인 조

회 성능을 모두 만족 시킬 수 있는 HYBRID 압축 이라고 하겠다.

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

HCC 방식은 여러 가지 유형이 존재하며 아래 표를 통해서 각 유형들의 특징을 볼 수 있다. 아래

표를 참고하여 테스트를 통해 압축 유형들의 특징들을 구체적으로 알아 보도록 하자.


압축 유형 설명 예상 압축률

QUERY LOW

HCC 레벨1 은 LZO 압축 알고리즘을 사용한다 이 레벨은 가장 낮

은 압축률을 제공하지만， 압축 및 압축해제 작업을 위해 최소한

의 CPU를 필요로 한다 이 알고리즘은QUERYLOW 알고리즘은 압

축보다는 속도를 극대화할 수 있도록 최적화되었다. 이 알고리즘

의 압축해제는 대단히 빠르다 일부 문서에서 이 레벨을

WAREHOUSE LOW 지칭하는 것을 볼 수 있다.

4X

QUERY HIGH HCC 레벨2는 ZLlB(gzip) 압축 알고리즘을 사용한다 일부 문서는

이 레벨을 WAREHOUSE HIGH로 지칭한다 6X

ARCHIVE LOW

HCC 레벨3 또한 ZLlB(gzip) 알고리즘을 사용하지만. QUERYHIGH

보다 더 높은 압축 레벨이다. 그러나 데이터에 따라 압축률은

QUERY HIGH보다 높지 않을 수도 있다.

7X

ARCHIVE HIGH

HCC 레벨4 압축은 Bzip2 압축을 사용한다 이것은 사용 가능한

가장 높은 레벨의 압축이지만， 단연코 가장 CPU 집약적이다.

압축 시간은 종종 레벨2와 3보다 몇 배ARCHIVE HIGH 느리다.

그러나 대상 데이터에 따라 압축률은 ARCHIVELOW보다 많이 높

지 않을 수도 있다 이 레벨은 데이터 압축에 필요한 시간은 상대

적으로 덜 중요하지만 심각한 공간 부족을 겪는 상황을 대비한

것이다.

12X

[표 1-1 ] 압축유형

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

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

CREATE TABLE HCC_TEST AS SELECT * FROM DBA_OBJECTS;

INSERT INTO HCC_TEST AS SELECT * FROM HCC_TEST ; (x 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 ;


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 ;



MBYTES

---------

104

-- HCC 레벨 4

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



MBYTES

---------

72


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

테이블 명 압축방법 압축률 적재시간

HCC_TEST_HCC1 QUERY LOW 8 00:00:20

HCC_TEST_HCC2 QUERY HIGH 15.4 00:00:40

HCC_TEST_HCC3 ARCHIVE LOW 15.4 00:00:40

HCC_TEST_HCC4 ARCHIVE HIGH 22.2 00:04:01

[표 2-1 ] 압축유형 테스트 결과

표 1 압축 유형 테스트 결과를 살펴보면 압축 단계가 높을 수록 압축률이 높아 진다. 즉 압축 레

벨이 높을수록 스토리지 공간을 절약 할 수가 있다. QUERY HIGH을 보면 QUERY LOW 비해

압축률이 7배 정도 좋아졌지만 적재시간도 2배 정도 소요 되었다. ARCHIVE LOW 보면

QUERY HIGH와 거의 차이를 보이지 않고 있다. ARCHIVE HIGH을 보면 압축률이 ARCHIVE

LOW 비해 7배 정도 좋아 졌지만 시간은 4배 정도 더 느려졌다.

결과적으로 레벨의 단계가 높을 수록 압축률은 좋아 졌지만 적재는 더 많은 시간을 요구 하고 있

다. 또한 압축 하는 동안 많은 시간이 소요 된다면 시스템 자원도 오랜 시간 동안 사용 해야 할

것이다.

HCC 압축과 QUERY 성능과의 관계

HCC 압축과 QUERY 의 성능을 알아보려고 한다. 여기서 2가지 테스트를 해 보겠다. I/O 집약

적인 QUERY 성능 테스트와 CPU 작업 집약적인 QUERY 성능 테스트를 해 보겠다. 이렇게 테스

트를 하는 이유는 쿼리에 상황에 따라서 성능에 차이를 보이기 때문이다.


I/O 집약적인 QUERY

SQL> select sum(OBJECT_ID) from HCC_TEST;

SUM(OBJECT_ID)

--------------

7.4e+011


SQL> select sum(OBJECT_ID) from HCC_TEST_HCC1;

SUM(OBJECT_ID)

--------------

7.4e+011



SUM(OBJECT_ID)

--------------

7.4e+011



SUM(OBJECT_ID)

--------------

7.4e+011



SUM(OBJECT_ID)

--------------

7.4e+011



CPU 집약적인 QUERY

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST',METHOD_OPT =>' for all columns

size 1');

PL/SQL executed.


SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST_HCC1', METHOD_OPT =>' for all

columns size 1');

PL/SQL executed.



columns size 1');

PL/SQL executed.



columns size 1');

PL/SQL executed.


SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS ('BIZMAX', 'HCC_TEST_HCC4', METHOD_OPT =>' for all

columns size 1');

PL/SQL executed.


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

테이블 명 I/O집약적 CPU 집약적

HCC_TEST 00:02:51 00:00:13

HCC_TEST_HCC1 00:01:31 00:00:16

HCC_TEST_HCC2 00:01:13 00:00:19

HCC_TEST_HCC3 00:01:14 00:00:19

HCC_TEST_HCC4 00:01:58 00:00:33

[표 2-2 ] 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



Statement Processed.


ALTER TABLE HCC_TEST COMPRESS FOR ARCHIVE LOW ;

INSERT INTO HCC_TEST SELECT * FROM HCC_TEST_HCC1;

COMMIT;



---------------------------

1536


Statement Processed.


ALTER TABLE HCC_TEST COMPRESS FOR ARCHIVE LOW ;

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

COMMIT;



---------------------------

104

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



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 ('BIZMAX', '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 ;


MBYTES

---------

2

EXEC DBMS_STATS.GATHER_TABLE_STATS ('BIZMAX', '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.


COMMIT;


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 ;


MBYTES

---------

2



ROWID OBJECT_ID

------------------- ---------


UPDATE HCC_TEST_UPDATE SET TIMESTAMP = SYSDATE WHERE OBJECT_ID =100;

1 rows Updated.

COMMIT;


ROWID OBJECT_ID

------------------- ---------

AABUaUAAHAAAC/HABS 100

-- UPDATE 이전 ROWID 조회

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

ROWID OBJECT_ID

------------------- ---------


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 형태의 압축된 공간에서 UPDATE가 발생하게 되면 OLTP 압축으로 다운그레이

드가 되는데 한 ROW에 대해서 UPDATE되어 변경된 값은 압축되지 않은 형태로 존재하게 되


고 UPDATE가 발생하지 않은 ROW는 압축된 형태로 존재하게 되어 ROWID가 1개 이상 존재

하는 것이다.

현재 필자가 지원하고 있는 고객사에서 기존 DB2 시스템에서 통계 관련 일부 업무를 EXADATA

시스템으로 구축하였는데 HCC 압축을 하고자 하는 대상에 테이블에 대해서 UPDATE 업무를 모

두 DELETE 후 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='BIZMAX';


SID SERIAL# USERNAME MACHINE EVENT

--------- --------- --------- ----------------------- ---------------------

4726 1017 BIZMAX WORKGROUP\PARADISE-PC Enq: TM - contention

하지만 HCC 압축을 하고자 하는 대용량 테이블은 날짜를 기준으로 월이나 일별 압축을 하려고

할 것이다. 그렇다면 과거 달에 대해서 HCC 압축을 한다면 위와 같은 문제는 발생하지 않겠지만

여전히 HCC 압축을 하기에는 많은 어려움이 존재한다.

과거 파티션에 대해서 ALTER MOVE 명령어로 HCC 압축을 하게 되면 ROWID 값이 변경되어

기존에 인덱스를 사용할 수 없게 된다. HCC 압축 이후에 INDEX REBUILD을 해야만 한다. 인

덱스 REBUILD 시간 동안은 HCC 한 파티션은 FULL SCAN을 하게 될 것이며 이로 인해 많은

시스템의 부하를 발생 시킬 것이다. 이러한 문제점들을 해결 하기 위해 파티션 EXCHANGE을

사용하여 HCC 압축을 적용 할 수 있다. 단 변경이 발생하지 않는 과거 파티션 테이블에서만 가

능하다.

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

-- 테스트 데이터 생성

drop table HCC_PART_EXCH purge;

create table HCC_PART_EXCH

PARTITION BY RANGE (LAST_DDL_TIME)

( PARTITION HCC_PART_EXCH_201309 VALUES LESS THAN (TO_DATE('2013-10-01','yyyy-mm-dd'))

, PARTITION HCC_PART_EXCH_201310 VALUES LESS THAN (TO_DATE('2013-11-01','yyyy-mm-dd'))

, PARTITION HCC_PART_EXCH_201311 VALUES LESS THAN (TO_DATE('2013-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_201309 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

-------------- ----------------- ------------------------- ----------- ----------

BIZMAX HCC_PART_EXCH HCC_PART_EXCH_201309 ENABLED ARCHIVE LOW

BIZMAX HCC_PART_EXCH HCC_PART_EXCH_201310 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_201309 UNUSABLE

HCC_PART_EXCH_IX1 HCC_PART_EXCH_201310 USABLE


-- 파티션 TEMP 테이블 생성

CREATE TABLE HCC_PART_EXCH_201310_TMP NOLOGGING COMPRESS FOR ARCHIVE LOW

AS SELECT * FROM HCC_PART_EXCH PARTITION(HCC_PART_EXCH_201310);


CREATE INDEX HCC_PART_EXCH_201310_TMP_IX ON HCC_PART_EXCH_201310_TMP (OWNER,OBJECT_NAME);


-- 파티션 EXCHANGE

ALTER TABLE HCC_PART_EXCH EXCHANGE PARTITION HCC_PART_EXCH_201310

WITH TABLE HCC_PART_EXCH_201310_TMP INCLUDING INDEXES

WITHOUT VALIDATION;


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

---------------- ----------------- ------------------------------ ----------- ------------




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_201309 UNUSABLE



결론

시간이 지남에 따라 데이터가 점점 많아지면서 DBMS 시스템의 조회 성능의 문제와 스토리지

공간의 증가로 많은 비용이 발생하고 있다. 이러한 문제를 해결하기 위한 대안 중에 하나가 바로

데이터를 압축하는 것이다. 특히 EXADATA 시스템에서는 HCC라는 진화된 압축 방법으로 스토

리지 절약과 조회 성능을 최적화 시킬 수 있다.

하지만 이러한 압축 방식을 잘 이해하지 못하고 사용 한다면 시스템에 여러 가지 문제가 발생 할

수 있다. 또한 압축하고자 하는 대상도 잘 선별 해야만 한다. 갱신이 많은 테이블에 HCC 압축을

적용 한다면 스토리지 공간 절감에 최대 효과를 볼 수 없다. 따라서 갱신이 많이 일어나지 않은

데이터에 대해서 압축 대상으로 선정하는 것이 좋다. 자주 갱신되는 데이터 아닌 변화가 적은 데

이터에 대해서 HCC 압축 기술을 사용 한다면 BIG DATA 시대에 하드웨어 비용의 절감과 데이

터 처리 성능에 대해 여러 가지 시너지 효과를 얻을 수 있을 것이다.

oracle exadata hcc 압축방식 이해하기_wh oracle

Education