구성 매개변수 성능 조정

인스턴스와 데이터베이스를 작성한 후에, 모든 구성 매개변수들은 기본값을 가지게 된다. 이 기본값들은 작은 데이터베이스와 메모리를 위해 설정되어 있으므로, OLTP업무나 DSS 업무 등 각각의 업무의 특성에 맞게 설정되어야 최적의 성능을 낼 수 있다. 데이터베이스 성능에 중요한 영향을 주는 매개변수로는 데이터베이스 관리자(DBM) 매개변수, 데이터베이스(DB) 매개변수, 환경 매개변수 세가지로 분류된다.

데이터베이스 관리자 매개변수

데이터베이스 관리자 구성 매개변수는 전체 인스턴스와 관련되어 있고, 데이터베이스 서버와 클라이언트 모두에 상주한다. 하지만 클라이언트에서는 몇가지의 매개변수만이 사용가능 하다.

데이터베이스 관리자 구성 매개변수는 db2systm이라고 하는 파일에 저장된다. 이것은 db2 인스턴스 생성시에 만들어지고, $HOME/sqllib 디렉토리에 위치한다. 이 파일은 직접 변경할 수 없다. 데이터베이스 관리자의 구성 매개변수를 변경한 후, 데이터베이스 관리자는 반드시 중지시키고 변경이 적용되도록 재시작해야 한다.

데이터베이스 매개변수

이 매개변수는 데이터베이스 서버에만 위치하고 각각의 데이터베이스에 개별적으로 할당된다. 정보는 디렉토리 SQLnnnnn (nnnnn는 데이터베이스가 생성될 때 부여받은 숫자임) 하위에 위치한 파일 SQLDBCON에 저장된다. 직접 편집할 수 없다.

데이터베이스 구성 매개변수 변경은 응용프로그램이나 사용자가 데이터베이스에 연결된 동안에는 효력이 없다. 모든 응용프로그램의 종료와 재 연결후에 변경이 적용된다. 만약 데이터베이스가 활성화(Activate) 상태에 있다면, 반드시 비활성화(Deactivate)되어야 한다.

DB2 레지스트리 변수

데이터베이스 관리자와 데이터베이스 구성 매개변수와는 별도로 DB2 프로파일 레지스트리에 저장하는, DB2는 환경 변수들의 집합을 제공한다. db2set 명령어는 데이터베이스 관리자가 프로파일 변수들을 조회, 설정, 제거하기 위해 사용된다.

매개변수의 값을 보는 명령어는 db2 GET DBM CFG와 db2 GET DB CFG FOR DB명 을 이용해서 확인할수 있고, 값을 변경하기 위해서는 다음과 같이 명령어를 사용한다.

버퍼 풀 크기 (BUFFPAGE)

버퍼 풀은 데이터를 읽거나 조작을 행할 때에 사용되는 메모리의 영역이다. 버퍼 풀의 목적은 메모리내에 데이터를 버퍼링함으로써 데이터베이스 시스템 성능을 향상시키기 위함이다. 따라서 자주 사용되는 데이터를 버퍼 풀에 놓여지게 하는 것은 매우 중요한 일이다. DB2내의 모든 데이터가 버퍼링되지 않으며, Long Field와 LOB은 직접 I/O를 통해서만 액세스되고 결코 버퍼 풀내에 저장되지 않는다. 데이터베이스 관리자의 구성요소 중 하나가 Bufferpool Service(BPS)이다. BPS에서는 데이터와 색인 페이지를 디스크에서 메모리로 읽고, 메모리에서 디스크로 기록하는 일을 담당한다. BPS는 SMS 또는 DMS 테이블공간에 따라 페이지를 얻기 위해 File Storage Manager 또는 Raw Storage Manager를 사용한다.

버퍼 풀을 생성할 때 기본 페이지 크기는 4KB이다. 또한 버퍼 풀을 생성할 때 4KB, 8KB, 16KB, 32KB 중 하나로 페이지 크기를 갖는 것으로 선택할 수 있다. 버퍼 풀을 생성하면 동일한 페이지 크기를 사용하여 생성한 테이블공간만이 이 버퍼 풀과 연관시킬 수 있다.

각 데이터베이스는 적어도 하나의 버퍼 풀(IBMDEFAULTBP, 데이터베이스 생성시에 자동 생성됨)을 가지고, 그 이상을 가질 수 있다. 모든 버퍼 풀들은 데이터베이스를 사용하는 모든 응용프로그램에는 사용가능한 데이터베이스 전역 메모리에서 상주한다. 모든 버퍼 풀들을 응용프로그램이 데이터베이스에 처음 연결할 때 할당되거나, 외부적으로 ACTIVATE DATABASE 명령어를 사용할 때 활성화된다. 모든 연결이 종료된다 하더라도 버퍼 풀을 유지하기 위해 ACTIVATE DATABASE 명령어를 사용할 수 있다. 이것은 연결 로드가 매우 동적인 경우 (예를 들어, 웹 서버) 매우 유용하다.

