IBM DB2 UDB Blog Center

소개

메모리 튜너는 활성화되면 정렬 힙(sort heap), 패키지 캐시, 잠금 목록, 버퍼 풀 등을 포함하여 사용 가능한 메모리 자원을 여러 메모리 소비자에 동적으로 배포한다. 이 기능은 전체 시스템 성능을 높이려고 조금씩 반복하여 메모리 구성을 수정하는 식으로 작동한다.

STMM에서 변경한 모든 내용은 db2diag.log와 STMM 로그 파일 두 곳에 기록된다. 다음에서 두 로그 파일의 내용과 db2diag 도구, parseStmmLogFile.pl 도구를 사용하여 STMM이 변경한 내용을 모니터링하는 방법을 설명한다.

STMM이 작동하는 방법

STMM은 추가 메모리가 힙에 미치는 영향을 예측하는 새로운 내부 메트릭스(metrics)를 사용하여 결정을 수행한다. 이 메트릭스는 STMM의 고급 튜닝 알고리즘과 결합하여 대부분의 경우 최초 구성부터 거의 최적의 메모리 사용에 이르기까지 한 시간 이내에 시스템을 튜닝할 수 있다. 하지만 시스템을 튜닝할 때 STMM은 수백 가지 튜닝을 결정할 수 있으며 각 결정 때문에 구성 매개변수나 버퍼 풀 크기가 변경된다. 이러한 변경 사항 중 가장 최신의 변경만 구성 파일에 반영되므로 구성 매개변수나 버퍼 풀에 대한 내역 값(historic values)을 확인하려면 db2diag.log와 STMM 로그 파일을 검사해야 한다.

db2diag.log 파일의 변경사항 모니터링

db2diag.log 파일은 메모리 매니저가 변경한 각 구성 변경사항의 간단한 정보를 저장하기 위한 저장소다. 이 파일에서 다음 Listing 1에 표시된 것과 같은 구성 변경사항을 나타내는 레코드를 볼 수 있다.

Listing 1. 구성 변경사항을 나타내는 레코드

                
2006-10-17-19.10.00.912218-240 I408210A457        LEVEL: Event
PID     : 946302               TID  : 1           PROC : db2stmm (MYDB1) 1
INSTANCE: ewhhr                NODE : 001         DB   : MYDB1
APPHDL  : 1-52                 APPID: *N1.cgarciaa.060809150048
AUTHID  : CGARCIAA
FUNCTION: DB2 UDB, config/install, sqlfLogUpdateCfgParam, probe:20
CHANGE  : STMM CFG DB DEWHR000: "Sheapthres_shr" From: "109306" <automatic>
                                                 To: "105115" <automatic>

위에서 "STMM CFG"가 있는 구성 변경사항으로 시작하는 레코드는 이 변경이 사용자가 시작한 구성 업데이트가 아니라 STMM에서 시작된 변경임을 나타낸다. Listing 2와 같이 버퍼 풀 변경사항을 나타내는 레코드도 표시된다.

Listing 2. 버퍼 풀 변경사항을 나타내는 레코드

                
2006-10-17-19.03.58.672185-240 I395047A488        LEVEL: Event
PID     : 946302               TID  : 1           PROC : db2stmm (MYDB1) 1
INSTANCE: ewhhr                NODE : 001
APPHDL  : 1-52                 APPID: *N1.cgarciaa.060809150048
AUTHID  : CGARCIAA
FUNCTION: DB2 UDB, buffer pool services, sqlbAlterBufferPoolAct, probe:90
MESSAGE : Altering bufferpool ?쏝UFFERPOOL_16K" From: ??17268" <automatic>
                                               To: ??09666" <automatic> 

이 레코드는 db2diag 도구를 사용하여 db2diag.log로부터 쉽게 필터링할 수 있다. 예를 들어 다음 명령을 사용하면 버퍼 풀 크기에 대한 모든 변경사항을 찾을 수 있다.

Listing 3. 버퍼 풀 변경사항을 찾기 위한 db2diag 명령

                
db2diag -g "message:=Altering bufferpool" db2diag.log

데이터베이스에 여러 파티션이 있으며 DB2의 데이터 파티션 기능을 사용하는 경우 각 파티션에 대한 변경사항은 -node 옵션으로 필터링할 수 있다. 예를 들어 다음 명령은 파티션 1의 모든 데이터베이스 구성 업데이트를 필터링한다.

Listing 4. 구성 변경사항을 찾기 위한 db2diag 명령

                
db2diag -node 1 -g "changeevent:=CFG DB" db2diag.log

STMM 로그

변경사항은 db2diag.log 파일의 로그 항목 외에도 STMM 로그에 더 자세하게 기록된다. 이 경우 변경사항은 db2diag.log 파일과 동일한 디렉터리인 stmmlog라는 디렉터리에 저장된다. STMM 로그는 대개 DB2 지원에서 문제를 검사하는 데 사용한다. 하지만 STMM 로그에 있는 일부 튜닝 정보는 DBA가 STMM에 의한 튜닝 결정을 이해할 수 있도록 도움을 준다. STMM 로그의 각 항목은 튜닝 결정을 하기 전에 수집된 통계와 해당 통계를 기반으로 수행된 조치를 기록한다. STMM 로그는 최대 다섯 개의 파일로 분리되며 각 파일의 최대 크기는 10MB다. 이러한 로그 파일은 순환 방식으로 유지되어 새 파일을 만들기 전에 항상 가장 오래된 파일을 삭제한다.

STMM 로그 파일 파서의 목적은 중요한 튜닝 정보를 필터링하고 포맷하여 메모리 구성의 변화를 쉽게 식별할 수 있도록 하는 것이다.

STMM 로그 파일의 구문 분석

여기에 제시된 구문 분석 도구인 parseStmmLogFile.pl의 구문은 다음과 같다.

Listing 5. parseStmmLogFile.pl 구문

                
parseStmmLogFile.pl <log file> <database name> <options>

이 도구를 실행하면 결과가 테이블 형태로 생성된다. 이 테이블의 처음 네 열은 사용자가 선택한 옵션과 관계없이 동일하다. 처음 네 열은 다음과 같다.

• 튜닝 간격 번호
• 튜닝 간격이 발생한 시간
• 로그 파일에서 첫 번째 튜닝 간격 이후 총 시간(초)
• 이전 튜닝 간격이 시작된 이래 경과한 시간(초): 이 값에는 메모리 힙의 크기를 조정하는 데 걸린 시간과 튜닝을 결정하기 위해 통계를 수집하는 데 걸린 시간이 포함된다.

Listing 6에서는 두 튜닝 간격에 대한 처음 네 열의 예를 보여 준다.

Listing 6. parseStmmLogFile.pl 샘플 결과

                
[ MEMORY TUNER - LOG ENTRIES ]
[ Interv ] [        Date         ] [ totSec ] [ secDif ]
[        ] [                     ] [        ] [        ]
[      1 ] [ 02/01/2006 09:45:02 ] [     76 ] [     76 ]
[      2 ] [ 02/01/2006 09:46:03 ] [    137 ] [     61 ]

이 도구는 선택한 옵션을 기반으로 STMM 로그 파일 전체를 구문 분석하며 지정한 옵션에 대한 특정 상세를 수집한다. 선택할 수 있는 옵션에는 다음과 같이 총 네 개가 있다.

• (s) — 각 소비자의 새 크기를 표시한다(기본 옵션).
• (m) — 각 소비자의 최소 크기를 표시한다.
• (b) — 각 소비자의 이점(benefit) 데이터를 표시한다. 이점 데이터는 각 소비자가 추가 메모리에서 얻을 수 있는 이점의 양을 나타낸다.
• (o) — DATABASE_MEMORY 튜닝 정보를 표시한다.

