DB2 튜닝 가이드 Part 2: 최상의 성능을 위한 DB 구성(1)

대부분의 DB2 시스템은 ' 성능 전개 (performance evolution)' 과정을 거친다 . 시스템을 배포한 후 시스템 모니터링을 하고 , 만약 문제점이 발생되면 문제해결 과정을 거친다 . DB2 튜닝 가이드는 단계별로 최상의 성능을 위한 최적의 설정을 제시함으로써 , DB2 시스템 성능이 최상을 유지하도록 도와준다 . 이번 회는 DB2 튜닝 가이드 중 최상의 성능을 위한 DB 구성 첫 번째로 DB2 데이터 분할 (DPF), 코드 페이지와 데이터 정렬 선택 , 물리적 데이터베이스 디자인 , 초기 DB2 구성 설정 등을 알아본다 .<연재순서 >
DB2 튜닝 가이드 Part 1: 최상의 성능을 위한 시스템 구성
DB2 튜닝 가이드 Part 2: 최상의 성능을 위한 DB 구성 (1)

DB2 데이터 분할 기능 (DPF)

DB2 데이터 분할 기능 (DPF; Data Partitioning Feature) 사용에 대한 결정은 데이터 볼륨뿐만 아니라 워크로드를 기준으로 이뤄진다 . 일반적으로 DPF 배포는 데이터 웨어하우징과 비즈니스 인텔리전스 영역이다 . DPF 는 shared-nothing 아키텍처를 활용함으로써 확장성을 제공하기 때문에 주로 복잡한 쿼리 환경에 권장된다 . 빠르게 성장하는 소규모 데이터 마트 ( 약 300GB) 의 경우 DB2 Enterprise Server Edition(ESE) 구성을 사용한다 . 그러나 대형 또는 BI 환경에서는 DPF 를 활용함으로써 다양한 혜택을 얻을 수 있다 .본 글에서 분할된 데이터베이스 시스템 디자인을 설명하는 것은 범위를 벗어나지만 , CPU 파티션 ( CPU-to-partitio n) 에 대해서 설명한다 .분할된 데이터베이스 시스템에는 데이터 파티션 당 한 개의 프로세서 코어가 있다 . 예를 들어 , N 개의 프로세서 코어가 있는 시스템에는 파티션 0 에 카탈로그가 있고 N 개의 추가 데이터 파티션이 있다 . 만약 카탈로그 파티셔닝을 크게 사용한다면 ( 단일 파티션 테이블처럼 ) 프로세스 코어를 할당할 필요가 있다 . 시스템이 동시에 수많은 사용자들을 지원하는 경우 , 파티션당 두 개의 코어가 필요하다 . 일반적으로 파티션당 약 250GB 의 활성 원시 데이터 (raw data) 를 예상해야 한다 .분할된 데이터베이스 구성에 대한 자세한 정보는 ‘InfoSphere Balanced Warehouse(http://www-01.ibm.com/software/data/infosphere/balanced-warehouse/)' 를 참고하면 된다 . 이 문서에는 non-Balanced Warehouse 배포에 대한 다양한 정보도 있다 .

코드 페이지와 데이터 정렬 선택

코드 페이지 또는 코드 세트와 데이터 정렬 시퀀스의 선택은 데이터베이스 작동 (behavior) 뿐만 아니라 성능에도 큰 영향을 미친다 . 이 측면에서 유니코드가 오랫동안 사용되고 있다 . 유니코드는 기존의 단일 바이트 코드 페이지를 사용한 것보다 더 다양한 문자열을 표시할 수 있기 때문이다 .유니코드는 DB2 9.5 버전에 기본값으로 설정되어 있으며 , 새로운 특징 중 하나이다 . 그러나 유니코드 세트는 일부 개별 문자 표시를 위해 멀티바이트를 사용하기 때문에 디스크와 메모리에 대한 요구사항이 증가된다 . 예를 들어 , 유니코드 세트에서 가장 일반적인 코드 세트 중 하나인 UTF-8 코드 세트는 문자당 1 바이트에서 4 바이트까지 사용한다 . 단일 바이트 코드 세트에서 UTF-8 로의 변환으로 평균 문자열 확장 요소는 예측하기 어렵다 . 멀티바이트 문자가 사용되는 빈도에 따라 다르기 때문이다 .유니코드는 단일 바이트 코드 페이지에 비해 상대적으로 추가적인 CPU 소비를 발생시킨다 . 우선 , 확장이 일어나면 보다 긴 문자열을 처리하기 위해 더 많은 작업을 해야 한다 . 둘째 , 더욱 정교한 유니코드 데이터 정렬 시퀀스를 사용하는 UCA500R1_NO 같은 알고리즘은 단일 바이트 코드 페이지에 사용되는 일반적인 시스템 데이터 정렬보다 훨씬 더 부담 (expensive) 이 된다 . 이렇게 부담이 증가되는 이유는 정확한 방향으로 유니코드를 정렬하는 복잡성 때문이다 . 정렬 , 문자열 비교 , LIKE 처리 그리고 인덱스 생성 등이 복잡한 작업에 영향을 미친다 .데이터를 올바르게 표현하기 위해 유니코드가 필요하다면 , 데이터 정렬 시퀀스를 신중하게 선택해야 한다 .

데이터베이스에 다중 언어로 된 데이터가 포함되고 , 해당 데이터의 올바른 정렬 순서가 중요하다면 , UCA500R1_xxx 같은 정확한 데이터 정렬 중 하나를 사용한다 . 이러한 데이터 정렬은 데이터와 애플리케이션에 따라 IDENTITY 시퀀스에 비해 1.5~3 배 가량의 성능 오버헤드를 발생시킬 수 있다 . 정확한 데이터 정렬에는 표준화와 비표준화된 방식 모두 갖고 있다 . UCA500R1_NO 같은 표준화된 데이터 정렬은 잘못된 문자를 처리하는 추가 검사가 있는 반면 , UCA500r1_NX 같은 표준화 되지 않은 데이터 정렬에는 추가 검사가 없다 . 잘못된 문자의 처리가 문제가 되지 않는다면 , 표준화 코드 방지로 인한 성능상의 이점을 위해 표준화 되지 않은 버전을 사용한 것이 좋다 . 표준화되어 있지 않으며 문화적으로 올바른 데이터 정렬은 매우 부담 ( expensive ) 이 된다 . 데이터베이스가 다양한 언어를 호스팅하지 않고도 단일 바이트 환경에서 유니코드 환경으로 변환하는 경우 , ‘ 언어 인식 (language aware)' 데이터 정렬을 사용한다 . 언어 인식 데이터 정렬은 대부분의 유니코드 데이터베이스에 한 가지 언어로만 된 데이터를 포함한다 . 이 데이터 정렬은 SYSTEM_819_BE 와 같은 단일 바이트 데이터 정렬로 , 동일한 조회 테이블 기반 데이터 정렬 알고리즘을 사용하기 때문에 매우 효율적이다 . 일반적으로 단일 바이트 데이터베이스의 데이터 정렬 동작이 허용되는 경우 , 언어 콘텐츠가 유니코드로 변환되면서 심각한 변화가 없는 한 문화적으로 인식 가능한 데이터 정렬을 고려한다 . 이 데이터 정렬은 문화적으로 올바른 데이터 정렬보다 현저히 높은 성능을 제공한다 .

물리적 데이터베이스 디자인

물리적 데이터베이스 디자인에 대한 자세한 설명은 ‘ 물리적 데이터베이스 디자인( http://www.ibm.com/developerworks/data/bestpractices/ )' 을 참고하면 된다 .

일반적으로 파일 기반의 데이터베이스 관리 스토리지 (Database Managed Storage) 정규 테이블 스페이스는 시스템 관리 스토리지 (System Managed Storage) 정규 테이블 스페이스보다 더 나은 성능을 제공한다 . 임시 테이블이 아주 작은 경우에 SMS 는 주로 임시 테이블 스페이스에 사용된다 . 그러나 이 경우 시간이 지남에 따라 SMS 의 성능 이점은 줄어든다 . 과거에는 DMS 원시 장치 (raw device) 테이블 스페이스는 DMS 파일 테이블 스페이스 보다 상당히 많은 성능 이점이 있었다 . 그러나 직접적인 I/O 가 도입된 DMS 파일테이블 스페이스는 DMS 원시 장치 (raw device) 테이블 스페이스와 같은 성능을 제공한다 . I/O 는 현재 CREATE TABLESPACE 와 ALTER TABLESPACE, ALTER TABLESPACE 구문의 NO FILE SYSTEM CACHING 절에 기본값으로 설정되었다 .

초기 DB2 구성 설정

AUTOCONFIGURE 명령문으로도 알려진 ‘DB2 구성 관리자 (DB2 Configration advisor;http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsptopic=/com.ibm.db2.luw.admin.cmd.doc/doc/r0008960.html) 는 제공되는 기본적인 시스템 지침을 받아 DB2 구성 값에 대한 적절한 시작점을 결정한다 . AUTOCONFIGURE 명령문은 기본 구성 설정보다 더 많은 향상을 제공한다 . AUTOCONFIGURE 명령문은 초기 구성 값을 얻기 위한 방법으로 사용할 것을 권장한다 . AUTOCONFIGURE 명령문에 의해 생성된 권장사항은 시스템의 특성에 따라 일부 추가 조정이 필요한 경우가 있다 .다음은 AUTOCONFIGURE 명령문 사용에 대한 몇 가지 제안사항이다 .

DB2 9.1 버전부터 데이터베이스를 생성할 때 , AUTOCONFIGURE 명령문이 자동으로 실행되지만 AUTOCONFIGURE 명령문은 여전히 명시적 으로 실행하는 것이 더 좋다 . 왜냐하면 시스템에 대한 결과를 조정할 수 있는 키워드 / 값 쌍 (pair) 을 지정할 수 있기 때문이다 . 데이터베이스를 채운 다음 AUTOCONFIGURE 명령문을 실행한다 . 이렇게 하면 데이터베이스 특성에 대해 더 많은 정보를 가진 도구를 제공하다 . 원칙적으로 ‘ 채움 (populated)' 은 상당한 양의 활성 데이터 (active data) 를 의미한다 . 이러한 데이터는 버퍼 풀 크기 계산에 영향을 미친다 . 데이터가 너무 많거나 적어도 계산의 정확도는 떨어진다 . mem_percent, tpm 와 num_stmts 같은 주요 AUTOCONFIGURE 명령문 키워드 등에 대해 다른 값을 시도하여 이러한 변경으로 인해 어떤 구성 값이 어느 정도 영향을 받는지 알아 본다 . 다른 키워드나 값을 사용해 보는 경우 apply none 옵션을 사용한다 . 이렇게 하면 현재 설정된 값과 권장되는 값을 비교해 볼 수 있다 . 기본값이 시스템에 적절하지 않을 수 있기 때문에 모든 키워드에 대해 값을 지정한다 . 예를 들어 mem_percent 기본값을 25% 으로 지정하면 전용 DB2 서버의 경우 너무 낮은 값이 된다 . 이 경우 85% 를 지정해야 한다 .

필자소개

Steve Rees:DB2 성능 품질관리 선임 매니저
Thomas Rech:DB2 SAP Center of Excellence 선임 컨설턴트
Gang Shen:IBM Data Servers 기술 영업 전문가
Roman B. Melnyk:DB2 Information Development출처 : KDUG (http://www.kdug.kr/)제공 : DB포탈사이트 DBguide.net