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

대부분의 DB2 시스템은 '성능 전개(performance evolution)' 과정을 거친다. 시스템을 배포한 후 시스템 모니터링을 하고, 만약 문제점이 발생되면 문제해결 과정을 거친다. DB2 튜닝 가이드는 단계별로 최상의 성능을 위한 최적의 설정을 제시함으로써, DB2 시스템 성능이 최상을 유지하도록 도와준다. 이번 회는 지난 회에 이어DB2 튜닝 가이드 중 최상의 성능을 위한 DB 구성에 대해 DB2 자율/자동 매개변수, 명시적 구성 설정, 통계수집, SAP와 다른 ISV 환경에 대한 고려사항 등을 중심으로 살펴본다.<연재순서> DB2 튜닝 가이드 Part 1: 최상의 성능을 위한 시스템 구성
DB2 튜닝 가이드 Part 2: 최상의 성능을 위한 DB 구성(1)
DB2 튜닝 가이드 Part 3: 최상의 성능을 위한 DB 구성(2)

DB2 자율(autonomics) / 자동(automatic) 매개변수

최근 출시된 DB2 데이터베이스 제품들은 매개변수의 수가 많이 증가 되었다. 데이터베이스 시작과 동시에 자동으로 설정되거나 작업(Operation) 도중 동적으로 조정되는 매개변수들이다. 대부분의 시스템에서 자동 설정은 수동으로 조정하는 시스템보다 더 나은 성능을 제공한다. 이것은 DB2 시스템의 4개의 메인 메모리 소비자(consumer)뿐만 아니라 전체적인 데이터베이스 메모리 할당을 동적으로 조정하는 DB2 자가 튜닝 메모리 매니저(Self-Tuning Memory Manager; STMM) 때문이다. 여기서 4개의 메인 메모리 소비자는 버퍼 풀, 잠금 목록, 패키지 캐시 그리고 정렬 힙(heap)이다.이러한 매개변수는 분할된 데이터베이스 환경에서 STMM을 사용하여 각각의 파티션을 기준으로 적용되기 때문에 주의해야 한다. 분할된 데이터베이스 시스템에서 STMM은 단일 파티션에 대한 메모리 요구사항을 계속 측정하여 STMM이 활성화된 모든 파티션에 힙 사이즈(heap size) 업데이트를 ‘밀어 낸다(pushes out)'.전체 파티션에서 같은 값이 사용되기 때문에 STMM은 많은 양의 데이터, 메모리 요구사항 그리고 활동의 일반적인 레벨이 전 파티션에 걸쳐 매우 균등하게 분할된 데이터베이스 환경에서 가장 잘 수행된다. 몇몇 파티션의 데이터 볼륨이 일치하지 않거나 메모리 요구사항이 다른 경우 해당 파티션에서 STMM을 비활성화함으로써 보다 균등한 값으로 조정할 수 있다. 예를 들어 카탈로그 파티션에서는 일반적으로 STMM을 비활성화해야 한다.데이터 배포가 일치되지 않는 분할된 데이터베이스 환경에서 지속적인 상호 클러스터 메모리 튜닝이 통지(advise)되지 않는 경우 ‘튜닝 단계' 동안 최상의 수동 힙 설정 값을 결정할 수 있도록 STMM을 선택적 혹은 임시로 사용할 수 있다.

한 개의 ‘일반(typical)' 파티션에는 STMM을 활성화하고, 다른 파티션에는 STMM을 계속 비활성화 상태로 둔다.
메모리 설정이 안정된 후 STMM을 비활성화시키고 영향을 받은 매개변수를 수동으로 값을 고정시킨다.
조정된 값을 유사한 데이터 볼륨과 메모리 요구사항이 있는 다른 데이터베이스 파티션(예를 들면, 같은 파티션 그룹 내 파티션)에 배포한다.
유사한 볼륨과 데이터 유형이 포함되어 있고 시스템에서 유사한 역할을 수행하는 데이터베이스 파티션의 해체된 파티션이 여러 개 있으면 이 과정을 반복한다.