이외에 다음 두 가지 선택적 플래그를 사용하여 실행 결과를 수정할 수 있다. 이 플래그를 지정하는 경우 반드시 위 플래그 중 하나를 지정해야 한다.

• (4) — 모든 메모리 소비자의 페이지 크기를 4KB로 변환한다.
• (d) — 실행 결과를 세미콜론으로 분리한다. 이 옵션은 파서의 출력 내용을 스프레드시트로 입력하려는 경우 유용하다.

예 1. 힙 크기 조정 내역

이 옵션은 STMM에서 수행한 구성 매개변수와 버퍼 풀 변경사항을 표시하는 데 사용된다.

Listing 7에서는 두 튜닝 간격으로부터의 정보를 표시하는 데 parseStmmLogfile.pl 명령을 사용한다. 첫 번째 튜닝 간격은 STMM 로그 파일이 만들어지고 76초 후에 시작되었다. 또한 튜닝되고 있는 두 매개변수는 SHEAPTHRES_SHR과 PCKCACHESZ다. 두 번째 행은 61초 후에 시작된 두 번째 튜닝 간격을 표시하며 이에 따라 PCKCACHESZ에서 SHEAPTHRES_SHR로 1000페이지가 전송되었다.

Listing 7. 튜닝 간격에 대한 샘플 결과

                
$ parseStmmLogFile.pl stmm.0.log mydbname s
                      
  [ MEMORY TUNER - LOG ENTRIES ] 
  [ Interv ] [        Date         ] [ totSec ] [ secDif ] [ newSz ]
  [        ] [                     ] [        ] [        ] [ SHEAPTHRES_SHR  PCKCACHESZ ] 
  [      1 ] [ 02/01/2006 09:45:02 ] [     76 ] [     76 ] [ 31482 19438 ]       
  [      2 ] [ 02/01/2006 09:46:03 ] [    137 ] [     61 ] [ 32482 18438 ]

예 2. 데이터베이스 메모리 크기 조정 내역

다음 명령은 데이터베이스 메모리 튜닝 결정에 대한 기본 정보를 출력하는 데 사용된다. 여기에는 메모리 튜너가 확인한 시스템의 총 메모리 양(configMem), DB2가 사용할 수 있는 실제 메모리 양(memAvail), DATABASE_MEMORY 구성 매개변수를 사용하여 크기가 지정되는 데이터베이스 공유 메모리 세트의 현재 크기(setConfSz)를 나타내는 열이 포함된다.

Listing 8. database_memory 튜닝에 대한 샘플 결과

                
$ parseStmmLogFile.pl stmm.0.log mydbname o

[ MEMORY TUNER - DATABASE MEMORY AND OVERFLOW BUFFER TUNING - OG ENTRIES ]
[ Interv ][ Date                ][ totSec ][ secDif ][ configMem ][ memAvail ][ setCfgSz ]
[      1 ][ 02/01/2006 09:45:02 ][     76 ][     76 ][       N/A ][      N/A ][      N/A ]
[      2 ][ 02/01/2006 09:46:03 ][    137 ][     61 ][   4194304 ][  1559966 ][    62224 ]

예 3. SORTHEAP 크기 조정의 내역

이 명령은 SORTHEAP 구성 매개변수의 값을 튜닝하는 데 사용되는 정보의 요약을 출력하는 데 사용된다. 각 행은 SORTHEAP 값에 대한 성공적인 자동 업데이트를 나타낸다. 열에는 SORTHEAP 구성 매개변수(OLD), 현재 값(NEW), 메모리 튜너가 계산한 최소 및 최대 값(min/max)이 포함된다.

Listing 9. SORTHEAP 튜닝에 대한 샘플 결과

                
$ parseStmmLogFile.pl stmm.0.log mydbname v

[ SORTHEAP TUNING - SORTHEAP CHANGE VALIDATION RECORDS ]
[ Date                ][ totSec ][ secDif ][ SHEAPTHRES_SHR ][ OLD ][ NEW ][ min ][  max ]
[ 02/01/2006 14:51:01 ][    184 ][    184 ][          11212 ][ 373 ][ 560 ][ 224 ][ 2243 ]

힌트와 팁

• 도구를 실행할 때 지정한 데이터베이스 이름이 STMM 로그 파일에 있는지 확인한다.
• 최적의 결과를 얻으려면 결과를 쉽게 읽을 수 있도록 도구를 실행할 때 옵션을 각각 한 개(m, s나 o)만 지정한다.
• 실행할 때 옵션을 지정하지 않으면 기본적으로 새 크기나 s 옵션이 표시된다.
• 자세한 옵션 목록은 위에 표시된 것과 같은 예를 포함하여 스크립트 자체 내에 제공된다.
• 도구를 실행하려면 실행되는 시스템에 펄(Perl) 인터프리터가 설치되어 있어야 한다. 시스템에 펄 인터프리터가 없는 경우 http://www.perl.org에서 다운로드할 수 있다. 이 소프트웨어를 다운로드하여 설치하기 전에 타사 소프트웨어 사용에 대한 회사 정책을 확인해야 한다.
• 이 도구는 DBA가 자신의 특정 요구사항에 맞춰 수정할 수 있도록 펄 스크립트 언어로 개발했다. 예를 들어 내역 데이터를 구성하기 위해 기타 도구로 가져올 수 있는 다른 포맷을 사용하도록 수정할 수 있다.

법적 고지 사항

IBM은 IBM 사이트에서 참조되거나, 액세스할 수 있거나, 링크되어 있는 비IBM 웹 사이트 또는 제3자 소스에 대하여 어떠한 진술, 보증 또는 기타 확약도 제공하지 않습니다. 비IBM 웹 사이트에 대한 링크가 존재하더라도, IBM이 해당 웹 사이트의 내용을 보증하거나 해당 사이트의 사용에 대해, 또는 해당 사이트 소유주에 대한 책임이 있다는 것을 의미하지 않습니다. 또한, IBM은 귀하가 제3자와 체결할 수 있는 거래의 당사자가 아니며 해당 거래에 대한 책임이 없습니다. 귀하가 IBM 사이트로부터(또는 해당 당사자로의 링크를 통하여) 해당 당사자와 연결된 경우에도 책임이 없습니다. 또한, 귀하는 IBM이 외부 사이트 또는 소스의 이용 가능성에 대해 책임이 없고, 해당 사이트 또는 소스에서 이용할 수 있는 컨텐트, 서비스, 제품 또는 기타 자료에 대하여 책임이 없다는 점을 인정하고 동의합니다. 제3자가 제공한 소프트웨어는 해당 소프트웨어에 수반하는 제3자의 라이센스 조건에 따릅니다.

다운로드 하십시오

다운로드 방식에 대한 정보

참고자료

교육

• "Self-tuning Memory Manager Roadmap": DB2 V9 자가 튜닝 메모리 매니저에 대한 추가 정보를 확인한다.
  
  
• "Self-tuning Memory Manager Whitepaper": STMM에 대한 자세한 내용을 읽는다.
  
  
• developerWorks 정보 관리 존: DB2에 대해 학습한다. 기술 문서, 사용 방법에 대한 기사, 교육, 다운로드, 제품 정보 등을 찾아본다.
  
  
• developerWorks 기술 행사와 웹 캐스트로 최신 정보를 유지한다.
  
  

제품 및 기술 얻기

• developerWorks에서 직접 다운로드할 수 있는 IBM 평가판 소프트웨어로 다음 개발 프로젝트를 작성한다.
  
  

토론

