TABLE COMPRESS

Oracle 9i Release 2 Enterprise Edition 에서 소개된 TABLE Compress 기능은 블록 내에 저장되어 있는 데이터의 중복을 제거 함으로써 블록 내에 많은 데이터를 저장함으로써 저장공간의 효율성을 높이는 기술입니다.

반복되는 데이터를 블록의 시작 부분에  symbol table의 row로 생성하고 실재 row data는 이 row의 참조로 대체합니다. 해당 block의 row에 대한 데이터는 global symbol table이 아닌 해당 block내의 local symbol table로 만들어집니다.

따라서 블록에서 압축되지 않은 데이타를 다시 만드는데 필요한 모든 정보를 해당 블록 내에서 사용할 수 있습니다.

블록의 시작 부분에 있는 심볼 테이블을 제외하고 압축된 데이타베이스 블록은 일반 데이타베이스 블록과 비슷합니다.  결과적으로 일반 데이타베이스 블록에서 작동하는 모든 데이타베이스 기능은 압축된 데이타베이스 블록에서도 동일하게 작동한다고 합니다.

Table compress 기능은 storage의 높은 활용도와 질의시 적은 I/O양, buffer cache내의 압축된 형태 유지로 더 많은 데이터를 메모리 내에 유지하는 등의 장점을 갖고 있으나, DML 작업은 compress가 적용되지 않은 일반 table에 비해 느리며, CPU 사용률이 높아지는 단점도 가지고 있습니다.

compress의 경우 다른 고려 사항없이 compress 만 지정하면 oracle에서 자동으로 compress를 진행합니다. 대부분의 자료에서는 2:1 ~ 4:1 정도의 compress 비율을 말하지만 data의 속성, 군집 여부 등 많은 변수에 의해 편차가 많아 실 데이터의 sampling으로 compress 비율을 확인하는 것이 그나마 가장 확실 합니다.

compress는 동일 column data가 2개 이상이면 compress 대상이 되며, 서로 다른 column에 같은 값이 존재해도 이에 대해 compress를 하게 됩니다.

compress가 되는 시점은 한개의 block내에 pctfree에 도달하면 compress를 하며 compress 후 빈 공간에 non-compress row를 insert 하고 pctfree에 도달하면 다시 compress.. 를 반복하게 됩니다.

2010/05/04 Update:

UPDATE, INSERT가 많은 table에 대해서 COMPRESS optoin 사용은 자제 해야 되겠네요. 
이틀동안 UPDATE 문 성능으로 헤매다가 결국 OLTP COMPERSS 문제인 걸 확인했네요. --;

In general table compression is good for read only operations.Following is excerpt from "Table Compression" section of Data Warehousing Guide manual, which suggests that it is not a good idea to compress a table which expects a large update,because there are CPU overheads and big space consumption :
Table compression should be used with highly redundant data, such as tables with many foreign keys. You should avoid compressing tables with much update or other DML activity. Although compressed tables or partitions are updatable, there is some overhead in updating these tables, and high update activity may work against compression by causing some space to be wasted.