1. 압축률

  • 현재 DB2 DW의 압축률 = 70% 수준 (table 단위의 block compression)
  • 현재 운영 Oracle의 압축률 = 55% 수준 (row 단위 compression)
  • DB2 BLU (columnar)의 압축률 = 95% (hybrid compression)
  • DB2 Netezza (columnar)의 압축률 = 75%
  • 오라클 HCC (columnar)의 압축률 = 85% ~ 92.5% (외부 압축 알고리즘 도입)


    ■ 압축률
    - Query Low : 85%
    - Query High :   
    - Archive Low :
    - Archive High : 92.5%

실질적으로 운영환경에서 사용할 수 있는 압축방식은 제공되는 4 가지 옵션 중
성능의 문제로 인해 Query Low 하나라고 보면 되겠고,

Archive Low/High 압축의 경우는
곧바로 읽을 수 있다는 장점이 있는 마그네틱 테이프를 생각하시면 되겠다.


■ Query Low
    CU (Compression Unit)의 크기 : 32k
    LZO 알고리즘

■ Query High
    CU 크기 : 32~64k
    ZLIB 알고리즘

■ Archive Low
    CU 크기 : 32~256k
    ZLIB 알고리즘


■ Archive High
    BZIP2 알고리즘






2. 성능
압축 시 데이터 크기 자체가 줄어들음으로 인해, 조회 성능은 개선되나,
데이터 ETL 시 불리하다.

■ Insert 성능

query low = 20초
query high = 40초
archive low = 40초
archive high = 240초


■ SQL 쿼리 성능

비압축 = IO bound :171초, CPU bound : 13초
query low = IO bound :91초, CPU bound : 16초
query high = IO bound :73초, CPU bound : 19초
archive low = IO bound :74초, CPU bound : 19초
archive high = IO bound :118초, CPU bound : 33초





3. 기타 기술적인 제약

- 특성 상 데이터의 Sort 상태를 유지하여야 압축률이 높아짐

- 조회한 데이터를 메모리 버퍼에 올리거나, aggregate 또는 sort 동작을 위해 temporary 영역에 넣으려면 압축을 해제해야 함

- Index를 읽어 데이터를 조회할 때, 하나의 CU를 여러 번 압축 해제 해야 하는 문제로 성능이 저하될 수 있음
  ∵ 정렬된 rowid 순서로 select하는 게 아니라, 컬럼 데이터 순서로 정렬된 rowid 포인터로 CU를 읽기 때문

- HCC 압축된 row에 update가 수행되면, 이 데이터는 압축이 풀리면서 기존의 낮은 압축률 공간으로 옮겨지며
  이 과정도 느릴 뿐더러, 향후 조회 시 HCC블럭, OLTP블럭 두 군데를 읽어야 하므로 성능 저하
  업데이트가 있는 테이블에는 HCC를 적용하지 않을 것을 권고

- 하나의 row를 업데이트 하더라도, 그 row가 걸쳐있는 전체 CU를 lock 걸어야 하는데, 이로 인해 빈번한 lock wait 발생 가능, 동시성 저하

- 이를 해결하기 위해서는 Oracle 12c Advanced Compression 옵션을 구매해야 하며, 적용 시 일반적인 RDBMS의 row level locking이 가능해짐

- 그러나, 이 정보를 관리하기 위한 overhead가 발생하여, 약 10% 가량의 데이터 사이즈가 증가함

- partition table의 경우, 압축된 후의 사이즈가 충분히 크지 않으면 direct path read 플랜 (스마트 스캔을 가능하게 하는) 으로 풀리지 않게 되고,
이로인해 결국 스마트 스캔을 하지 않게 되면서, 셀 노드의 CPU로 압축해제 하지 못하고, DB 서버에 CPU 부하를 주게 될 수 있음.
다시 말해, 월별 건수가 애매하게 작으면 DB서버 CPU 부하 상당량 발생 (이 기준점은 알 수 없음)



4. 환경 고려사항


- HCC 압축을 하기 위해서는 모든 insert문을 수정해야 함. INSERT /*+ APPEND */ INTO


- HCC가 적용된 DB의 백업본을 복구하기 위해서도 Exadata가 필요함 (Exadata Storage server 이외의 HW에서는 HCC 사용에 제약이 걸려있어)