• developerWorks 블로그에 참여하고 developerWorks 커뮤니티에서 활동한다.
  

parseStmmLogFile.pl

머리말

IBM®은 자동화 컴퓨팅 분야의 선두 주자이다. DB2 Version 8은 자가 설정(self-configuring), 자가 최적화(self-optimizing), 자가 치료(self-healing) 기능을 도입했다. DB2 9은 데이터에서 더 나은 비즈니스 가치를 이끌어내고, 관리 시간을 줄일 수 있는 전략을 지속적으로 개발하고 있다.

이 글에서는 DB2 9의 새로운 자동화(autonomic) 기능들을 소개한다. 또한 이전 글에서는 다루지 못했던 중요한 향상에 대해서도 설명한다.

자동화

새로운 DB2 9 데이터베이스는 이제 기본적으로 자가 환경설정(configuration) 및 자가 유지보수(maintaining)가 가능하다. 데이터베이스 생성 시, 메모리 관리, 스토리지 관리, 성능 튜닝, 데이터베이스 관리 플래닝에 대해 걱정할 필요가 없다. 그저, 데이터베이스를 만들어서, DB2가 모든 것을 관리하도록 하면 된다.

자가-튜닝(self-tuning) 메모리 관리 [한글] 외에도, DB2 9는 자동화와 관련하여 다음과 같이 향상되었다:

• 자동-환경 설정(디폴트)
• 자동 데이터베이스 관리
• 자동 스토리지 관리

이러한 자동화 기능은 데이터베이스 관리 수고를 덜어주고, 관리자의 생산성과 효과를 높이며, 관리 비용을 낮춘다. 이러한 기능들은 애플리케이션 개발자와 벤더들에게도 효과적이다. 데이터베이스 설정이나 전개에 신경 쓰지 않고 애플리케이션 개발에 집중할 수 있다.

디폴트로 실행되는 자동-환경설정

DB2 Version 8은 시스템과 데이터베이스 특성들(CPU, 메모리, 데이터베이스 사이즈, 테이블의 수)을 탐지하고 설정 매개변수에 값을 제시하는 Configuration Advisor를 도입했다. DB2 9은 더 나아가서 Configuration Advisor를 자동으로 실행하여, 일부 기본적인 튜닝 결정들은 기본적으로 내릴 수 있도록 하고 있다. 예를 들어, 디폴트 버퍼 풀의 크기, I/O 클리너, I/O 서버를 설정한다. 이러한 초기 자동 튜닝으로, 데이터베이스는 이전 데이터베이스 설정 디폴트 값으로 만들어진 데이터베이스 보다 더 나은 성능을 보이며, 상용 제품에서도 더욱 잘 작동하게 된다.

데이터베이스 자동 유지보수(maintenance)

단순한 유지보수 작업을 위해, DB2 9은 일부 진행 중인 태스크를 기본적으로 자동화 한다. 예를 들어, RUNSTATS 유틸리티를 주기적으로 자동 실행하여 테이블의 물리적 특성과 관련 인덱스들에 대한 통계를 업데이트 한다. DB2 옵티마이저는 이 통계를 사용하여 주어진 쿼리에 가장 효율적인 액세스 플랜을 세워, 쿼리 성능을 높인다.

또한, DB2 9에서는 자동으로 유지보수(maintenance)할 수 있는 데이터베이스를 만들거나 기존 데이터베이스에 대해서도 자동 유지보수 기능을 적용할 수 있는 그래픽 위자드를 제공한다. 이 위자드에서는 RUNSTATS 외에도, 데이터베이스 백업과 REORGs (테이블과 인덱스 데이터의 단편화 제거(defragmentation))를 자동화 한다. 자동 유지보수 기능을 사용하기 위해서는 Backup, REORG, RUNSTATS에 대해서 유지보수(maintenance) 윈도우의 사용 방식과 자동화(Automate), 통지(Notify) 옵션을 선택함으로써 활동 수준을 조절할 수 있다.(그림1. 참조)

그림 1. 자동 관리 설정하기

스토리지 관리 자동화

DB2 9은 DB2 V8.2.2에 처음 도입된 자동화 스토리지 기능을 확장했다. 자동화 스토리지는 디스크와 파일 시스템에서 데이터베이스의 크기를 자동으로 늘린다. 데이터베이스 관리 스토리지의 성능과 유연성을 활용하기 때문에, 스토리지 컨테이너를 관리할 필요가 적어진다. DB2 9에서, 자동화 스토리지는 새로운 데이터베이스를 만들면 기본적으로 실행된다. 게다가, 자동화 스토리지 지원은 멀티-파티션 데이터베이스에 추가되었다.

이러한 기능 덕택에, 용량을 만들기 위해 추가 테이블 공간을 만들고, 컨테이너를 추가하고, 컨테이너 증가를 감시하는 작업을 더 이상 신경 쓸 필요가 없다. 데이터베이스 백업을 복원하려면, (다른 디렉토리나 경로 구조를 가진)다른 시스템일 경우, 스토리지 경로를 재정의 하여 백업 이미지에 저장된 경로 대신 새로운 경로가 사용된다.

이전에는, Windows® 시스템의 경우, C에 데이터베이스를 만들 수 있었다. 이제는, C와 D에 데이터베이스를 만들 수 있고, 데이터베이스를 변경하여 E와 F 드라이브를 추가하고 특정 정책들을 사용하여 DB2가 그 공간을 관리하도록 할 수 있다. 다음 예제는 유닉스®와 리눅스® 시스템에서 자동화 스토리지의 사용법이다.

데이터베이스가 생성되면, 그 데이터베이스에서 사용될 스토리지 풀을 설정할 수 있다. 스토리지 경로가 지정되지 않으면, 기본 데이터베이스 경로(dftdbpath)가 사용된다.

CREATE DATABASE test on /data/path1, /data/path2 

나중에 추가 경로를 이 풀에 추가할 수 있다:

ALTER DATABASE ADD STORAGE /data/path3, /data/path4 

전에는, 테이블 공간을 만들면, 여기에 대한 컨테이너들을 설정해야 했다. 이제는, 자동으로 데이터베이스 스토리지 풀을 사용한다.

CREATE TABLESPACE ts1 MANAGED BY AUTOMATIC STORAGE 

스토리지 증가와 제한에 대한 정책들도 정의할 수 있다:

CREATE TABLESPACE ts2 
	INITIAL SIZE 500K
	INCREASE SIZE 100K
	MAXSIZE 100M

이러한 예제들은 자동화 스토리지의 단순함과 유연성을 단적으로 보여주고 있다.

디폴트 자동화 변경하기

DB2 9에서, 새로운 데이터베이스를 만들면, 자동 설정, RUNSTATS, 자가 튜닝 메모리, 자동 스토리지 기능들은 기본적으로 실행된다. 이 모든 것이 환경을 쉽게 설정하고 최적화 할 수 있도록 하기 위함이다. 하지만, 이러한 기능들을 직접 설정 및 튜닝하고 싶다면, DB2에서는 디폴트 자동화를 실행 불가로 하는 옵션도 제공한다. 마찬가지로, 이전 버전의 DB2에서 데이터베이스를 업그레이드 해도, 이러한 기능들이 기본적으로 실행되지 않는다. 튜닝이 잘 된 설정을 보존하고, 시스템의 신뢰도(predictability)를 보장하기 위해서이다. 새로운 자동화 기능을 활용하려면, 기존 데이터베이스에 이 새로운 자동화 기능을 정확히 실행시켜야 한다.

기타 향상점

