ORACLE EXADATA HCC 압축방식이해하기 엑셈컨설팅본부 /DB 컨설팅팀김철환 개요 시간이지나면서데이터는급속하게증가하고있다. 데이터가증가함에따라 DBMS 에서관리되어지는정보도급속하게증가하고있다. 이로인해저장공간의부족으로하드웨어비용의증가와데이터처리성능에많은문제점들

Size: px

Start display at page:

Download "ORACLE EXADATA HCC 압축방식이해하기 엑셈컨설팅본부 /DB 컨설팅팀김철환 개요 시간이지나면서데이터는급속하게증가하고있다. 데이터가증가함에따라 DBMS 에서관리되어지는정보도급속하게증가하고있다. 이로인해저장공간의부족으로하드웨어비용의증가와데이터처리성능에많은문제점들"

지은 손
5 years ago
Views:

1 ORACLE EXADATA HCC 압축방식이해하기 엑셈컨설팅본부 /DB 컨설팅팀김철환 개요 시간이지나면서데이터는급속하게증가하고있다. 데이터가증가함에따라 DBMS 에서관리되어지는정보도급속하게증가하고있다. 이로인해저장공간의부족으로하드웨어비용의증가와데이터처리성능에많은문제점들이나타나고있다. 이러한문제점들을해결하고자 ORACLE 에서는 EXADATA 라는시스템을통해스토리지공간부족현상과데이터처리성능을향상시키고자하였다. EXADATA 시스템이란대용량데이터베이스에서디스크스토리지시스템에서데이터베이스서버로많은데이터를이동시킬때발생하는많은비효율을하드웨어와소프트웨어의조합을통해해결하고자한것이 EXADATA 시스템이라하는데 HCC (HYBRID COLUMNAR COMPRESSION) 라는압축기술을통해이와같은문제점들을해결할수있다. 본장에서는 EXADATA 시스템의 HYBRID COLUMNAR COMPRESSION 압축을중심으로이야 기할것이다. 데이터압축의원리를알아보고디스크공간절약과데이터조회의성능에어떤 영향을미치는지비교해보고자한다. HCC 란무엇이며어떻게동작하는지알아보자. 데이터를압축을하게되면스토리지공간을절약할수있다. 압축에도여러가지방법으로데이터들을압축할수있으며 EXADATA 시스템에서는 HCC 라는압축방식을통해보다진보된방식으로압축을할수있다. HCC 이전에압축방식은 BLOCK 안에중복된값들을하나의값으로가지고있고그값을참조하는주소값을통해서중복데이터를접근하는방식인 ROW 데이터를기반으로하는압축방식이였다 기술백서 White Paper

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

2 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 방식은여러가지유형이존재하며아래표를통해서각유형들의특징을볼수있다. 아래 표를참고하여테스트를통해압축유형들의특징들을구체적으로알아보도록하자. Part 1 ORACLE 249

3 압축유형설명예상압축률 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 기술백서 White Paper

4 -- HCC 레벨 1 CREATE TABLE HCC_TEST_HCC1 COMPRESS FOR QUERY LOW AS SELECT * FROM HCC_TEST ; SQL Execution Time > 00:00: SQL> SELECT SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC1'; HCC 레벨 2 CREATE TABLE HCC_TEST_HCC2 COMPRESS FOR QUERY HIGH AS SELECT * FROM HCC_TEST ; SQL Execution Time > 00:00: SELECT SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC2'; HCC 레벨 3 CREATE TABLE HCC_TEST_HCC3 COMPRESS FOR ARCHIVE LOW AS SELECT * FROM HCC_TEST ; SQL Execution Time > 00:00: SELECT SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC3'; HCC 레벨 4 CREATE TABLE HCC_TEST_HCC4 COMPRESS FOR ARCHIVE HIGH AS SELECT * FROM HCC_TEST ; SQL Execution Time > 00:04: SELECT SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC4'; 72 Part 1 ORACLE 251