응용프로그램이 데이터베이스에서 데이터를 요청할 때, 데이터를 포함한 페이지들은 디스크에서 버퍼 풀들중의 하나로 전달된다. 다음에 응용프로그램이 데이터를 요청할 때, 데이터가 메모리 영역내에 있는지를 먼저 확인하고 만약 존재하면 BPS는 디스크에서 데이터를 읽을 필요가 없다. 다시 말해, 디스크로부터의 데이터 추출 방지는 빠른 성능 결과를 가져다 준다. 만약 버퍼 풀이 필요한 데이터를 메모리내에 유지하기에 충분하지 않다면, BPS는 디스크에서 데이터를 읽어야 한다. 페이지는 변경되거나 다음 중의 하나가 발생될 때까지는 디스크로 다시 기록되지 않는다.

• 모든 응용프로그램이 데이터베이스와의 연결이 끊길 때(Disconnect)
• 데이터베이스가 외부적으로 비활성화될 때(Deactivate)
• 모든 연결된 응용프로그램이 확약될 때 (Commit)
• 다른 들어오는 페이지를 위해 공간이 필요할때
• 페이지 정리자가 사용가능(NUM_IOCLEANERS 데이터베이스 구성 매개변수가 0이 아닌 경우) 하고 데이터베이스 관리자에 의해 활성화될 때

필요한 데이터를 버퍼 풀로 읽어오거나 디스크로 쓰는 데는 두 가지 방법이 있다.

• 첫번째는 동기적인 수행 방식으로 데이터가 필요할 때마다 db2agent라는 프로세스를 가동시켜 데이터를 가져오는 방법이 있다.
• 두번째는 비동기적인 수행 방식으로 버퍼 풀을 모니터링 하여서 I/O 서버에 의해 데이터를 가져오 고 페이지 정리자에 의해 데이터를 쓰는 방법이 있다.

하나 이상의 버퍼 풀을 구성하는 것은 가장 중요한 튜닝 부분이다. UDB에서는 테이블 공간별로 버퍼 풀을 할당할 수가 있다. 따라서 색인등을 위한 테이블 공간을 작성한 후 별도의 버퍼 풀을 할당하는 것은 좋은 방법이다.

DB2 옵티마이저는 가장 좋은 쿼리 성능을 성취하기 위해 서로 다른 버퍼 풀을 활용한다. 액세스 계획을 선택할 때, 옵티마이저는 디스크에서 버퍼 풀로의 페이지들을 페치하는 I/O 비용을 고려한다. 또한 옵티마이저는 쿼리를 만족하기 위해 필요한 I/O의 수를 예측한다. 옵티마이저는 예측하기 위해 BUFFERPOOLS 시스템 카탈로그 테이블내의 NPAGES 컬럼의 값을 고려한다.

AVG_APPLS 매개변수는 옵티마이저에게 활동중인 응용프로그램의 평균수에 대한 정보를 제공한다. 이 매개변수는 각각의 응용프로그램에 대해 각각의 버퍼 풀이 얼마나 사용되는지를 결정하기 위해 옵티마이저에 의해 사용되어진다. 이 매개변수에 대해, 1 값은 옵티마이저가 하나의 응용프로그램에 전체 버퍼 풀이??니터는 읽기와 쓰기 횟수와 시간에 대한 정보를 얻기 위해 사용되어질 수 있다. 스냅샷을 수행하기 전에 다음중의 하나를 수행함으로써 버퍼ul class="bu_point dep3">

• 현재의 세션에만 영향을 미치는 UPDATE MONITOR SWITCHES 명령어를 수행한다. db2 UPDATE MONITOR SWITCHES USING BUFFERPOOL ON
• DBM_MON_BUFPOOL 데이터베이스 관리자 구성 매개변수를 ON으로 변경한다. db2 UPDATE DBM CFG USING DBM_MON_BUFPOOL ON

스냅샷 모니터는 다음의 명령어를 수행할 때 데이터베이스에 대한 버퍼 풀 활동에 대한 정보를 제공한다.