DB2 9에는 이 글에서 모두 열거할 수 없을 정도로 많은 부분들이 향상되었다. 이 섹션에서는 새로운 버전에서 눈에 띄게 향상된 부분 몇 가지만 소개하도록 하겠다:

• 같은 시스템 상에 여러 DB2 설치 지원
• DB2 클라이언트 없이 ODBC와 CLI 애플리케이션 실행
• IPv6 지원
• 테이블 크기 제한 및 용량 증가

같은 시스템 상에 다중 DB2 설치

같은 시스템 상에 한 개 이상의 데이터 서버나 클라이언트 소프트웨어를 설치할 수 있다. 게다가:

• 어디든 설치할 수 있다: 여러분이 선택한 경로를 사용하여 DB2 데이터베이스 시스템을 설치할 수 있다.
• 여러 번 설치할 수 있다: 같은 운영 체계 이미지에 두 개 이상의 DB2 9 카피를 설치할 수 있다. 각 카피는 같은 코드 레벨(fixpack 적용 버전) 또는 다른 코드 레벨이 될 수 있다.
• 각 카피(설치본)를 독립적으로 다룬다: 다른 카피에 영향을 주지 않고 한 개의 카피만 업데이트 할 수 있다.

장점:

• 전개 독립성: 독립적인 DB2 카피들은 다른 목적과 그룹들에 사용될 수 있다. 이러한 독립성 덕택에 같은 컴퓨터에 다른 데이터베이스들이 다양한 픽스 팩 레벨에서 실행될 수 있다. 예를 들어, 인사부가 재무부에 영향을 주지 않고 픽스를 적용할 수 있다.
• 라이프-사이클 유연성: 한 버전의 DB2를 실행 환경에, 더 새로운 버전을 테스트 환경에 전개하여 새로운 픽스 팩을 테스트 한다. 제품 인스턴스는 인스턴스 별로 새로운 설치 경로로 롤오버(roll over) 될 수 있다.
• 향상된 임베딩 기능: 애플리케이션 벤더들은 자신들의 데이터 서버 소프트웨어 카피들을 임베딩 하여, DB2를 사용해야 하는 다른 애플리케이션들과는 독립적으로 실행할 수 있다.

DB2 클라이언트 없이 ODBC와 CLI 애플리케이션 실행

CLI 또는 ODBC 인터페이스를 사용하는 DB2 9 애플리케이션 런타임의 전개가 더 쉬워졌다. DB2 서버나 클라이언트 패키징과 별개로 DB2 9의 새로운 드라이버는 ODBC와 CLI를 위한 런타임 지원과 원격 연결을 제공한다.

새로운 ODBC와 CLI용 DB2 드라이버에 사용할 수 있는 다양한 설치 옵션들이 있다:

• DB2 클라이언트가 이미 설치된 머신에 드라이버를 설치할 수 있다.
• 하나의 머신에 이 드라이버를 여러 개 설치할 수 있다.

DB2 클라이언트나 서버 없이 ODBC와 CLI용 DB2 드라이버를 설치할 수 있기 때문에 데이터베이스 애플리케이션 전개가 더 쉬워진다:

• 데이터베이스 애플리케이션 설치 패키지에 드라이버를 포함시킬 수 있다.
• 배포판 크기, 설치 시 차지하는 공간이나 메모리 사용량이 줄어든다.

IPv6 지원

DB2 9은 IPv6을 지원한다. IPv6은 현재 IP (Internet Protocol) 버전(IPv4)에서 업그레이드 된 것이며, 글로벌 접근성(addressability)에 어떤 제한도 없다. IPv4에서는 사용할 수 있는 글로벌 어드레스의 수가 제한되었기 때문에 IPv6이 이를 점차적으로 대체할 것으로 보인다.

IPv4는 DB2 9의 모든 플랫폼에서 계속 지원될 것이고, 디폴트 프로토콜로 남아있게 될 것이다. 서버에서, IPv6이 설정되지 않으면, DB2는 이전 버전과 마찬가지로 모든 IPv4 어드레스들만 리스닝 한다. IPv6이 설정되면, DB2는 모든 IPv4와 IPv6 어드레스를 리스닝 한다. DB2 9.1에 IPv6을 설정하려면 새로운 CATALOG TCPIP6 NODE 명령어를 사용하여 TCPIP 노드 목록을 작성한다.

테이블 제한 및 용량 증가

DB2 9의 테이블은 “페이지크기 X 512 megabytes(Version 8에 비해 32배 증가)”까지 늘어났다. 이는 DB2 9에서 큰 Record Identifier (RID)를 지원한 결과이다. RID는 테이블 공간에 있는 객체들을 참조하는데 사용된다. 이들은 레코드가 위치한 페이지에서 페이지 수와 슬롯을 지정한다. RID가 더 커졌기 때문에, 테이블 공간에서 더 많은 페이지들이 참조될 수 있고, 페이지당 더 많은 행들, 결국 테이블 용량이 훨씬 더 증가하게 된다.

그림 2. 큰 RID 지원

RID는 DMS(database managed) 테이블 공간과 자동 스토리지로 생성된 것에는 기본이다. 비 파티션 테이블(32KB 페이지 크기 사용)은 16 테라바이트 또는 1조 1천억 행을 보유할 수 있다.

큰 RID 지원은 데이터베이스 용량을 늘리는 것 외에도, 테이블 공간 관리를 단순화 하고(통합을 통해), 스토리지와 메모리 활용을 향상시킨다.

맺음말

DB2 9은 더 단순하고, 저렴한 방식으로 데이터베이스를 관리하고, 새로운 레벨로 스케일링 하며, 개발과 전개 생산성을 높일 수 있도록 하고 있다. DB2 9을 다운로드 하여 이 새로운 기능들을 직접 체험해 보기 바란다.

기사의 원문보기

• Introducing DB2 9, Part 4: Autonomic and other enhancements in DB2 9

참고자료

교육

• DB2 Express-C
  
  
• IBM DB2 "Viper" revs XML engine InfoWorld, May 2006.
  
  
• articles about DB2 9 on developerWorks.
  
  
• 한국 developerWorks Information Management 존
  
  
• developerWorks DB2 for Linux, UNIX, and Windows resource page
  
  
• developerWorks technical events and Webcasts.
  
  

제품 및 기술 얻기

• DB2 9 다운로드
  
  
• DB2 Express-C 다운로드
  
  
• IBM 평가판 SW
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 블로그
  

머리말

데이터베이스 워크로드는 항상 변화하기 마련이다. 워크로드와 실행 환경은 증가하는 사용자들, 쿼리 패턴의 변화, 관리 태스크 실행, 다른 애플리케이션들이 사용하는 리소스의 변화와 같은 다양한 요소들 때문에 시간의 흐름에 따라 변하기 마련이다. 따라서, 숙련된 관리자가 어떤 한 시점에 시스템 튜닝을 하더라도, 또 다른 시점에는 이러한 튜닝이 최적 상태가 아니다. 변경 사항들은 (일 또는 주 단위가 아닌) 초 단위로 발생하기 때문에 관리자가 대응할 시간이 없다. 데이터베이스 메모리 설정은 이 같은 시스템 환경의 변화에 취약하고 응답 시간에 심각한 영향을 미칠 수 있다.

데이터베이스 메모리 설정을 자동으로 튜닝하고, 런타임 시 동적으로 조정하여 퍼포먼스를 최적화 하고 관리자의 생산성을 높이는, DB2 9의 새로운 자가 튜닝(self-tuning) 메모리 관리 기능을 소개한다.

작동 방법