5 압축유형에따른테스트결과 테이블명 압축방법 압축률 적재시간 HCC_TEST_HCC1 QUERY LOW 8 00:00:20 HCC_TEST_HCC2 QUERY HIGH :00:40 HCC_TEST_HCC3 ARCHIVE LOW :00:40 HCC_TEST_HCC4 ARCHIVE HIGH :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 성능테스트를해보겠다. 이렇게테스트를하는이유는쿼리에상황에따라서성능에차이를보이기때문이다 기술백서 White Paper

6 I/O 집약적인 QUERY SQL> select sum(object_id) from HCC_TEST; SUM(OBJECT_ID) e+011 SQL Execution Time > 00:02: SQL> select sum(object_id) from HCC_TEST_HCC1; SUM(OBJECT_ID) e+011 SQL Execution Time > 00:01: SQL> select sum(object_id) from HCC_TEST_HCC2; SUM(OBJECT_ID) e+011 SQL Execution Time > 00:01: SQL> select sum(object_id) from HCC_TEST_HCC3; SUM(OBJECT_ID) e+011 SQL Execution Time > 00:01: SQL> select sum(object_id) from HCC_TEST_HCC4; SUM(OBJECT_ID) e+011 SQL Execution Time > 00:01: Part 1 ORACLE 253

7 CPU 집약적인 QUERY SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST',METHOD_OPT =>' for all columns size 1'); PL/SQL executed. SQL Execution Time > 00:00: SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST_HCC1', METHOD_OPT =>' for all columns size 1'); PL/SQL executed. SQL Execution Time > 00:00: SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST_HCC2', METHOD_OPT =>' for all columns size 1'); PL/SQL executed. SQL Execution Time > 00:00: SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST_HCC3', METHOD_OPT =>' for all columns size 1'); PL/SQL executed. SQL Execution Time > 00:00: SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS ('BIZMAX', 'HCC_TEST_HCC4', METHOD_OPT =>' for all columns size 1'); PL/SQL executed. SQL Execution Time > 00:00: 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 성능테스트결과 기술백서 White Paper

8 표 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; Part 1 ORACLE 255

9 Statement Processed. SQL Execution Time > 00:00: 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: 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: SELECT SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC3'; 104 테이블을생성후 ALTER 명령어를통해테이블형태를 ARCHIVE LOW 형태의압축형태로테 이블로변경하였다. 테이블은압축형태로변경되었지만 DIRECT PATH LOAD 발생하지않은 기술백서 White Paper

10 상태에서데이터적재와원본테이블의 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 < ; SELECT SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_UPDATE'; 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 ALTER TABLE HCC_TEST_UPDATE MOVE COMPRESS FOR ARCHIVE LOW ; SELECT SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_UPDATE'; 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 SELECT ROWID, OBJECT_ID FROM HCC_TEST_UPDATE WHERE OBJECT_ID =100; Part 1 ORACLE 257

11 ROWID OBJECT_ID - AABUaUAAHAABC+4Asp 100 UPDATE HCC_TEST_UPDATE SET TIMESTAMP = SYSDATE ; rows Updated. SQL Execution Time > 00:00: COMMIT; SELECT SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_UPDATE'; 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 FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_UPDATE'; 2 SELECT ROWID, OBJECT_ID FROM HCC_TEST_UPDATE WHERE OBJECT_ID =100; 기술백서 White Paper

12 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 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 형태의압축된공간에서 UPDATE 가발생하게되면 OLTP 압축으로다운그레이 드가되는데한 ROW 에대해서 UPDATE 되어변경된값은압축되지않은형태로존재하게되 Part 1 ORACLE 259

13 고 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$ 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'; 기술백서 White Paper

14 SID SERIAL# USERNAME MACHINE EVENT 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_ VALUES LESS THAN (TO_DATE(' ','yyyy-mm-dd')), PARTITION HCC_PART_EXCH_ VALUES LESS THAN (TO_DATE(' ','yyyy-mm-dd')), PARTITION HCC_PART_EXCH_ VALUES LESS THAN (TO_DATE(' ','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_ 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'; Part 1 ORACLE 261