• db2 GET SNAPSHOT FOR BUFFERPOOLS ON SAMPLE
• 버퍼 풀 데이터 논리적 읽기 - 버퍼 풀을 통과한 데이터 페이지의 논리적 읽기 요청 수
• 버퍼 풀 데이터 물리적 읽기 - 버퍼 풀에 데이터 페이지를 넣기 위해 I/O를 요구한 읽기 요청 수
• 버퍼 풀 색인 논리적 읽기 - 버퍼 풀을 통과한 색인 페이지의 논리적 읽기 요청 수
• 버퍼 풀 색인 물리적 읽기 - 버퍼 풀에 색인 페이지를 넣기 위해 I/O를 요구한 읽기 요청 수
• 버퍼 풀 적중율 (Bufferpool Hit Ratio) =
  1 - ((버퍼 풀 데이터 물리적 읽기 + 버퍼 풀 색인 물리적 읽기)
  /(버퍼 풀 데이터 논리적 읽기 + 버퍼 풀 색인 논리적 읽기))

버퍼 풀 적중율은 데이터베이스 관리자가 페이지 요청 서비스를 하기 위해 디스크에서 페이지를 로드할 필요가 없는 시간의 비율을 가리킨다. 즉 페이지가 이미 버퍼 풀에 있다는 것을 의미한다. 버퍼 풀 적중율이 높으면 높을수록 디스크 I/O의 빈도수가 낮아진다.
일반적으로 버퍼 풀 크기를 증가시키면 적중율은 향상되지만, 리턴은 줄어든다. 이상적으로 전체의 데이터베이스를 저장할 만큼 충분한 버퍼 풀이 있고, 시스템이 최대 성능으로 수행중이면 100%의 적중율을 확보할 수 있다. 하지만 대부분인 경우에는 비현실적이다. 적 중율의 중요성은 데이터 크기와 데이터를 액세스하는 방식에 달려 있다. 데이터를 균등하게 액세스하는 대형 데이터베이스에서 버퍼 풀 크기를 증가하는 것은 버퍼 풀 적중율에 최소한의 효과를 가져다 준다. 좀 더 작고 자주 액세스되는 테이블 및 색인에 초점을 맞춘다. 그리고 높은 적중율이 나오도록 개별 버퍼 풀을 할당한다.

• 데이터와 색인을 두개의 다른 버퍼 풀로 분리하여 각각을 조정한다. - 색인과 데이터가 다른 테이블 공간에 상주하는 것이 필요하다.
• 하나의 버퍼 풀을 사용하나, 색인 적중율의 증가가 멈출때까지 크기를 증가한다.

색인 풀 적중율과 버퍼 풀 적중율은 데이터 재구성(Reorganization)에 영향을 받는다. 조정하기 전에 적중율은 확인하기 위해 REORGCHK 명령어를 수행하는 것이 바람직하다.

기본값은 1000페이지이고, (2*MAXAPPLS) - 524288사이의 값을 가질수 있다.
관련 매개변수는 데이터베이스 힙 (DBHEAP), 비동기 페이지 정리자의 수(NUM_IOCLEANERS), 변경된 페이지 한계값 (CHNGPGS_THRESH) 등이 있다.

데이터베이스 힙 크기 (DBHEAP)

각각의 데이터베이스는 데이터베이스 힙이라는 메모리를 가진다. 이 영역은 테이블, 색인, 테이블 공간과 버퍼 풀에 대한 제어 블럭 정보를 가지고 있다. 또한, 이벤트 모니터 버퍼, 로그 버퍼와 카탈로그 캐쉬에 대한 공간도 이 영역에서 할당을 하게 된다. 기본값은 1200페이지이고, 32 - 60000 사이의 값을 가질 수 있다.

관련 매개변수는 카탈로그 캐쉬 크기 (catalogcache_sz), 로그 버퍼 크기 (logbufsz)이다.

I/O 서버의 수 (NUM_IOSERVERS)

DB2는 응용프로그램이 필요로 하는 페이지들을 미리 버퍼 풀로 읽어 들여서 성능을 증가시킬 수 있다. 이러한 프리페칭을 가능하게 하는 방법은 I/O 서버라고 하는 별도의 쓰레드들을 통해서 가능하게 된다. 결과적으로 쿼리 처리는 두 개의 활동, 데이터 처리(CPU)와 데이터 페이지 I/O로 구분될 수 있다. I/O 서버는 CPU 처리 활동에서 프리페치 요청을 기다린다. 비 프리페치 I/O는 데이터베이스 에이전트에서 직접 스케쥴된다. 만약 프리페처와 페이지 정리자가 지정되지 않으면, 응용프로그램 에이전트는 버퍼 풀과 디스크 저장 영역사이에서 모든 데이터를 읽고 기록해야 한다. 따라서 효율적인 I/O를 유지하기 위해서는 적정한 수의 I/O 서버를 구성하여야 한다.

프리페처가 비동기 액세스, 대형 블록을 제공하고, 병렬 I/O를 제공하기 때문에, 효율적인 I/O는 DSS에서 이루어질 수 있다.

NUM_IOSERVERS의 기본값은 3이고, 1- 255사이의 값을 가진다.