DB2 9의 자가-튜닝 메모리 기능은 시작 시 여러 메모리 구성 매개변수에 대한 값을 자동으로 설정하여 메모리 설정 태스크를 단순화 한다. 자가 튜닝(self-tuning) 메모리 매니저는 지능형 제어와 피드백 메커니즘을 사용하여 워크로드 특성, 메모리 사용, 데이터베이스의 다양한 공유 리소스에 대한 수요 등을 지속적으로 추적하여, 필요할 때 마다 메모리 사용을 동적으로 조정한다. 예를 들어, 정렬(sort) 작업에 더 많은 메모리가 필요하고, 몇몇 버퍼풀(buffer pool)이 메모리를 초과하면, 메모리 튜너(tuner)는 초과된 버퍼 풀 메모리를 비우고 이것을 정렬 힙(sort heap)에 할당한다.

그림 1. 데이터베이스 메모리

Windows®와 AIX® 플랫폼에서, 자가 튜닝 메모리 기능은 전체적인 데이터베이스 메모리 요구량을 파악하고, 데이터베이스 메모리 사용량을 동적으로 조정한다. 이 플랫폼에서는 데이터베이스 리소스들간 메모리 활용도를 동적으로 조정하는 것 외에도, DB2는 워크로드가 메모리를 요구하는 만큼 물리적 메모리를 소비하고, 데이터베이스 메모리 요구량이 낮을 때 다른 태스크와 애플리케이션을 위해 그 메모리를 비워둔다.

자가-튜닝(self-tuning) 메모리 실행하기

메모리 자가-튜닝은 데이터베이스 공유 메모리 리소스에서 실행된다. 이 리소스에는 다음 사항들이 포함된다:

• 버퍼 풀(Buffer pools) (ALTER BUFFERPOOL과 CREATE BUFFERPOOL 문으로 제어됨)
• 패키지 캐시(Package cache) (pckcachesz 설정 매개변수에 의해 제어됨)
• 잠금 메모리(Locking memory) (locklist와 maxlocks 설정 매개변수에 의해 제어됨)
• 정렬 메모리(Sort memory) (sheapthres_shr와 sortheap 설정 매개변수에 의해 제어됨)
• 총 데이터베이스 공유 메모리(Total database shared memory) (database_memory 설정 매개변수에 의해 제어됨)

자가-튜닝(self-tuning) 메모리는 self_tuning_mem 데이터베이스 설정 매개변수를 사용하여 실행된다. DB2 9에서, 새로운 데이터를 만들 때 (파티션되지 않은 데이터베이스의 경우) 자가 튜닝(self-tuning) 메모리는 자동으로 실행된다. self_tuning_mem이 ON으로 설정되고, 위에 열거된 리소스용 데이터베이스 매개변수들이 AUTOMATIC으로 설정된다. 이전 버전의 DB2에서 마이그레이션 된 기존 데이터베이스의 경우, 자가 튜닝 메모리는 직접 실행되어야 한다. 모든 데이터베이스 메모리 리소스들을 자동으로 관리되도록 하는 대신, 원하는 메모리 리소스들(매개변수들)만 AUTOMATIC으로 설정할 수도 있다.

효용성

일반적으로, 최적의 연산을 위해 데이터베이스 메모리 매개변수를 설정하는 일은 복잡하고 시간이 많이 든다. 데이터베이스용 메모리 매개변수를 자동으로 설정함으로서, DB2 9은 데이터 서버를 설정하는 태스크를 단순화 한다. 이로서 DBA 생산성이 향상되고, 관리자는 다른 중요한 태스크에 집중할 수 있는 여유도 생긴다.

메모리 설정을 단순화 하는 것 외에도, 이 새로운 자가 튜닝 메모리 기능은 워크로드의 중요한 변경에 대해 동적이고 반응성이 뛰어난 고급 설정을 제공하여 퍼포먼스를 향상시킨다.

이러한 기능은 같은 시스템에서 여러 데이터베이스들이 실행되고 있을 때, 특정 데이터베이스가 피크 타임에 더 많은 메모리를 소비하도록 자동으로 설정하고, 다른 데이터베이스와 워크로드가 필요로 할 때를 대비하여 비워두기 때문에 이 효과적이다.

자가-튜닝(self-tuning) 메모리 수행 결과

그림 2의 그래프는 사용자의 요구에 따라 설정된 벤치마크에 대한 DB2 자가 튜닝 메모리 실행 모습이다. DB2는 자동으로 데이터베이스 공유 메모리(왼쪽 그래프)를 늘려 워크로드 요구를 충족시키고, 쿼리 처리량도 여기에 상응하여 증가세를 보인다. (오른쪽 그래프)

그림 2. 자동 튜닝이 시스템 퍼포먼스에 미치는 영향

맺음말

DB2 9의 자가-튜닝 메모리는 많은 시간을 절약하고, 메모리 튜닝을 단순화 하며, 퍼포먼스를 자동으로 최적화 할 수 있는 혁신적인 기능이다. DB2 9을 다운로드 하고 이러한 기능을 직접 경험해 보기 바란다.

기사의 원문보기

• Introducing DB2 9, Part 3: Self-tuning memory in DB2 9

참고자료

교육

• DB2 Express-C
  
  
• IBM DB2 'Viper' revs XML engine
  
  
• articles about DB2 9 on developerWorks.
  
  
• 한국 developerWorks Information Management 존
  
  
• developerWorks DB2 for Linux, UNIX, and Windows resource page
  
  
• developerWorks technical events and Webcasts
  
  

제품 및 기술 얻기

• DB2 9 다운로드
  
  
• DB2 Express-C 다운로드
  
  
• IBM 평가판 SW
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 블로그
  

머리말

대용량 데이터베이스와 테이블 관리는 어려운 일이다. 테이블 크기가 커지면, 그렇게 큰 테이블에서 전체적으로 모든 데이터를 관리하는 것보다 데이터를 몇 개의 청크(chunks) 혹은 범위를 제한하여 관리하는 것이 더 쉬운 방법이 될 수 있다. 이러한 데이터 관리 방식은 새로운 데이터의 청크(chunks)나 범위가 추가되거나 오래된 데이터가 빈번히 테이블에서 삭제될 때 특히 유용하다. (예를 들어, 데이터 웨어하우징 환경에서는 일반적인 롤인과 롤아웃 작동).

DB2 9의 테이블 (범위) 파티셔닝 기능으로 관리가 쉬워지고, 퍼포먼스가 높아지며, 대용량 데이터베이스의 확장성도 더욱 향상된다.

테이블 파티셔닝이란?

테이블 파티셔닝(종종 ‘범위 파티셔닝’이라 불리운다.)은 데이터 구성 스킴(scheme)으로서, 한 개 이상의 테이블 칼럼의 값에 따라, 테이블 데이터는 데이터 파티션이라고 하는(데이터베이스 파티션이나 DPF와 혼돈하지 않길 바란다.) 여러 스토리지 객체들로 나뉘어 진다. 이러한 스토리지 객체들은 다른 테이블 공간 또는 같은 테이블 공간, 또는 이 두 가지를 혼용하여 존재할 수 있다.

DB2 9은 다양한 애트리뷰트에 따라서 데이터 파티션이나 데이터 범위를 지원한다. 일반적으로 사용되는 파티셔닝 스킴은 날짜이다. 데이터 파티션에서 연도(year)나 달(month)별로 데이터를 묶을 수 있다. 또한 파티셔닝에는 숫자 애트리뷰트도 가능하다. 예를 들어, 1에서 백만 까지의 ID를 가진 기록들이 하나의 데이터 파티션에 저장되고, 백만에서 2백만 까지의 ID가 또 다른 데이터 파티션에 저장된다. 또는, 하나의 데이터 파티션에 A-C로 시작하는 이름을 가진 고객들을 저장하고, 두 번째 파티션에는 D-M, 세 번째 데이터 파티션에는 N-Q, 마지막 데이터 파티션에는 R-Z 등으로 저장할 수 있다.

