IBM DB2 UDB Blog Center

pureScale에 구성된 인스턴스 상태를 보기 위해서 db2instance –list 를 수행하면 진단로그에 다음과 같은 메시지가 기록된다.

위의 메시지는 DB2 V10.1 FixPack0 에서 발생하였고, 고객사 환경에서만 나오는 메시지였다.

IBM LAB에서는 다음과 같은 답변을 주었다.

V10.1 FixPack1 에서 위의 메시지는 “Error”에서 “Info”로 변경되었으며, 위의 메시지는 무시해도 되는 메시지로확인되었다.

소개

메모리 튜너는 활성화되면 정렬 힙(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 블로그