관련 매개변수는 기본 프리페치 크기(DFT_PREFETCH_SZ), 순차 검출 플래그(SEQDETECT)

비동기 페이지 정리자의 수 (NUM_IOCLEANERS)

페이지들은 버퍼 풀내에 변경된 페이지가 차지하는 공간의 퍼센트가 CHNGPGS_THRESH 구성 매개변수에서 지정한 값을 초과할 때 버퍼 풀에서 디스크로 기록된다. 페이지 정리자 에이전트(NUM_IOCLEANERS)는 변경된 페이지들을 디스크로 기록한다. 페이지 정리자는 DB2에이전트와 무관하기 때문에 때때로 비동기 페이지 정리자 또는 비동기 버퍼 기록이라고 언급된다. 페이지 정리자들은 버퍼 풀내의 공간이 데이터베이스 에이전트에 의해 필요로 하기 전에 변경된 페이지들을 버퍼 풀에서 디스크로 변경된 페이지들을 기록한다. 이것은 에이전트가 변경된 페이지들을 기록하는 것을 기다리지 않는다는 것을 의미한다. 결과적으로 응용프로그램의 트랜잭션이 좀 더 빠르게 수행될 수 있다.

페이지 정리자는 DB2 에이전트와 무관하기 때문에 때때로 비동기 페이지 정리자 또는 비동기 버퍼 기록이라고 언급된다.

NUM_IOCLEANERS의 기본값은 1이고, 0 - 255사이의 값을 가진다.

관련 매개변수는 버퍼 풀 크기(BUFFPAGE), 변경된 페이지 한계값(CHNGPGS_THRESH)

변경된 페이지 한계값 (CHNGPGS_THRESH)

이 매개변수는 비동기 페이지 정리자가 시작되는 시점을 지정하는 값이다. 버퍼 풀에 있는 페이지들중 변경된 페이지의 퍼센트가 지정된 값에 이르면 페이지 정리자가 시작되어 변경된(Dirty) 페이지들을 디스크로 쓰게 된다. 페이지들을 디스크에 기록하는 것이 끝나면, 다시 비활동(Inactive) 상태가 되고 다음 트리거가 시작되기를 기다린다. 이 매개변수는 NUM_IOCLEANERS 매개변수와 관려되어 있다.

기본값은 60퍼센트이고, 5 - 99 퍼센트값을 가질 수 있다.

관련 매개변수는 비동기 페이지 정리자의 수 (NUM_IOCLEANERS)

정렬 힙 크기 (SORTHEAP)

SORTHEAP은 정렬시에 데이터베이스에 연결된 각각의 에이전트에게 할당되는 개인용 메모리(Private Memory)의 양이다. 이 메모리는 정렬시에 할당되고 정렬이 끝나면 해제된다. 하나의 응용프로그램이 활동중인 동시 정렬들을 갖는 것이 가능하다. 서브쿼리를 갖는 SELECT 문장은 동시 정렬들을 발생시킬 수 있다. 정렬을 해야 할 테이블들이 크면 클수록 이 매개변수 값은 커야 한다.

기본값은 256 페이지이고, 16 - 524288사이의 값을 가진다.

관련 매개변수는 정렬 힙 임계값 (SHEAPTHRES)

정렬 힙 임계값 (SHEAPTHRES)

이 매개변수는 데이터베이스 관리자 매개변수로 인스턴스 안에 있는 모든 응용프로그램에 할당된 모든 SORTHEAP의 합계를 조절하는 것이다. 이 값은 소프트 리미트(Soft Limit)이기 때문에 만일 정렬을 위한 메모리가 더 필요하다면 데이터베이스 관리자가 적정한 한도내에서 메모리를 할당하게 된다.

파티션내 병렬 처리가 가능하다면, 정렬 수행이 병렬로 처리될 수 있고, 두 개의 다른 메모리 소스로부터 메모리를 사용하는 개인 정렬(Private Sort)과 공유 정렬(Shared Sort)이 있다. 개인 정렬을 위한 정렬 힙은 에이전트 개인 메모리(Agent Private Memory)이고, 공유 정렬을 위한 정렬 힙은 데이터베이스 전역 메모리(Database Global Memory)이다. 공유 정렬 메모리 영역의 크기는 SHEAPTHRES의 값을 기반으로 처음 데이터베이스에 연결시 정적으로 미리 정의되나 미리 할당하지는 않는다. 개인 정렬 메모리 영역의 크기는 제한이 없다. 쿼리에 수행되는 병렬 정렬의 유형을 보기 위해서 Explain 유틸리티를 사용할 수 있다.

SHEAPTHRES 매개변수는 개인(Private)과 공유(Shared) 정렬에 대해 다르게 사용된다.