(데이터 파티션 연산에 유용한) 이름이나 숫자로 데이터 파티션을 참조하는 옵션이 있지만, 데이터 파티션은 애플리케이션에 대해 투명하다. 다시 말해서, 애플리케이션은 칼럼과 테이블 이름을 지정하여 데이터에 액세스 할 수 있고, 데이터가 어떤 데이터 파티션에 있는지를 알 수 있다.

DB2 for Linux®, UNIX®, Windows®의 테이블 파티셔닝 기능은 DB2 for z/OS®, Informix® Dynamic Server, Informix Extended Parallel Server의 파티셔닝 기능과 비슷하다. DB2 for z/OS, DB2 for iSeries™와 DB2 for Linux, UNIX, Windows는 공통모듈을 사용하지만, 하위세트(subset)의 구현은 다르다. DB2 for Linux, UNIX, Windows는 다른 두 제품의 신택스 보다 훨씬 더 간결한 축약 신택스를 사용한다.

테이블 파티셔닝 효과

DB2 9의 테이블 파티셔닝의 효과는 다음과 같다:

• 대용량 테이블의 관리 향상
• 데이터 파티션 경감을 통한 쿼리 퍼포먼스 향상
• 빠른 온라인 데이터 롤-인 / 롤-아웃
• 스토리지 비용의 최적화
• 더 커진 테이블 용량
• 더욱 유연해진 인덱스 배치

관리 향상: DB2 9에서는 다양한 데이터 파티션들이 독립적으로 관리된다. 예를 들어, 전체 테이블 대신 개별 데이터 파티션을 백업 및 복원할 수 있다. 따라서 시간이 오래 걸리는 관리 작업을 더 작은 작업 단위로 나눌 수 있는 것이다.

쿼리 퍼포먼스 향상: DB2 옵티마이저는 데이터 파티션을 인식한다. 따라서 쿼리가 실행 중일 때 오직 관련 데이터 파티션만 스캔된다. 쿼리에 영향을 받지 않는 데이터 파티션은 스캔하지 않도록 하여 퍼포먼스를 높인다.

그림 1. 관련 파티션만 스캐닝 하기

빠른 롤-인 / 롤-아웃 : DB2 9은 데이터베이스를 끄지 않아도 테이블에서 데이터 파티션을 쉽게 추가 또는 제거할 수 있다. 이 기능은 의사 결정 지원(decision-support) 쿼리를 실행하기 위해 데이터를 자주 로딩 또는 삭제해야 하는 데이터 웨어아우스 환경에 특히 유용하게 사용된다. 어떤 보험 데이터 웨어하우스에 3년 간의 클레임 내역이 저장되어 있다고 가정해 보자. 매 달 웨어하우스로 로딩 및 롤아웃 되면서, 가장 오래된 달은 활성 테이블에서 압축 및 제거(롤아웃) 될 수 있다. 이렇게 데이터 파티션을 롤아웃 하는 방식은 delete 문 수행 log를 남길 필요가 없기 때문에 더욱 효율적이다.

스토리지 비용의 최적화: DB2 9의 테이블 파티셔닝은 계층적 스토리지 모델과 더 잘 통합된다. 가장 활성화 된 데이터 파티션에 가장 빠르고 비싼 스토리지 하드웨어를 사용하기만 해도 DB2 9은 전체 스토리지 비용을 최적화 하고 퍼포먼스를 높일 수 있다. 최근 세 달 동안의 데이터에 대해서만 대부분의 쿼리가 실행한다면, 오래된 데이터에 대해서는 좀 더 느리고 덜 비싼 스토리지 하드웨어를 할당할 수 있다.

더욱 커진 테이블 용량: 파티셔닝 없이는 스토리지 객체(테이블)가 보유할 수 있는 최대 데이터의 양이 제한된다. 하지만 테이블의 콘텐트를 여러 스토리지 객체나 데이터 파티션으로 나누고, 각각의 테이블 파티션이 파티션 되지 않은 테이블이 보유할 수 있는 데이터 만큼을 지원한다고 볼 때 가상으로는 무제한 크기의 데이터베이스를 효과적으로 만들 수 있다.

더욱 유연해진 인덱스 배치: DB2 9에서는 파티션 테이블용 인덱스들이 고유의 스토리지 객체(테이블 공간)에 저장될 수 있다. 파티션 되지 않은 테이블의 경우 같은 스토리지 객체에 저장되는 것과는 반대되는 이치이다. 이러한 인덱스 배치로 인해, 테이블에 있는 인덱스 데이터로 효율적인 동시 액세스가 가능해져서, 더욱 빠른 인덱스 연산(드롭 인덱스, 온라인 인덱스 생성, 인덱스 재구성)이 가능하고, 테이블 증가를 관리하며, I/O 경쟁을 줄일 수 있다.

테이블 파티션 생성 및 사용

DB2에서는 테이블 파티션 생성이 매우 유연하다. 예를 들어, 1년치 데이터가 있고, 이것을 날짜 별로 파티션 하여, 한 분기씩 개별 데이터 파티션에 있도록 한다. 아래 create 테이블 신택스는 이를 쉽게 수행하는 방법을 설명한다. 또한 그래픽 DB2 Control Center를 사용하여 데이터 파티션을 생성 및 관리할 수 있다.

CREATE TABLE orders(id INT, shipdate DATE, …)

  PARTITION BY RANGE(shipdate)

    (

    STARTING '1/1/2006' ENDING '12/31/2006' 

      EVERY 3 MONTHS

    )

이렇게 하면 네 개의 데이터 파티션을 가진 테이블이 만들어지고 각각 세 달치의 데이터를 갖게 된다.

그림 2. 네 개의 데이터 파티션을 가진 테이블

예제에서 설명하는 것처럼, 데이터 파티션 범위를 구체적으로 지정하고, 시작과 종료 범위를 만들고, 각 데이터 파티션에 이름을 짓는 것이 가능하다. 데이터 파티션의 네이밍은 DETACH 같은 데이터 파티션 조작을 수행하는데 유용하다.

CREATE TABLE orders(id INT, shipdate DATE, …)

  PARTITION BY RANGE(shipdate)

    (

  PARTITION 4q05 STARTING MINVALUE,

    PARTITION 1q06 STARTING '1/1/2006',

    PARTITION 2q06 STARTING '4/1/2006',

    PARTITION 3q06 STARTING '7/1/2006',

    PARTITION 4q06 STARTING '10/1/2006' 

                  ENDING ‘12/31/2006'

    )

테이블 파티셔닝을 사용하면 데이터를 동시에 롤인, 롤아웃 할 수 있다. ALTER TABLE 명령어의 ATTACH와 DETACH 옵션들은 이러한 수행을 하도록 한다. DETACH를 사용하여 기존 데이터 파티션이나 값의 범위가 별개의 테이블로 나뉜다. 롤아웃(분리된) 테이블은 드롭(삭제) 혹은 별도로 저장되거나 느린 스토리지로 옮겨질 수 있다.

마지막 예제에서 만들어진 주문 테이블에 단 1년짜리(2006) 데이터를 저장해야 할 경우도 있다. 오래된(2006년 이전) 데이터를 포함하고 있는 파티션에 DETACH 연산을 수행할 수 있다.

ALTER TABLE orders 

	DETACH PARTITION qold INTO oldorders