- 오라클 ZFS 스토리지 어플라이언스에 복구가 가능하기는 하나, 스토리지를 백업본 크기의 10배를 준비해야 하며,
   ALTER TABLE NOCOMPRESS로 압축을 다 풀기 전에는 조회 불가

Posted by in0de
,

sqllib/tmp

DB2 LUW 2009. 4. 16. 16:38

${instance home}/sqllib/tmp는 다음의 유틸리티/어플리케이션/툴 들에 의해 I/O가 발생한다.

DB2 Engine
db2 Utilities(Backup, load, import 등)
DB2 Governor
DB2 Snapshot functions
DB2 GUI tools / DB2 Wizards
  (ie. Server profile generated from the Control Center, Redistribution Data wizard) 
DB2 Extenders (ie. Text Information Extender)
any application (ie. WebSphere)


Linux의 경우, sqllib/tmp 에 named pipe를 생성하여
frontend(db2), backend(db2bp) 프로세스 간의 통신을 하기도 한다.

DB2 Engine에서의 temporary processing의 세부내용은 알 수 없겠지만
대부분의 경우는 index key sorting 이라던가
여러 utility나 application들에 의해 I/O가 발생된다고 보면 되겠다.

엔터프라이즈 시스템에서의 sqllib/tmp의 위치는 신경써서 정해야할 듯 한데
실제로 이 디렉토리를 모니터링해보면 상당히 자주, 많이 access하고있고

파일시스템에 문제가 있거나
(ie. 시만텍의 매우 오래된 VxFS 4.0.3.2 (4.0 MP3RP2)의
비효율적인 dirty page scan 알고리즘으로 인해 disk I/O의 30%를 일으켰던 경우)

좋지 못한 성능의 Internal disk에 instance home을 둔다거나 한다면
전체적으로 DB의 성능을 떨어뜨릴 수 있기 때문이다.

instance home 디렉토리는 디스크 장애에 의해서 inaccessible할 경우
DB에 대해서 어떠한 제어도 할 수 없게 되므로, 안정적인 디스크에 두어야 하며

안정적인 디스크에 instance home을 두었으나 속도가 좋지 못해,
sqllib/tmp로 인한 성능 저하가 우려되는 경우
DB 자체적으로 sqllib/tmp의 위치를 hidden parameter등으로 변경할 방법은 존재하지 않으며
다음과 같은 방법으로 성능 좋은 디스크 쪽의 디렉토리를 링크하여
안정성과 성능을 둘 다 만족시킬 수 있다.

mkdir ${better perf disk path}/newTmpPath
rm -rf ${instance home}/sqllib/tmp
ln -s ${better perf disk path}/newTmpPath ${instance home}/sqllib/tmp
Posted by in0de
,
Tablespace의 File System Caching 기능을 해제하여 DB2 응답 성능을 향상시킬 수 있다.

모든 I/O를 할 때, OS 레벨의 File system caching 기능을 사용하지 않고
DB2의 bufferpool만을 사용하는 개념인데,
모든 상황, 모든 버전에서 효과가 있는 지는 테스트를 해봐야 알 것 같다.

Filesystem caching On 상태

이 상태로 속도는 최초 수행 시 0.83초, 반복 수행 시 0.45초로 나타났다.
정확한 측정을 위해서는 db2batch command를 사용해야하나, 측정 결과는 크게 다르지 않다.

Alter tablespace문의 NO FILE SYSTEM CACHING command option으로 OS level의 cache를 사용하지 않도록 지정한다.
online으로 바로 적용 가능하며, Connection terminate 이후부터 반영된다.

FSC 컬럼을 보면 Filesystem caching이 해제된 것을 확인할 수 있다.

적용 후의 동일 쿼리 수행 결과

OS Caching을 bypass함으로써, 상당한 성능 향상을 볼 수 있다.

단, 다음 환경에서의 테스트에 따르면
OS : AIX 5.3, CPU : 2, Memory : 2GB, DB size : 8GB, Partition : Single, db2_parallelism_io = null
FSC OFF 할 경우 백업 속도가
36MB/sec에서 30MB/sec 정도로 느려질 수 있다는 결과가 있다.
Posted by in0de
,