• 개인 정렬(Private Sort)에 대해, 이 매개변수는 주어진 시간에 개인 정렬에 소비될 수 있는 총 메모리 의 양에 대한 인스턴스의 소프트 리미트 값이다. 인스턴스에 대해 전체 개인 정렬 메모리 소비가 이 한 계값에 도달할 때, 추가적으로 들어오는 개인 정렬 요청시에 할당되는 메모리는 현저하게 감소한다.
• 공유 정렬(Shared Sort)에 대해, 이 매개변수는 주어진 시간에 대해 공유 정렬에 소비될 수 있는 총 메 모리의 양에 대한 데이터베이스의 하드 리미트 값이다. 이 한계값에 도달할 때, 총 공유 정렬 메모리 소비가 SHEAPTHRES에 지정한 한계값 아래로 떨어질때까지 더 이상의 공유 정렬 메모리 요청이 허 용되지 않는다.

가능한 한 메모리 페이징이 발생함이 없이 정렬 힙에 많은 메모리를 할당하는 것이 중요하다. 정렬 메모리내에 정렬이 전체로 이루어지게 하는 것은 가능하나, 이것이 운영 시스템으로 하여금 페이지 스왑핑을 수행하는 것을 발생시킨다면, 대형 정렬 힙의 이점을 잃어버릴 수 있다. 따라서 SORTHEAP / SHEAPTHRES 구성 매개변수들을 조정할 때마다 시스템 페이징 여부를 추적하기 위해 운영 시스템 모니터를 사용하도록 한다.

시스템 성능 모니터를 사용하여 모니터될 수 있는 정렬에 관련된 요소는 다음과 같다.

• 총 정렬 : 실행된 총 정렬의 수
• 정렬 오버플로우 : 정렬 힙을 초과하여 임시 저장공간을 위한 디스크 공간이 요청된 총 정렬의 수
• 정렬 오버플로우/총 정렬 :

옵티마이저가 정렬 힙을 사용하고자 하나 실패한 경우. 비율이 놓으면 SORTHEAP을 증가하고 또는 SHEAPTHRES 값을 증가하는 것을 고려해야 한다.

• 요청된 파이프 정렬
• 수락된 파이프 정렬
• 수락된 파이프 정렬 / 요청된 파이프 정렬

파이프 정렬이 옵티마이저에 의해 선택되었으나 수락되지 않는 경우. 비율이 낮다면 SORTHEAP을 증 가하고 또는 SHEAPTHRESH 값을 증가하는 것을 고려해야 한다. 파이프 정렬에서는 정렬 힙이 응용 프로그램이 정렬과 관련된 커서를 닫을 때까지 해제하지 않는다. 따라서 파이프 정렬은 커서가 닫힐 때까지 메모리를 사용할 수 있다.

db2 GET SNAPSHOT FOR DATABASE MANAGER | grep -i "정렬"

할당된 정렬 힙(heap)                               =   305

  포스트 임계값 정렬                                  =   0

  요청된 파이프 정렬                                  =   4

  수락된 파이프 정렬                                  =   4

  정렬 정보 (SORT)                                   = ON 08/25/2000 09:34:48.448833

db2 GET SNAPSHOT FOR DATABASE ON sample | grep -i "정렬"

할당된 총 정렬 힙(heap)                          = 305

  총 정렬                                                  = 2

  총 정렬 시간(밀리초)                               = 19649

  정렬 오버플로우                                      = 0

  사용중인 정렬                                         = 4

기본값은 20000 페이지이고, 250 - 2097152 사이의 값을 가질 수 있다.

관련 매개변수는 정렬 힙 크기 (SORTHEAP)

패키지 캐쉬 크기 (PCKCACHESZ)

이 매개변수는 정적 및 동적 SQL문을 캐쉬하기 위한 메모리의 양을 정한다. 패키지 캐싱은 응용프로그램이 패키지 정보를 필요로 할 때 시스템 카탈로그를 접근해야하는 오버헤드를 줄일 수가 있다. 예를 들어서, 두 사용자가 같은 쿼리를 가진 같은 응용프로그램을 수행하면, 이 쿼리에 대한 액세스 계획이 같으므로 이미 캐쉬되어 있는 패키지 정보를 사용할 수가 있다.

데이터베이스에 연결된 응용프로그램이 같은 쿼리를 여러 번 수행한다면, 데이터베이스 관리자는 정적 SQL을 위한 패키지의 섹션들을 재로드할 필요를 제거함으로써 내부적인 오버헤드를 줄일 수 있고, 동적 SQL을 위한 패키지를 생성할 오버헤드를 줄일 수 있다.

동적 SQL에 대해서, 응용프로그램이 정확히 같은 쿼리를 실행하지 않는다 하더라도, 파라미터 마커 (Parameter Marker)를 사용하면 패키지 캐쉬에 대한 이점이 있다.