이와 마찬가지로, 한 테이블에 있는 새로운 데이터 파티션으로서 데이터를 붙이는(attach하는) 것(롤인) 역시 쉽다. 롤인 될 데이터는 처음 개별(스테이징) 테이블에 로딩되고 필요에 따라 변환 및 제거 과정을 거치며 이미 존재하는 테이블에 추가(attach)된다.(추가해주세요) 그 예가 아래 보여진다.

// CREATE TABLE neworders

// load / insert desired data into neworders

// transform or cleanse new data if neeeded

  ALTER TABLE orders

  	ATTACH PARTITION 1q07

  	STARTING '01/01/2007'

  	ENDING   '03/31/2007'

  	FROM TABLE neworders 

// COMMIT 

// SET INTEGRITY …

// COMMIT

롤인 된 데이터가 애플리케이션에 보이기 전에 (새로운 데이터의 유효성을 검사하고 글로벌 인덱스를 관리하기 위해) SET INTEGRITY 문의 실행으로 작업이 확약될 필요가 있다.

그림 3은 이전 예제에 사용되었던 주문 테이블의 롤-인 / 롤-아웃 데이터 모습이다.

그림 3. 데이터 파티션 롤-인 / 롤-아웃

테이블 파티셔닝과 기타 구성 스킴

DB2 9의 테이블 파티셔닝은 다른 데이터 구성 스킴들과 결합하여 사용되거나 독립적으로 사용될 수 있다. CREATE TABLE 문의 각 구절에는 데이터가 구성되는 방법을 나타내는 알고리즘이 포함되어 있다. 다음 세 개의 구문들은 조합되어 사용될 수 있는 데이터 구성 레벨이다.

• DISTRIBUTE BY -- 데이터를 공평하게 데이터베이스 파티션에 분산한다. 이 구절을 사용하여 인트라쿼리(intraquery) 병렬 처리가 가능하고 각 데이터베이스 파티션에 로드를 분산할 수 있다. 이 개념은 데이터베이스 파티셔닝으로 알려져 있고 DB2에서 Database Partitioning Feature (DPF)를 사용하여 실행한다.
• PARTITION BY -- 같은 데이터 파티션에 같은 차원의 비슷한 값으로 행(row)을 그룹핑한다. 이 개념은 테이블 파티셔닝이라고 한다.
• ORGANIZE BY -- 같은 테이블 확장에서 여러 차원에 대한 비슷한 값으로 행을 그룹핑 한다. 이 개념은 다차원 클러스터링(MDC)이라고 한다.

이 신택스를 사용하면 구절 간 일관성을 유지하는 것이 가능하고 미래의 데이터 구성 알고리즘도 가능하다. CREATE TABLE 문의 DISTRIBUTE BY와 PARTITION BY를 결합하면 데이터는 여러 테이블 공간에 걸쳐 존재하며 데이터베이스 파티션 전반으로 확대된다.

DB2 9은 데이터를 동시에 그룹핑하는 세 개의 방법을 지원하는 최초의 데이터 서버이다. 이는 데이터 관리와 정보 가용성을 향상시키는 크나큰 혁신이다.

그림 4는 서로 연결되어 사용되는 세 개의 DB2 데이터 구성 스킴이다:

그림 4. 세 개의 DB2 데이터 구성 스킴

맺음말

DB2 9의 테이블 파티셔닝은 큰 볼륨을 쉽고 빠르게 관리할 수 있는 강력한 기능을 제공한다. DB2 9을 다운로드 하여 이 글에서 설명한 기능과 기타 기능들을 직접 경험해 보기 바란다.

기사의 원문보기

• Introducing DB2 9, Part 2: Table partitioning in DB2 9

참고자료

교육

• DB2 Express-C
  
  
• DB2 Viper: Range Partitioning and Large RID support
  
  
• articles about DB2 Viper (developerWorks)
  
  
• 한국 developerWorks Information Management 존
  
  
• developerWorks DB2 for Linux, UNIX, and Windows resource page
  
  
• developerWorks technical events and webcasts
  
  

제품 및 기술 얻기

• DB2 9 다운로드
  
  
• DB2 Express-C 다운로드
  
  
• IBM 평가판 SW
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 블로그
  

머리말

디스크 스토리지 시스템들은 데이터베이스 솔루션에 있어서 가장 값비싼 부분이 되기도 한다. 큰 웨어하우스나 많은 양의 데이터를 갖고 있는 데이터베이스의 경우, 스토리지 서브시스템(subsystem)의 비용은 하드웨어 서버와 데이터 서버 소프트웨어 비용을 합친 것을 거뜬히 넘는다. 따라서 스토리지 서브시스템을 조금만 줄여도 전체적인 데이터베이스 솔루션에 상당한 비용 절감 효과를 거둘 수 있다.

행(row) 데이터를 압축하여 스토리지 요구량 줄이고, I/O 효율성을 높이며, 디스크에서 데이터로 더욱 빠르게 액세스 할 수 있는 DB2 9 (이전 코드명 "DB2 Viper") Venom 기술을 소개하고자 한다.

데이터 행(row) 압축 - 어떻게 동작하는가

DB2 9의 "Venom" 기술은 데이터 레코드를 압축할 때 알고리즘에 기반한 딕셔너리를 사용한다. DB2 9은 반복되거나 중복된 데이터가 있는 테이블을 검사하고, 그러한 반복 엔트리에 간단한 숫자 키를 할당하는 딕셔너리를 구축하여, 데이터베이스 테이블에 있는 여러 행(rows)을 압축한다. 텍스트 데이터는 앞뒤로 붙는 공백문자들이나 반복되는 문자열이 많기 때문에 압축이 잘 이루어진다.

DB2는 단순히 특정 필드나 행의 일부가 아닌, 전체 행을 검사하여 반복되는 엔트리나 패턴들이 있는지를 검사한다. 다음 예제를 보자.

Dept 칼럼에서 반복되는 값("500")이 압축되고, 그 외에도 City, State, ZipCode 칼럼에서 반복되는 패턴("Plano, TX, 24355") 역시 하나의 값으로 압축된다. 그림 1은 DB2가 정상적인 방법으로 열을 저장하는 방법과 압축 포맷으로 저장하는 방법을 비교한 것이다.

압축/비압축 검색을 위한 딕셔너리는 데이터베이스 내 비밀 객체에 저장되고, 작은 공간을 차지하며, 빠른 액세스를 위해 메모리에 캐싱된다. 아주 큰 테이블이라 할지라도 압축 딕셔너리는 대게 100 KB 정도이다. 특정 데이터 세트가 압축을 잘 못하거나 많이 압축할 수 없는 데이터 크기가 있을 수 있다. DB2는 지능형 알고리즘을 갖고 있어 이 같은 상황을 파악하고 디스크 공간 절약이라는 효용성이 없다고 판단되면 압축을 하지 않는다.

DB2 for Linux®, UNIX®, Windows®의 데이터 열 압축 기능은 DB2 for z/OS®의 기능과 비슷하다. 하지만 이것은 다른 데이터베이스 벤더들이 제공하는 페이지 레벨 압축 기술과는 다르다. 여기에서 압축 딕셔너리는 데이터베이스의 각 페이지에 대해 만들어진다. 페이지 레벨이 아닌 테이블에서 압축 딕셔너리를 만들기 때문에 전체 테이블의 패턴들이 분석되고 디스크 절약 효과도 높아지게 되는 것이다.

압축 활성화하기

DB2의 데이터 행 압축은 COMPRESS YES 옵션을 사용하여 테이블이 만들어질 때 이루어진다. 또한, ALTER TABLE 명령어를 사용하여 기존 테이블에도 이를 적용할 수 있다. 예를 들어,

CREATE TABLE Sales COMPRESS YES