15 TABLE_OWNER TABLE_NAME PARTITION_NAME COMPRESSION COMPRESS_FOR BIZMAX HCC_PART_EXCH HCC_PART_EXCH_ ENABLED ARCHIVE LOW BIZMAX HCC_PART_EXCH HCC_PART_EXCH_ DISABLED BIZMAX HCC_PART_EXCH HCC_PART_EXCH_ 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_ UNUSABLE HCC_PART_EXCH_IX1 HCC_PART_EXCH_ USABLE HCC_PART_EXCH_IX1 HCC_PART_EXCH_ 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); SQL Execution Time > 00:00: CREATE INDEX HCC_PART_EXCH_201310_TMP_IX ON HCC_PART_EXCH_201310_TMP (OWNER,OBJECT_NAME); SQL Execution Time > 00:00: 파티션 EXCHANGE ALTER TABLE HCC_PART_EXCH EXCHANGE PARTITION HCC_PART_EXCH_ WITH TABLE HCC_PART_EXCH_201310_TMP INCLUDING INDEXES WITHOUT VALIDATION; SQL Execution Time > 00:00: 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 BIZMAX HCC_PART_EXCH HCC_PART_EXCH_ ENABLED ARCHIVE LOW BIZMAX HCC_PART_EXCH HCC_PART_EXCH_ ENABLED ARCHIVE LOW BIZMAX HCC_PART_EXCH HCC_PART_EXCH_ DISABLED SQL> SELECT INDEX_NAME,PARTITION_NAME,STATUS FROM DBA_IND_PARTITIONS WHERE INDEX_NAME='HCC_PART_EXCH_IX1'; 기술백서 White Paper

16 INDEX_NAME PARTITION_NAME STATUS HCC_PART_EXCH_IX1 HCC_PART_EXCH_ UNUSABLE HCC_PART_EXCH_IX1 HCC_PART_EXCH_ USABLE HCC_PART_EXCH_IX1 HCC_PART_EXCH_ USABLE 결론 시간이지남에따라데이터가점점많아지면서 DBMS 시스템의조회성능의문제와스토리지공간의증가로많은비용이발생하고있다. 이러한문제를해결하기위한대안중에하나가바로데이터를압축하는것이다. 특히 EXADATA 시스템에서는 HCC 라는진화된압축방법으로스토리지절약과조회성능을최적화시킬수있다. 하지만이러한압축방식을잘이해하지못하고사용한다면시스템에여러가지문제가발생할수있다. 또한압축하고자하는대상도잘선별해야만한다. 갱신이많은테이블에 HCC 압축을적용한다면스토리지공간절감에최대효과를볼수없다. 따라서갱신이많이일어나지않은데이터에대해서압축대상으로선정하는것이좋다. 자주갱신되는데이터아닌변화가적은데이터에대해서 HCC 압축기술을사용한다면 BIG DATA 시대에하드웨어비용의절감과데이터처리성능에대해여러가지시너지효과를얻을수있을것이다. Part 1 ORACLE 263

Bind Peeking 한계에따른 Adaptive Cursor Sharing 등장 엑셈컨설팅본부 /DB 컨설팅팀김철환 Bind Peeking 의한계 SQL 이최초실행되면 3 단계의과정을거치게되는데 Parsing 단계를거쳐 Execute 하고 Fetch 의과정을통해데이터

Bind Peeking 한계에따른 Adaptive Cursor Sharing 등장 엑셈컨설팅본부 /DB 컨설팅팀김철환 Bind Peeking 의한계 SQL 이최초실행되면 3 단계의과정을거치게되는데 Parsing 단계를거쳐 Execute 하고 Fetch 의과정을통해데이터를사용자에게전송하게되며 Parsing 단계에서실행계획이생성된다. Bind 변수를사용하는 SQL