시스템 성능 모니터를 사용하여 모니터될 수 있는 패키지 캐쉬에 관련된 성능 변수들은 많이 있다. 이들 매개변수들은 다음과 같다.

• 패키지 캐쉬 삽입 (Package Cache Insert)
  요청된 섹션이 사용할 수 없어 패키지 캐쉬에 로드해야 하는 총 횟수. 이 값이 높으면 캐쉬가 작다는 것을 의미한다.
• 패키지 캐쉬 찾아보기 (Package Cache Lookups)
  응용프로그램이 패키지 캐쉬내에 섹션 또는 패키지를 찾는 횟수. 이 횟수는 섹션이 이미 캐쉬에 로 드된 경우와 섹션이 캐쉬로 로드해야 할때를 포함한다.
• 패키지 캐쉬 적중율 (Package Cache Hit Ratio) = 1 - (패키지 캐쉬 삽입 / 패키지 캐쉬 찾아보기)

일반적으로 낮은 적중율은 캐쉬가 너무 작다는 것을 의미한다. 그러나, 수행하는 DDL문장의 결과로써, 낮은 적중율이 캐쉬가 작다는 것을 항상 의미하지는 않는다. 그것은 불합리한 동적 섹션들과 정보가 다시 캐쉬에 재입력됨으로써 발생될 수도 있다. 이 경우 PCKCACHESZ를 증가해도 캐쉬 성능은 향상되지 않는다. 따라서 패키지 캐쉬 크기를 조정할 때는 응용프로그램의 유형에 대해 고려해야 한다. 예를 들어 응용프로그램이 같은 쿼리를 드물게 수행한다면, 패키지를 유지하기 위해 패키지 캐쉬를 증가시키는 것은 가치가 없을 수도 있다.

PCKCACHESZ 매개변수에 지정된 한계값은 소프트 리미트(Soft Limit)이다. 이 한계값은 필요하면, 메모리가 데이터베이스 공유 집합에서 여전히 이용가능하다면, 초과할 수 있 다. 패키지 캐쉬가 가질수 있는 가장 큰 값을 결정하기 위해 패키지 캐쉬에 할당된 최 고 페이지수(Package Cache High Water Mark) 모니터 요소와 PCKCACHESZ 매개변수에서 지정한 한계값이 초과된 횟수를 결정하기 위해 패키지 캐쉬 오버플로우(Package Cache Overflows) 모니터 요소를 사용할 수 있다. 다음의 예는 스냅샷 모니터에 의해 모니터되는 패키지 캐쉬에 관련된 요소들을 보여준다.

$ db2 get snapshot for database on sample | grep -i "패키지"

패키지 캐쉬 찾아보기(lookup)                                   = 2

  패키지 캐쉬 삽입                                                     = 2

  패키지 캐쉬 오버플로우                                            = 0

  패키지 캐쉬에 할당된 최고 페이지 수(바이트)              = 137731

기본값은 -1이고, 의미는 MAXAPPLS값의 8배로 페이지를 할당한다는 것을 의미한다. 32 - 64000 사이의 값을 가질 수 있다.

로그 버퍼 크기 (LOGBUFSZ)

데이터베이스 관리자가 갱신된 데이터 등을 디스크로 로깅을 하기 전에 메모리에 버퍼링을 하게된다. 이 로그 버퍼에 있는 내용은 다음과 같은 상황에서 디스크로 쓰여진다.

• MINCOMMIT 구성 매개변수에 의해 정의된 트랜잭션 확약(Commit)시
• 로그 버퍼가 찼을 때
• 다른 내부 데이터베이스 관리자 이벤트의 결과로

로그 레코드를 버퍼링하는 것은 파일 I/O를 줄일 수 있으므로 효율적인 결과를 가져온다. 로그 버퍼 크기를 설정할 때, LOGBUFSZ가 데이터베이스 힙(DBHEAP)에서 할당되기 때문에 DBHEAP의 크기도 고려해야 한다. 또한 큰 로그 버퍼를 사용하는 것는 데이터베이스 확약(Commit)이 로그 파일을 강제로 기록하기 때문에 데이터 무결성을 감소시키지 않는다.

기본값은 8페이지이고, 4 - 4096 사이의 값을 가질 수 있다.

관련 매개변수는 카탈로그 캐쉬 크기 (CATALOGCACHE_SZ), 데이터베이스 힙 (DBHEAP), 그룹 Commits갯수 (MINCOMMIT)이다.

실행중인 응용프로그램의 최대수 (MAXAPPLS)