구성 관리자는 일반적으로 적용 가능한 경우 자율 설정을 활성화하도록 선택한다. 여기에는 RUNSTATS 명령문에서 가져온 유용한 자동 통계 업데이트가 포함되지만 자동 재구성과 자동 백업은 제외된다. 이들도 유용할 수 있지만 최상의 결과를 얻기 위해서는 환경에 따라 구성하고 예약해야 한다.자동 통계 프로파일링은 기본적으로 비활성화 상태이다. 이 기능은 오버헤드가 매우 크며 주로 제어된 상황에서 복잡한 구문을 사용하여 일시적으로 사용한다.

명시적 구성 설정

일부 매개변수에는 자동 설정값이 없으며 구성 관리자에 의해 설정되지도 않는다. 이러한 매개변수는 명시적으로 처리해야 한다. 이때 성능과 관련 있는 매개변수만을 고려해야 한다.

logpath 또는 newlogpath는 트랜잭션 로그의 위치를 지정한다. 구성 관리자(configuration advisor)는 로그가 어디로 가야 하는지 결정할 수 없다. 위에서 언급한 것처럼 다른 DB2 개체와 디스크 장치를 공유하거나 데이터베이스 경로 하에 있는 기본 위치에 남아 있으면 안 된다.
기본적으로 트랜잭션 로그는 병목 상태를 만들지 않도록 충분한 처리 용량이 있는 전용 스토리지에 보관한다. logbufsz는 트랜잭션 로거(logger) 내부 버퍼의 크기를 4KB 페이지로 지정한다. 기본 값은 8개 페이지이다. 그러나 이 값은 프로덕션 환경에서 좋은 성능을 내기에는 작은 값이다. 구성 관리자는 이 값을 늘리지만 입력 매개변수에 따라 충분하지 않을 수 있다.
일반적으로 256~1000페이지가 적당하며, 이 값은 데이터베이스 서버의 전체 스키마에서 매우 적은 총 메모리 양만을 나타낸다. mincommit은 ‘그룹 커밋(group commit')'을 제어한다. 그룹 커밋은 커밋중인 트랜잭션 N개를 한꺼번에 일괄 처리하기 위해 DB2 시스템에 영향을 준다. 현재는 트랜잭션 로거(logger) 디자인을 사용함으로써 그룹 커밋을 더 이상 하지 않는다. mincommit은 기본값은 1로 설정한다. buffpage는 -1 크기로 정의된 각 버퍼 풀에 할당된 페이지 수를 지정한다. buffpage는 무시(ignore)하는 것이좋으며 SYSCAT.BUFFERPOOLS에 항목이 있는 버퍼 풀 크기를 명시적으로 설정하거나 STMM에서 자동으로 버퍼 풀 크기를 조정한다. diagpath는 다양하고 유용한 DB2 진단 파일의 위치를 지정한다. 일반적으로 이 매개변수는 분할된 데이터베이스 환경을 제외하고 성능에 미치는 영향은 적다. 전체 파티션에서 diagpath의 기본 위치는 일반적으로 NFS 마운트(mounted)된 공유 경로이다.
각 파티션에 대한 diagpath를 NFS가 아닌 로컬 디렉터리로 다시 정의해야 한다. 그래야 전체 파티션이 같은 파일을 진단 메시지로 업데이트하려는 것을 방지할 수 있기 때문이다. 대신 이러한 메시지는 각 파티션에 로컬로 저장되며 따라서 컨텐션(contention)이 현저하게 감소된다. DB2_PARALLEL_IO는 구성 매개변수가 아니라 DB2 레지스트리 변수다. DB2 시스템은 일반적으로 운영 체제에 단일 장치로 나타나는 디스크 어레이로 이루어진 스토리지를 사용하거나 여러 장치에 걸쳐 있는 파일 시스템을 사용한다.

따라서 DB2 데이터베이스 시스템은 기본적으로 테이블 스페이스 컨테이너에 대해 한 번에 한 개의 프리페치(prefetch) 요청을 처리한다. 이것은 단일 장치에 대해 여러 요청이 어떻게든 직렬화(serialize)되는 것을 이해함으로써 수행된다.그러나 컨테이너가 디스크 어레이에 있는 경우에는 직렬화하지 않고 동시에 여러 프리페치 요청을 해당 장치에 디스패치할 수 있다. 이 경우 DB2_RAPALLEL_IO 변수가 필요하다. 이 변수는 프리페치 요청이 단일 컨테이너에 병렬로 요청될 수 있다는 것을 DB2 시스템에 알린다.가장 간단한 설정 방법은 DB2_PARALLEL_IO=*이다. 이는 모든 컨테이너가 여러 디스크에 있다는 것을 의미한다. 그러나 다른 설정도 병렬 처리(parallelism) 정도와 영향을 받는 테이블 스페이스를 제어한다. 예를 들어 컨테이너가 네 개의 디스크로 된 RAID-5 어레이에 있는 경우 DB2_PARALLEL_IO를 ‘*:3'으로 설정할 수 있다. 또한 특정 값이 성능 혜택을 주는지 여부는 확장 크기, RAID 세그먼트 크기, 같은 디스크 세트를 사용하는 컨테이너 개수에 따라 다르다.

통계 수집

특별히 복잡한 쿼리 환경에서 최상의 SQL 성능을 얻으려면 올바른 통계 자료를 수집하는 것이 가장 중요하다.

SAP와 다른 ISV 환경에 대한 고려사항

SAP와 같은 ISV 애플리케이션에서 DB2 데이터베이스 서버를 실행하는 경우 특정 애플리케이션을 고려한 우수 사례 가이드라인을 사용할 수 있다. 가장 간단한 방법은 DB2 레지스트리 변수인 DB2_WORKLOAD에 SAP 값을 설정하는 것이다. 이 방법은 SAP 워크로드에 최적화된 전체 레지스트리 변수를 활성화시킨다. 또 다른 권장사항과 우수사례를 적용할 수 있다. 코드 페이지/코드 세트와 데이터 정렬 시퀀스 선택 등이 그 예이다.코드 페이지/코드 세트와 데이터 정렬 시퀀스 선택과 같은 기타 권장 사항 및 우수 사례의 경우 미리 지정된 값으로 설정해야 하므로 이들을 적용할 수도 있다. 자세한 내용은 애플리케이션 공급업체의 설명서를 참조한다.SAP Business One과 같은 많은 ISV 애플리케이션의 경우 AUTOCONFIGURE 명령문을 사용하여 초기 구성을 정의한다. 그러나 DB2 구성 매개변수의 초기 세트가 SAP가 설치되는 동안 DB2 구성 매개변수의 초기 세트가 적용되기 때문에, SAP NetWeaver를 설치할 때 AUTOCONFIGURE 명령문을 사용하면 안 된다. 또한 SAP는 기본 DB2 매개변수 설정이 기술된 SAP Notes와 함께 대체 우수 사례 방법 등이 있다. SAP Note 1086130 DB6: DB2 Standard Parameter Settings 등이 그 예이다.DB2 DPF 기능을 사용할 때는 SAP 애플리케이션에 특히 주목해야 한다. SAP은 주로 SAP NetWeaver Business Intelligence(Business Warehouse) 제품에서 DPF를 사용한다. 권장되는 레이아웃은 파티션 0의 SAP 기본 테이블 외에도 DB2 시스템 카탈로그, 차원(dimension) 마스터 테이블을 갖는다. 이렇게 하면 다른 DB2 DPF 설치와 비교하여 해당 파티션의 다른 워크로드로 이어진다.SAP 애플리케이션 서버가 이 파티션에서 실행되기 때문에, 이 파티션에 최대 8개의 프로세서가 할당된다. SAP BW 워크로드는 보다 고도로 병렬화되어 있어 짧은 쿼리는 동시 수행이 가능하기 때문에, SAP BI에 대한 파티션 수가 다른 애플리케이션에 비해 일반적으로 적다. 즉 데이터 파티션당 하나 이상의 CPU가 필요하다.DB2와 SAP의 초기 설정에 대한 자세한 내용은 SAP Service Marketplace(service.sap.com) 또는 ‘SAP 개발자 네트워크(https://www.sdn.sap.com/irj/sdn/db6)에서 확인할 수 있다.

필자소개

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