또는,

ALTER TABLE Sales COMPRESS YES

압축은 테이블 딕셔너리가 생성되어야만 가능하다. 이는 대게 테이블 REORG 단계 동안 발생한다.

큰 테이블을 압축할 때 테이블과 함께 "대표" 세트나 샘플 데이터를 먼저 파퓰레이트 하는 것이 유용하다. 작은 데이터 세트를 사용하면 압축 딕셔너리를 만드는 과정은 매우 빨라질 수 있다. 올바른 대표 샘플 세트라면 테이블에 새로운 데이터가 들어올지라도 이에 대한 별도의 분석이 필요 없이 압축은 잘 적용된다. 하지만 테이블에 저장된 데이터 유형이 여러 번 변화하면 딕셔너리는 REORG를 사용하여 최신 데이터를 반영한다.

압축률 추정하기

DB2에서는 특정 테이블이나 데이터 세트의 압축에 대한 판단을 위해 압축 비율을 추정할 수 있는 INSPECT를 제공한다. 이 툴은 테이블 데이터 샘플을 모아서 압축 딕셔너리를 만든다. 이 딕셔너리는 샘플에 포함된 레코드에 대한 압축률을 테스트할 때 사용된다. 이러한 테스트를 통해서 압축률이 추정된다.

INSPECT ROWCOMPESTIMATE TABLE NAME Sales … 

		RESULTS KEEP <filename>

	

db2inspf <filename> <outfile>

결과를 보려면 INSPECT의 아웃풋을 DB2 유틸리티를 사용하여 포맷해야 한다. 파일은 db2dump 디렉토리에 있다. 샘플 아웃풋은 아래 내용을 참조하라.

  DATABASE: TEST  

  VERSION : SQL09010 

  2005-12-01-13.12.21.232959



  Action: ROWCOMPESTIMATE TABLE

  Schema name: RSAHUJA 

  Table name: Sales 

  ... 

      Percentage of bytes saved from compression: 66 

      Compression dictionary size: 2176 bytes. 

  ... 

데이터 열 압축의 효용성

"Venom" 압축 기술은, 데이터 저장에 필요한 디스크 공간 (그리고 디스크 하위 시스템 주변장치)을 줄여서 스토리지 비용을 50% 이상 절약할 수 있다. 로그 레코드 내에서 DB2가 사용자 데이터를 압축하기 때문에 데이터베이스 로그 크기도 줄어든다.

어떤 경우에는 퍼포먼스까지 높인다. 압축/비압축이 CPU 오버헤드를 야기하긴 하지만, 어떤 상황에서는 퍼포먼스를 높이기도 한다. 디스크에 존재하는 데이터에 액세스 하는 것은 가장 더딘 데이터베이스 작동이라 할 수 있다. 압축된 데이터를 디스크에 저장하여, 더 적은 I/O 연산으로 같은 양의 데이터를 가져오거나 저장한다. 따라서 디스크 I/O 중심의 워크로드의 경우(디스크에 존재하는 데이터에 액세스 되기를 기다리거나 유휴상태일 때) 쿼리 처리 시간이 매우 빨라진다.

더욱이 DB2는 디스크와 메모리(DB2 버퍼 풀)에 압축된 데이터를 저장하기 때문에 사용된 메모리 양이 줄어들고, 다른 데이터베이스나 시스템 작동을 위한 여유 공간이 남는다. 이로서 쿼리나 다른 연산에 대해 데이터베이스 퍼포먼스는 더욱더 높아지는 것이다.

샘플 결과

DB2의 데이터 열 압축 기능을 사용했을 때 어느 만큼의 공간이 절약되는지는 데이터 마다 다르다. DB2 9 베타 버전을 사용하는 사람들은 50% 이상을 절약했다고 하고, 어떤 대형 데이터베이스의 경우 80%까지 절약했다고도 한다. 어떤 데이터 세트의 경우 32KB 페이지를 사용한 179.9GB 테이블은 42.5GB로 줄어들었다. 76.4%나 절약된 것이다.

다음 차트는 다른 테이블에서 DB2 데이터 열 압축 기능을 사용했을 때 어느 만큼의 공간 절약 효과를 거두었는지를 보여주는 예제이다.

InfoWorld의 Sean McCown은 다음과 같이 설명한다.

"새로운 압축 방식은 데이터 유형에 따라 평균 45%에서 75% 정도의 스토리지 절약 효과를 거두고 있다. 이를 테스트 하기 위해 숫자와 텍스트 데이터가 혼합된 40GB 테이블 (약 5억 줄)을 만들어서 이것을 압축된 테이블 포맷으로 반출했다. 압축된 테이블의 크기는 약 17.75GB가 되었다. 56%나 줄어든 것이다."

자세한 내용은 참고자료 섹션을 참조하라.

DB2의 다른 압축 형태

"Venom" 기술의 일부인 데이터 열 압축 외에도 DB2는 스토리지 요구 사항을 더욱 줄일 수 있는 다른 방식들도 제공한다.

• NULL 값과 디폴트 값 압축
• 데이터베이스 백업 압축
• XML 태그 대체
• 다차원 클러스터링

NULL 값과 디폴트 값 압축

DB2 for Linux, UNIX, and Windows, Version 8부터는, NULL 값, 길이가 0인 데이터, 시스템 디폴트 값에 스토리지가 사용되지 않는다.

데이터베이스 백업 압축

DB2 for Linux, UNIX, and Windows V8의 Fixpak 4 이후부터 이러한 압축 기능은 더 작은 백업 이미지를 만들어 백업 스토리지 요구량을 줄일 뿐만 아니라 시스템 간 백업도 이동하기가 더욱 쉬워졌다.

XML 태그 대체

XML의 장황한 특성 상 XML 조각과 문서들은 많은 디스크 공간을 소비하기 마련이다. DB2 9은 파싱된 계층형 포맷으로 XML 데이터를 저장하고 태그 이름(가령, employee)을 정수 값(4와 같은)으로 바꾼다. 반복되는 태그에는 같은 숫자 값이 할당된다. 정수 값을 사용하여 텍스트 태그를 저장하면 공간 소비율을 줄일 뿐만 아니라 데이터를 쿼리 할 때도 높은 퍼포먼스를 누릴 수 있다. 더욱이 데이터 행 압축 같은 XML 태그 파싱(정수 값으로 대체하기)은 별도로(사용자가 신경 쓸 필요 없이) 수행되고 사용자와 애플리케이션에 완전히 투명하다.

다차원 클러스터링

인덱스 압축 형태도 V8.1부터는 가능해졌다. 블록 인덱스를 통해서 인덱스 공간이 상당히 많이 절약된다. 이곳에서는 수 천 개의 레코드에 하나의 키(인덱스 엔트리)가 사용된다. (레코드 당 하나의 키가 아니다.)

결론

DB2 9의 데이터 열 압축은 디스크 공간과 스토리지 비용을 많이 줄일 수 있는 혁신적인 신기능이라 할 수 있다. DB2 9을 다운로드 하여 직접 경험해 보기 바란다.

기사의 원문보기

• Introducing DB2 9, Part 1: Data compression in DB2 9

참고자료

교육

• DB2 Express-C
  
  
• IBM DB2 "Viper" revs XML engine InfoWorld
  
  
• DB2 9 관련 기술자료
  
  
• 한국 developerWorks Information Management 존
  
  
• developerWorks DB2 for Linux, UNIX, and Windows resource page
  
  
• developerWorks technical events and Webcasts
  
  

제품 및 기술 얻기

• DB2 9 다운로드
  
  
• DB2 Express-C 다운로드
  
  
• IBM trial software
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 블로그