이 매개변수는 동시에 데이터베이스에 연결될 수 있는 응용프로그램의 최대수이다. 데이터베이스에 연결된 각각의 응용프로그램은 각각 고유의 메모리를 할당받게 된다. 따라서 많은 수의 동시 응용프로그램이 허용되면 많은 메모리를 사용하게 되므로 페이징의 우려가 있다.

기본값은 40이고, 1 - 64000사이의 값을 가질 수 있다.

관련 매개변수는 에이전트의 최대수 (MAXAGENTS), 조정 에이전트의 최대수 (MAX_COORDAGENTS), 자동 업그레이드(ESCALATION)전에 잠금 목록의 최대 백분율 (MAXLOCKS), 잠금 목록을 위한 최대 저장영역 (LOCKLIST), 평균 실행 중인 응용프로그램의 수 (AVG_APPLS) 이다.

에이전트의 최대수 (MAXAGENTS)

이 매개변수는 응용프로그램 요청들을 받기 위한 데이터베이스 관리자 에이전트 (db2agent)의 최대 수를 가리킨다. 데이터베이스 관리자는 응용프로그램이 요청을 할 때마다 에이전트를 하나씩 할당하게 된다. SMP 머신의 경우 쿼리내 병렬 처리가 지원되면 하나의 응용프로그램에 대하여 여러개의 서브 에이전트들이 할당될 수 있으므로 최소한 MAXAPPLS값보다는 커야 한다.

기본값은 200이고, 1 - 64000 사이의 값을 가질 수 있다.

관련 매개변수는 실행중인 응용프로그램의 최대수 (MAXAPPLS), 동시 에이전트의 죄대수 (MAXCAGENTS), 조정 에이전트의 최대수 (MAX_COORDAGENTS), DARI 프로세스의 최대수 (MAXDARI), 최소 확약된 사적 메모리 (MIN_PRIV_MEM), 에이전트 풀 크기 (NUM_POOLAGENTS)

에이전트 풀 크기 (NUM_POOLAGENTS)

데이터베이스 관리자 구성 매개변수 NUM_POOLAGENTS는 유휴(Idle) 에이전트를 포함하는 에이전트 풀의 크기를 정의한다. DB2 에이전트가 현재의 요청을 실행하는 것이 끝날 때, 유휴 에이전트의 수가 NUM_POOLAGENTS의 값을 초과하지 않는 한 유휴(Idle) 상태에 놓이게 되고, 그렇지 않으면 종료된다.

데이터베이스 관리자는 응용프로그램을 위해 조정 에이전트 또는 서브 에이전트를 할당할 필요가 있을 때, 에이전트 풀로부터 유휴 에이전트를 재사용하고자 한다. 만약 에이전트 풀이 이용 가능한 유휴 에이전트를 가지고 있지 않다면, 데이터베이스 관리자는 새로운 에이전트 프로세스들을 생성한다 (MAXAGENTS에 정의된 숫자가 될 때까지). 만약 NUM_POOLAGENTS에 지정한 값보다 많은 에이전트가 생성된다면, 현재의 요청을 실행하는 것이 끝날 때, 에이전트는 풀로 리턴되기보다 종료된다.

이 매개변수에 적당한 값을 설정함으로써 DB2 에이전트 프로세스들을 생성하고 종료하는 비용을 감소시킬 수 있다. 또한 이 매개변수에 너무 높은 값을 설정하면 많은 유휴 에이전트로 인해 메모리를 낭비시킬 수 있다.

적은 응용프로그램이 동시에 연결하는 DSS 환경에서는 작은 값을 설정하고, 많은 응용프로그램이 동시에 연결하는 트랜잭션 처리 환경에서는 에이전트의 빈번한 생성과 종료에 관련된 비용을 피하기 위해 NUM_POOLAGENTS의 값을 증가시킨다.

관련 매개변수는 풀의 초기 에이전트의 수 (NUM_INITAGENTS), 에이전트의 최대 수 (MAXAGENTS), 병렬 처리 최대 조회 정도 (MAX_QUERYDEGREE), 조정 에이전트의 최대수 (MAX_COORDAGENTS)

잠금 목록을 위한 최대 저장영역 (LOCKLIST)

이 매개변수는 잠금 목록에 할당된 영역의 양을 나타낸다. 데이터베이스당 하나의 잠금 목록이 있고 그 데이터베이스에 연결된 모든 응용프로그램의 잠금들을 포함한다. 각각의 잠금은 잠금 목록 안에 32 또는 64바이트를 필요로 한다. 잠금이 없는 오브젝트에 대하여 잠금을 할 때는 64바이트가 필요하고, 잠금이 있는 오브젝트에 대하여 잠금을 할 때는 32바이트가 필요하다.

기본값은 100페이지이고, 4 - 60000 사이의 값을 가질 수 있다.

관련 매개변수는 자동 업그레이드(Escalation)전의 응용프로그램당 잠금 목록의 최대 퍼센트 (MAXLOCKS), 실행중인 응용프로그램의 최대수 (MAXAPPLS)이다.

자동 업그레이드(Escalation)전에 응용프로그램당 잠금 목록의 최대 퍼센트 (MAXLOCKS)

이 매개변수는 잠금 목록에 할당된 영역의 양을 나타낸다. 데이터베이스당 하나의 잠금 목록이 있고 그 데이터베이스에 연결된 모든 응용프로그램의 잠금들을 포함한다. 각각의 잠금은 잠금 목록 안에 32 또는 64바이트를 필요로 한다. 잠금이 없는 오브젝트에 대하여 잠금을 할 때는 64바이트가 필요하고, 잠금이 있는 오브젝트에 대하여 잠금을 할 때는 32바이트가 필요하다.

기본값은 100페이지이고, 4 - 60000 사이의 값을 가질 수 있다.

관련 매개변수는 자동 업그레이드(Escalation)전의 응용프로그램당 잠금 목록의 최대 퍼센트 (MAXLOCKS), 실행중인 응용프로그램의 최대수 (MAXAPPLS)이다.

병렬 처리의 최대 조회 등급 (MAX_QUERYDEGREE)

이 데이터베이스 관리자 매개변수는 데이터베이스 관리자의 인스턴스에서 실행하는 SQL 문장에 대해 사용되는 파티션내 병렬 처리의 최대 등급을 나타낸다. SQL 문장은 문장이 실행될 때 한 파티션내에서의 병렬 작업이 이 수치이상을 사용할 수 없다. SMP머신에서 파티션내 병렬 처리를 사용하기 위해서는 데이터베이스 파티션이 가능하도록 INTRA_PARALLEL 구성 매개변수가 반드시 YES로 설정되어야 한다.

기본값은 -1이고, 이 의미는 데이터베이스 시스템이 옵션을 자동으로 결정한다는 것을 말한다. 1 - 32767사이의 값을 가질 수 있다.

관련 매개변수는 기본 정도 (DFT_DEGREE), 파티션내 병렬 처리 가능 (INTRA_PARALLEL) 이다.

RAID를 사용할 경우의 고려사항.

데이터베이스의 작업은 크게 CPU작업과 I/O작업으로 분류할 수가 있다. 이중에서 I/O작업의 효율성을 높이기 위해서는 데이터베이스의 내용이 하드디스크에 전체적으로 골고루 분산되어 있어야 하며, 데이타가 필요할 경우 여러 개의 하드디스크를 동시에 접근할 수 있어야 한다. 하지만 RAID로 구성되어 있는 디스크의 경우 물리적으로 여러 개의 디스크가 하나의 디스크로 보이기 때문에 컨테이너를 구성함에 있어서 약간의 고려사항이 필요하다.

1) DB2_PARALLEL_IO

이 레지스트리 변수는 하나의 컨테이너를 가지는 하나의 테이블 공간에 대하여 병렬 I/O을 하도록 하는 것이다. 데이터베이스에 안에 여러 개의 컨테이너를 가지면 데이터베이스 관리자는 자동적으로 병렬 I/O를 한다. 그러나, 특별한 상황에서는 하나의 컨테이너에 대하여 병렬 I/O를 하는 것이 효율적일수 있다. 예를 들면, 컨테이너가 여러 개의 물리적인 디스크로 구성된 하나의 RAID장치에 만들어져 있으면, 비록 논리적으로는 하나의 디스크이지만 물리적으로는 여러 개의 디스크이므로 병렬 읽기, 쓰기를 하는 것이 효율적이다.

2) DB2_STRIPED_CONTAINERS

DMS 테이블 공간에 컨테이너를 작성할 때, 특성상 컨테이너 앞에 태그를 위해서 한 페이지가 할당된다. 그 이외의 페이지들은 extent크기로 블럭된 페이지로 그룹지워진다. RAID장치에서 테이블 공간에 컨테이너를 작성할 때는, 하나의 extent 크기가 RAID 스트라이프 크기와 같거나 배수로 작성될 것을 제안한다. 그렇게 해야만 RAID가 일으키는 I/O와 데이터베이스가 필요로 하는 페이지의 정보들이 효율적으로 전송될 수 있기 때문이다. 그러나, 한 페이지의 컨테이너 태그때문에, extent들이 RAID 스트라이프와 엇갈릴게 된다. 따라서 이를 방지하려면 이 레지스트리 변수를 ON으로 설정한 후 테이블스페이스 컨테이너를 작성해야 한다. 이렇게 작성된 컨테이너는 태그를 위해 한 페이지가 아니라 한 extent를 할당하게 됨으로 RAID 스트라이프와 정렬되게 되는 것이다.