DB2 테이블스페이스와 버퍼풀

요약： 테이블 스페이스과 버퍼 풀의 중요성을 인식시키고, 이들을 올바르게 설계하고 튜닝하여 데이터베이스 성능을 높이는 방법을 설명합니다.

머리말

DB2의 세계로 막 진입한 DBA나 앞으로 DBA가 될 사람들에게는 새로운 데이터베이스를 위한 디자인과 퍼포먼스를 선택하기란 매우 어렵다. 이 글에서, DBA에게 있어 중요한 두 가지 영역에 대해 살펴보기로 한다. 바로 테이블 스페이스과 버퍼 풀이다. 테이블 스페이스과 버퍼 풀을 어떻게 디자인 하는냐, 또 어떻게 튜닝하느냐에 따라 DB2 Server의 성능에 큰 영향을 줄 수 있기 때문에 테이블 스페이스과 버퍼 풀의 디자인과 튜닝에 초점을 맞추어 설명하도록 한다.

예제는 DB2 version 8.1, Enterprise Server Edition을 기준으로 한다. 예제 대부분은 이전 버전에도 적용된다. version 8.1에만 적용될 경우 별도로 알려주겠다.

Section 1에서는 DB2가 테이블 스페이스 Type을 어떻게 정의하고 데이터를 어떻게 저장하는지에 대해 설명할 예정이다. 그리고 구성 옵션 및 테이블 스페이스의 생성 및 관리방법에 대해 다룰 것이다. 또한, 버퍼 풀이 무엇이며 버퍼 풀의 생성 및 사용방법에 대해서도 중점적으로 다룰 예정이다. Section 2에서는 성능을 높이기 위해 앞에서 다룬 테이블 스페이스 및 버퍼풀이 어떻게 구성되어야 하는지를 알아보도록 한다.

http://www.ibm.com/developerworks/kr/library/0212wieser/0212wieser.html
http://www.ibm.com/developerworks/data/library/techarticle/0212wieser/

Section 1: 정의

테이블 스페이스

데이터베이스안에 존재하는 모든 데이터들은 수 많은 테이블 스페이스에 저장된다. 테이블 스페이스을 자식으로 , 데이터베이스를 부모로 생각해 보면 테이블 스페이스(자식)은 한 개 이상의 데이터베이스(부모)를 가질 수 없다. 테이블 스페이스마다 사용 용도가 다르기 때문에 사용용도 및 관리 방식에 따라 테이블 스페이스은 다음과 같이 다섯가지로 분류된다.

카탈로그 테이블 스페이스

데이터베이스 당 단 한 개의 카탈로그 테이블 스페이스이 있고 CREATE DATABASE 명령어가 실행될 때 만들어 진다. DB2에 의해 SYSCATSPACE로 이름이 붙여진 카탈로그 테이블 스페이스에는 시스템 카탈로그 테이블이 있다. 이 테이블 스페이스은 데이터베이스가 만들어질 때 항상 생성되어진다.

Regular 테이블 스페이스

regular 테이블 스페이스에는 테이블 데이터와 인덱스가 포함된다. 만약 Large Objects ( LOBs ) 같은 Long 데이터가 Long 테이블 스페이스에 명시적으로 저장되지 않았다면 이와 같은 Long 데이터도 Regular 테이블 스페이스에 저장될 수 있다. 테이블과 인덱스는 개별적인 Regular 테이블 스페이스으로 분리될 수 있다. 테이블 스페이스이 데이터베이스 관리 스페이스(DMS)일 경우가 그렇다. DMS와 시스템 관리 스페이스(SMS)의 차이는 나중에 설명하도록 하겠다. 적어도 한 개의 Regular 테이블 스페이스은 각 데이터베이스에 존재해야 한다. 데이터베이스가 만들어질 때 디폴트로 USERSPACE1이라는 이름이 붙여진다.

Long 테이블 스페이스

Long 테이블 스페이스은 길거나 LOB 테이블 칼럼을 저장하는데 사용되고 DMS 테이블 스페이스에 있어야 한다. 또한 구조화된 유형 칼럼이나 인덱스 데이터도 저장할 수 있다. Long 테이블 스페이스이 정의되지 않으면 LOB는 Regular 테이블 스페이스에 저장된다. Long 테이블 스페이스은 옵션이며 기본적으로 생기는 것이 아니다.

시스템 임시 테이블 스페이스

시스템 임시 테이블 스페이스은 소팅, 테이블 재구성, 인덱스 생성, 테이블 결합 같은 SQL 연산 동안 필요한 내부의 임시 데이터를 저장하는데 사용된다. 데이터베이스에 최소 한 개는 있어야 한다. 데이터베이스와 함께 생성되며 디폴트 이름은 TEMPSPACE1이다.

사용자 임시 테이블 스페이스

사용자 임시 테이블 스페이스에는 Declared Global Temporary Table이 저장된다. 데이터베이스가 만들어질 때에는 사용자 임시 테이블 스페이스은 존재하지 않으나 만약 Declared Global Temporary Table을 정의할 경우에는 적어도 한 개의 사용자 임시 테이블 스페이스이 존재해야만 한다. 사용자 임시 테이블 스페이스은 선택사항이며 디폴트로는 생성이 되지 않는다.

테이블 스페이스 관리

테이블 스페이스은 두 가지 방식으로 관리될 수 있다.

시스템 관리 스페이스(SMS)

SMS 테이블 스페이스은 OS가 관리한다. 컨테이너들은 일반 OS 파일로서 정의되고 OS 호출을 통해 액세스 된다. 즉 이는 모든 일반 OS 함수들이 다음과 같은 것을 다룰 수 있다는 것을 의미한다. : I/O는 OS에 의해 버퍼링 되고 스페이스은 OS 규약에 따라 할당되고 테이블 스페이스은 필요할 경우 자동으로 확장된다. 하지만 SMS 테이블 스페이스에서 컨테이너들을 제거하는 것은 불가능하고 새로운 컨테이너들을 SMS 테이블 스페이스에 추가하는 것은 파티션 데이터베이스에서만 가능하다. 이전 섹션에서 설명한 이 세가지 기본 테이블 스페이스이 SMS이다.

데이터베이스 관리 스페이스(DMS)

DMS 테이블 스페이스은 DB2가 관리한다. 컨테이너는 파일(테이블 스페이스이 만들어 질 때 주어진 크기로 할당될 것이다.) 또는 디바이스로 정의된다. DB2는 할당 메소드 만큼 많은 I/O를 관리할 것이고 OS가 이를 수락할 것이다. 컨테이너 확장은 ALTER TABLESPACE 명령어를 통해 가능하며 사용되지 않는 DMS 컨테이너 부분 역시 릴리스 될 수 있다. ( Version 8 부터 )

다음은 컨테이너 크기를 늘리는 방법이다. (version 7과 version 8 모두 지원됨)

ALTER TABLESPACE TS1 RESIZE (FILE '/conts/cont0' 2000, DEVICE '/dev/rcont1' 2000, FILE 'cont2' 2000)

원래 컨테이너의 크기를 더 작은 크기로 조정하는 것은 Version 8에서만 지원된다.

테이블 스페이스을 생성하고 보는 방법

데이터베이스를 만들 때 세 개의 테이블 스페이스이 만들어진다. (SYSCATSPACE, TEMPSPACE1, USERSPACE1). DB2 명령어 윈도우나 유닉스 명령행을 사용하여 testdb라는 데이터베이스를 만들어서 여기에 연결하고 테이블 스페이스들을 나열한다.

CREATE DATABASE testdb CONNECT TO testdb LIST TABLESPACES

아래 Listing 1은 LIST TABLESPACES 명령어의 결과이다.

Listing 1. LIST TABLESPACES 명령어의 결과

Tablespaces for Current Database Tablespace ID = 0 Name = SYSCATSPACE Type = System managed space Contents = Any data State = 0x0000 Detailed explanation: Normal Tablespace ID = 1 Name = TEMPSPACE1 Type = System managed space Contents = System Temporary data State = 0x0000 Detailed explanation: Normal Tablespace ID = 2 Name = USERSPACE1 Type = System managed space Contents = Any data State = 0x0000 Detailed explanation: Normal

위에 보이는 세 개의 테이블 스페이스은 CREATE DATABASE 명령어에 의해 자동으로 생성된다. 사용자는 CREATE DATABASE 명령어 수행시 테이블 스페이스에 대한 정의를 지정함으로써 테이블 스페이스을 디폴트 값으로 생성하지 않아도 된다. 하지만 카탈로그 테이블 스페이스과 최소 한 개의 일반 테이블 스페이스과 한 개의 시스템 임시 테이블 스페이스은 데이터베이스 생성시 만들어져야 한다. (카탈로그 테이블 스페이스을 제외한) 모든 유형의 테이블 스페이스들이 CREATE DATABASE 명령어나 CREATE TABLESPACE 명령어를 사용하여 생성될 수 있다.

컨테이너

모든 테이블 스페이스에는 한 개 이상의 컨테이너가 있다. 이 컨테이너를 자식으로, 테이블 스페이스을 부모로 생각할 수 있다. 각 컨테이너는 한 개의 테이블 스페이스에만 속하지만 테이블 스페이스은 많은 컨테이너를 가질 수 있다. 컨테이너는 DMS 테이블 스페이스에 추가되거나 그 스페이스에서 제거될 수 있고 크기도 수정될 수 있다. 컨테이너는 파티션으로 나뉜 데이터베이스 상의 SMS 테이블 스페이스에만 추가될 수 있다. 이 파티션에는 테이블 스페이스에 할당된 컨테이너가 아직 없다. 새로운 컨테이너가 추가되면 자동 밸런싱이 시작되어 전체 컨테이너에 걸쳐 데이터를 분산시킨다. 재 밸런싱은 데이터베이스로의 동시 액세스를 방해하지는 않는다.

테이블 스페이스 설정

테이블 스페이스에는 많은 것이 설정될 수 있다. 테이블 스페이스이 생성될 때나 나중에 ALTER TABLESPACE문을 사용하여 설정할 수 있다.

페이지 크기 ( Page Size )

테이블 스페이스에 사용되는 페이지 크기를 정의한다. 지원되는 크기는 4K, 8K, 16K, 32K이다. 페이지 크기에 따라 테이블 스페이스에 저장되는 테이블의 한 행의 최대 길이와 컬럼 개수가 아래 표와 같이 제한된다.

표 1. 페이지 크기

페이지 크기	열 크기 한계	칼럼 카운트 한계	최대 용량
4 KB	4 005	500	64 GB
8 KB	8 101	1 012	128 GB
16 KB	16 293	1 012	256 GB
32 KB	32 677	1 012	512 GB

테이블 스페이스은 16384 페이지로 제한되기 때문에 이보다 더 큰 페이지를 선택하면 테이블 스페이스의 용량도 늘어난다.

확장 크기 ( Extent Size )

다음 컨테이너로 넘어가기 전에 컨테이너에 작성될 페이지의 수를 지정한다.데이터베이스 매니저는 컨테이너들을 반복적으로 순환하면서 데이터들을 저장한다. 이 매개 변수는 테이블 스페이스을 구성하는 컨테이너가 여러 개일 경우에만 유효하다.

프리패치 크기 ( Prefetch Size )

데이터 프리패치(미리 가져오기)가 수행될 때 테이블 스페이스에서 읽혀질 페이지의 수를 지정한다. 프리패치는 쿼리에 의해 참조되기 전에 쿼리에 필요한 데이터를 읽어서 쿼리가 I/O가 수행되는 것을 기다리지 않도록 한다. 프리패치는 순차적 I/O가 적절하고 프리패치가 퍼포먼스를 향상시킬 수 있다고 판단될 때 데이터베이스 매니저가 선택하는 것이다.

오버헤드와 전송 비율 ( Overhead and Transfer Rate )

이 값은 쿼리 최적화 동안 I/O의 비용을 결정하는데 사용된다. 두 값 모두 밀리초로 측정되고 모든 컨테이너의 평균치어야 한다. 오버헤드는 I/O 컨트롤러 액티비티, 디스크 탐색 시간, 회전 지연시간과 관련된 시간이다. 전송 비율은 한 페이지를 메모리로 읽어 들이는데 필요한 시간이다. 디폴트 값은 각각 24.1과 0.9이다. 이 값들은 하드웨어 스팩에 기반하여 계산될 수 있다.

CREATE TABLESPACE문의 예제

아래 예제는 Regular 테이블 스페이스을 생성하는 명령문을 보여준다. 위에서 거론되었던 매개변수 값들이 설정되어 있다.

CREATE TABLESPACE USERSPACE3 PAGESIZE 8K MANAGED BY SYSTEM USING ('d:\usp3_cont1', 'e:\usp3_cont2', 'f:\usp3_cont3') EXTENTSIZE 64 PREFETCHSIZE 32 BUFFERPOOL BP3 OVERHEAD 24.1 TRANSFERRATE 0.9

테이블 스페이스 애트리뷰트와 컨테이너를 보는 방법

LIST TABLESPACES 명령어의 SHOW DETAIL 옵션을 지정하면 추가 정보를 볼 수 있다.

LIST TABLESPACES SHOW DETAIL

Listing 2는 USERSPACE1 테이블 스페이스에 대한 정보를 보여준다. 디폴트로 데이터베이스 생성시 생성된 세 개의 테이블 스페이스들이 나열된다.

Listing 2. LlST TABLESPACES SHOW DETAIL 명령어의 결과값

Tablespaces for Current Database Tablespace ID = 2 Name = USERSPACE1 Type = System managed space Contents = Any data State = 0x0000 Detailed explanation: Normal Total pages = 336 Useable pages = 336 Used pages = 336 Free pages = Not applicable High water mark (pages) = Not applicable Page size (bytes) = 4096 Extent size (pages) = 32 Prefetch size (pages) = 16 Number of containers = 1

필요한 컨테이너 정보를 보려면 위의 결과값에서 Tablespace ID를 사용하여 아래 명령어를 수행한다.

LIST TABLESPACE CONTAINERS FOR 2

Listing 3. LIST TABLESPACE CONTAINERS 명령어의 결과값

Tablespace Containers for Tablespace 2 Container ID = 0 Name = C:\DB2\NODE0000\SQL00004\SQLT0002.0 Type = Path

이 명령어를 사용하면 지정된 테이블 스페이스에 대한 모든 컨테이너들이 나타난다. 위에 나타난 경로는 컨테이너가 물리적으로 위치한 곳을 가리킨다.

버퍼 풀

버퍼 풀은 하나의 데이터베이스와 제휴 되어 있고 한 개 이상의 테이블 스페이스에 의해 사용될 수 있다. 한 개 이상의 테이블 스페이스을 위한 버퍼 풀을 고려할 때 버퍼 풀 페이지 크기는 반드시 그 버퍼 풀을 사용하는 모든 테이블 스페이스의 페이지 크기와 동일해야 한다. 테이블 스페이스은 한 개의 버퍼 풀만을 사용한다.

데이터베이스가 만들어지면 IBMDEFAULTBP 라는 기본 버퍼 풀이 만들어지고 이는 모든 테이블 스페이스들이 공유한다. 더 많은 버퍼 풀들은 CREATE BUFFERPOOL 문을 사용하여 추가될 수 있다. 버퍼 풀 크기는 BUFFPAGE 데이터베이스 설정 매개변수로 지정된 크기가 기본이지만 CREATE BUFFERPOOL 명령어에서 SIZE 키워드를 지정해도 된다. 디스크 I/O를 줄이기 때문에 버퍼 풀 크기를 적절히 하는 것은 데이터베이스 성능에 중요하다. 또한 더 많은 작업들이 메모리에서 수행될 수 있으므로 버퍼 풀을 크게 하는 것은 쿼리 최적화에 영향을 준다.

블록 기반 버퍼 풀

Version 8에서는 블록 기반 프리패치를 위해 버퍼 풀(최대 98%) 부분을 남겨둘 수 있다. 블록 기반 I/O는 인접한 메모리 영역으로 블록을 읽어들임으로서 프리패치의 효율성을 높인다. 블록의 크기는 모든 버퍼 풀에 동일해야 하고 BLOCKSIZE 매개변수가 제어한다. 이 값은 페이지 단위의 블록 크기(2에서 256)이고 디폴트는 32이다.

확장된 스토리지

DB2는 버퍼의 확장된 스토리지를 사용하지 않는다. 하지만 확장된 스토리지는 메모리 페이지를 캐싱하는데 사용될 수 있다. 따라서 메모리에서 페이지를 더욱 빨리 이동할 수 있다.

CREATE BUFFERPOOL문 예제

다음은 CREATE BUFFERPOOL문 예제이다.

CREATE BUFFERPOOL BP3 SIZE 2000 PAGESIZE 8K

이 버퍼풀은 위 CREATE TABLESPACE 예제의 USERSPACE3에 지정된 것이고 테이블 스페이스이 생성되기 전에 만들어져야 된다. 이 버퍼 풀과 테이블 스페이스의 페이지 크기는 8K로 동일하다. 만약 버퍼 풀을 생성한 후에 테이블 스페이스을 생성하고 CREATE TABLESPACE 구문에서 BUFFER POOL BP3를 빼놓았다면 ALTER TABLESPACE 구문을 이용하여 기존 테이블 스페이스에 버퍼 풀을 추가할 수 있다.

ALTER TABLESPACE USERSPACE3 BUFFERPOOL BP3

버퍼 풀 애트리뷰트를 보는 방법

SYSCAT.BUFFERPOOLS 시스템 뷰를 쿼리하여 버퍼 풀 정보를 볼 수 있다.

SELECT * FROM SYSCAT.BUFFERPOOLS BPNAME BUFFERPOOLID NGNAME NPAGES PAGESIZE ES ------------------ ------------ ------------------ ----------- ----------- -- IBMDEFAULTBP 1 - 250 4096 N 1 record(s) selected.

어떤 버퍼 풀이 테이블 스페이스에 할당되었는지를 보려면 다음 쿼리를 실행한다.

SELECT TBSPACE, BUFFERPOOLID FROM SYSCAT.TABLESPACES TBSPACE BUFFERPOOLID ------------------ ------------ SYSCATSPACE 1 TEMPSPACE1 1 USERSPACE1 1 3 record(s) selected.

위의 Query 결과값에서 BUFFERPOOLID 를 사용하면 어떤 버퍼 풀이 어떤 테이블 스페이스과 연결되어 있는지 알 수 있다.

데이터베이스가 테이블 스페이스을 확보하는 방법

지금까지 테이블 스페이스과 버퍼풀이 무엇인지, 그리고 이들을 생성하는 방법을 설명했다. 이제는 이들이 데이터베이스 내에서 어떻게 구성되는지를 알아보자.

그림 1. 테이블 스페이스과 버퍼 풀

 

이 데이터베이스는 다섯 개의 테이블 스페이스을 갖고 있다. 카탈로그 테이블 스페이스, 두 개의 Regular 테이블 스페이스, Long 테이블 스페이스, 시스템 임시 테이블 스페이스. 그러나 사용자 임시 테이블 스페이스은 생성되지 않았다. 다섯 개의 테이블 스페이스에 속하는 여덟 개의 컨테이너가 있다.

이 시나리오에서 버퍼 풀들은 다음과 같이 할당된다.
BP1 (4K) ? SYSCATSPACE와 USERSPACE2
BP2 (8K)- USERSPACE1
BP3 (32K)- LARGESPACE와 SYSTEMP1

Section 2: 성능

일반적으로 물리적 장치에 테이블 스페이스과 컨테이너 배치를 설계할 때 I/O 병렬성과 버퍼 활용의 최대화에 초점을 맞추게 된다. 이 목표를 이루기 위해 데이터베이스 디자인과 애플리케이션에 대해 완벽히 이해해야 한다. 그런 다음에야 두 개의 테이블을 별도의 디바이스로 분리하는 것이 병렬 I/O를 일으킬 것인지의 여부, 또는 테이블을 별도의 테이블 스페이스에 생성하여 완전히 버퍼링 될 수 있는지 같은 문제를 결정할 수 있다.

새로운 데이터에 대한 물리적 레이아웃 설계는 테이블 스페이스을 구성하는 것으로 시작한다.

1. 첫 번째 단계는 테이블 디자인의 제약조건을 결정하는 단계이다. 이것은 한 개이상의 Regular 테이블 스페이스을 사용해야 할지도 모른다.
2. 두 번째 단계에서는 다른 설정값을 가진 테이블 스페이스에 테이블을 생성하는 것이 성능을 향상시키는 것인지 고려해야 한다.
3. 임시적인 테이블 스페이스 디자인이 완성되면 버퍼 풀 활용에 대해 생각해야 한다. 이전 테이블 스페이스 디자인을 수정할 수도 있다.
4. 마지막으로, 테이블 스페이스에 컨테이너를 할당한다.

이 프로세스는 반복적이고 스트레스 테스트와 벤치마킹을 통해 디자인을 검증 받아야 한다. 최적의 디자인은 강도 높은 노력을 통해 탄생하고 데이터베이스 퍼포먼스도 최상이어야 한다.

• 단순한 디자인에서 출발한다.
• 테스팅에 기반하여 충분한 이유가 있을 때만 복잡성을 추가하도록 한다.

가끔은 성능이 약간 저하된다 하더라도 데이터베이스에 대한 관리의 복잡성을 줄이고 데이터베이스 디자인을 단순화하는 것이 더 낫다. DB2는 매우 정교한 리소스 관리 로직을 가지고 있으므로 정교한 디자인 없이도 좋은 성능을 낸다.

테이블 스페이스 구성

카탈로그 테이블 스페이스과 시스템 임시 테이블 스페이스은 SMS로서 할당된다. 같은 페이지 크기를 가진 임시 테이블 스페이스을 한 개 이상 가질 필요가 없다. 최대 페이지 크기를 가진 한 개로 충분하다.

사용자 데이터를 다중 테이블 스페이스으로 나누어야 할 지의 여부가 의문스럽다. 고려해 볼 수 있는 것은 페이지의 활용이다. 한 행(row)은 페이지들간 나누어질 수 없기 때문에 긴 행을 가진 테이블은 적절한 페이지 크기가 필요하다. 하지만 한 페이지당 255 행 이상이 될 수 없기 때문에 짧은 행을 가진 테이블은 전체 페이지를 활용하지 않는다. 페이지 크기가 32K인 테이블 스페이스에 있는 행 길이 12 바이트의 테이블은 각 페이지의 10% 정도만 활용한다. (((255 행 * 12 바이트) + 91 바이트 오버헤드) / 32k 페이지 크기 = ~10%)

이는 테이블이 길 때 고려해야 할 것이다. 따라서 낭비되는 스페이스은 상당하다. 또한 I/O와 버퍼링의 효율성도 떨어진다. 각 페이지의 실제로 유용한 컨텐트는 작기 때문이다. 테이블이 작은 페이지 크기의 테이블 스페이스에 배치되고 큰 페이지를 활용한다면 가장 흔한 액세스 방식이 어떤 것이 더 나은지를 결정하게 된다. 많은 행들이 순차적으로 액세스 된다면(아마 테이블이 클러스터링 되어 있을 것이다.) 큰 페이지가 보다 효율적이다. 행이 랜덤으로 액세스 된다면 작은 페이지 크기가 버퍼를 더욱 잘 활용할 것이다.

테이블들이 페이지 크기로 그룹핑 되면 액세스 빈도와 유형으로 데이터를 개별 테이블 스페이스으로 그룹핑 할 것인지의 여부를 결정하게 된다. 각 테이블은 가장 빈번하게 액세스 되는 방식에 따라 가장 효율적인 테이블 스페이스 설정을 갖게 된다. PAGESIZE, EXTENTSIZE, PREFETCHSIZE, EXTENTSIZE는 데이터가 다음 컨테이너에 저장되기 전에 한 컨테이너에 저장될 데이터 페이지의 수이다. (한 테이블 스페이스에 여러 개의 컨테이너가 존재할 경우)

PREFETCHSIZE는 데이터 프리패치가 수행될 때 테이블 스페이스에서 읽어 들일 페이지의 수를 지정한다. 데이터베이스 매니저가 순차적 I/O가 적절하고 프리패치가 성능 향상에 도움이 된다고 결정하면 프리패치가 사용된다. PREFETCHSIZE 값은 테이블 스페이스의 EXTENTSIZE 값과 그 테이블 스페이스에 속하는 컨테이너 수의 곱의 배수로 설정하는 것이 좋다. EXTENTSIZE가 32이고 네 개의 컨테이너가 있다면 PREFETCHSIZE는 128, 256 등이 된다. 만약 자주 사용되는 테이블이 같은 테이블 스페이스에 존재하는 나머지 테이블과는 다른 성능 매개변수 값들을 요구한다면 이러한 테이블을 별도의 테이블 스페이스에 두는 것이 전체적인 성능을 향상시킬 것이다.

프리패치가 테이블 스페이스에 중요한 요소라면 블록 기반의 I/O에 대한 버퍼 부분을 남겨두는 것도 생각해 보라. 블록 크기는 PREFETCHSIZE와 같아야 한다.

버퍼 풀 활용

한 개 이상의 사용자 테이블 스페이스을 사용하는 가장 중요한 이유는 버퍼 활용을 관리하기 위해서 이다. 하나의 테이블 스페이스은 하나의 버퍼 풀만 사용할 수 있고 한 개의 버퍼 풀은 한 개 이상의 테이블 스페이스에 사용될 수 있다.

버퍼 풀을 튜닝하는 이유는 DB2가 버퍼에 사용할 수 있는 메모리를 최대한 활용할 수 있도록 하기 위해서 이다. 전체 버퍼 크기는 DB2 퍼포먼스에 중요한 영향을 미친다. 페이지가 많으면 많을수록 시간 소비가 가장 큰 I/O 작업이 현저히 줄어들기 때문이다. 하지만 총 버퍼 크기가 너무 크고 할당할 충분한 스토리지가 없다면 각 페이지 크기 별로 최소한의 버퍼 풀이 할당되고 성능은 저하될 것이다. 최대 버퍼 크기를 계산하려면 DB2 뿐만 아니라 OS와 다른 애플리케이션에서의 스토리지 활용도 고려해야 한다. 총 가용 크기가 결정되면 활용도를 높이기 위해 다른 버퍼풀로 나뉘어 질수도 있다. 다른 페이지 크기의 테이블 스페이스이 있다면 페이지 크기 당 최소한 한 개의 버퍼 풀이 있어야 한다.

한 개 이상의 버퍼 풀이 있다면 그 버퍼에 데이터를 보존할 수 있다. 예를 들어, 데이터베이스가 매우 빈번하게 사용되는 작은 테이블들을 갖고 있고 이들 전체 데이터가 버퍼에 있다면 매우 빠르게 액세스 될 것이다. 그러나 만약 매우 큰 테이블에 대해 실행되는 쿼리가 있고, 같은 버퍼 풀을 사용하고 총 버퍼 크기 보다 많은 페이지들을 읽는다고 가정해 보자. 쿼리가 실행되면 작고, 매우 빈번하게 사용되는 테이블에서 온 페이지들은 소실될 것이다. 이들이 다시 필요하게 될 때 다시 읽어 들여야 한다.

만약 작은 테이블들이 자신의 버퍼 풀이 있고 이로 인해 자기 소유의 테이블 스페이스도 가져야 한다면 메모리에 존재하는 이들 페이지는 큰 쿼리에 의해 더 이상 소실되지 않아도 된다. 비록 큰 쿼리에는 어느정도 부정적인 영향을 미치지만 이것은 전반적인 시스템 향상을 가져올 것이다. 매우 빈번한 튜닝은 전체 퍼포먼스 관점에서 볼 때 상쇄적인 측면이다. 시스템의 성능을 튜닝할 때 기능들에 대해 우선순위를 정하고 전체 throughput과 사용에 대해 항상 명심해야 한다.

데이터베이스를 중지하지 않고도 버퍼 풀 크기를 변경할 수 있는 기능이 V8에 새로 도입되었다. ALTER BUFFERPOOL 문에 IMMIDIATE 옵션을 사용하면 바로 적용된다. 그러나 데이터베이스 공유 메모리에 할당할 수 있는 충분한 보유스페이스이 없다면 바로 적용되지 못한다. 이 기능은 주기적인 변경에 따라 데이터베이스 퍼포먼스를 튜닝 할 때 사용된다.

물리적 스토리지 구성

테이블들이 테이블 스페이스으로 분산되면 물리적 스토리지를 결정해야 한다. 테이블 스페이스은 여러 컨테이너들에 저장될 수 있고 SMS나 DMS가 될 수 있다. SMS는 관리하기가 더 쉽고 작고 다양한 테이블들을 많이 포함하고 있는 테이블 스페이스(카탈로그 테이블 스페이스)에 알맞다. 이 테이블에 LOB가 포함되어 있다면 더욱 좋다. SMS 컨테이너를 한 번에 한 페이지씩 확장하는 오버헤드를 줄이려면db2empfa 명령어를 실행한다. 이것은 데이터베이스 설정 매개변수인 MULTIPAGE_ALLOC의 값을 YES로 설정한다.

DMS는 일반적으로 더 나은 성능을 보이고 인덱스와 LOB 데이터를 분리해서 저장할 수 있는 유연성도 제공한다. 하나의 테이블 스페이스을 구성하는 여러 컨테이너들은 각각 다른 물리적 불륨에 놓여질 경우 I/O 병렬성을 향상시킬 수 있으므로 가능한한 분리해서 놓는 것이 좋다. 여러 사용자 테이블 스페이스과 여러 장치들이 있다면 애플리케이션 로직을 고려하여 워크로드가 장치들에 고르게 분배될 수 있도록 한다.

RAID 디바이스는 주의해야할 고려 사항들이 있다. EXTENTSIZE는 RAID 스트라이프 크기와 같거나 배수여야 한다. PREFETCHSIZE는 RAID 병렬 디바이스의 수 ( 또는 배수 ) 와 RAID 스트라이프 크기의 곱이여야 한다. DB2에는 레지스트리 변수들이 있는데 이것은 특정 환경을 향상시킨다. 다음 명령어를 실행하면 I/O 병렬성이 단일 컨테이너 내에서도 가능해 진다.

db2set DB2_PARALLEL_IO=*

또 다른 레지스트리 변수인 DB2_STRIPED_CONTAINERS=ON 은 컨테이너 태그 크기를 한페이지에서 전체 EXTENT 로 변경하여 RAID 스트라이프로 테이블 스페이스 EXTENT 를 구성할 수 있다.

다른 성능 평가와 마찬가지로 변경이 효과적인 결과를 가져올 것인지 알수 있는 확실한 방법은 벤치마크를 수행하는 것이다. 물리적 구성 변경의 경우 다소 복잡하다. 테이블 스페이스을 변경하는데 노력이 많이 든다. 가장 실질적인 방법은 디자인 단계에서 케이스의 수를 줄여서 나중에 벤치마크에도 적은 케이스만 쓰이도록 하는 것이다. 퍼포먼스가 중요할 경우에는 시간과 노력을 많이 들여도 좋다. 디자인 마다 퍼포먼스 차이가 상당하다. 버퍼 풀에 중요성을 두어야 하며, 이들은 가상 메모리에 할당되어서는 안되며 가장 효율적인 방식으로 사용되어야 한다.

데이터베이스 옮기기

다른 시스템으로 옮기기 전에, 시스템이 같은 종류의 플랫폼일지라도 데이터베이스의 매개변수와 물리적 구성은 언제나 평가되어야 한다. 실제 상황에서 DBA는 1 GB 스토리지를 가지고 있는 Window 서버에서 잘 Tuning된 데이터베이스를 256 MB 스토리지를 가지고 있는 랩탑으로 옮긴후에 서버에서는 연결 하는데에 몇초 걸리지 않았던 것이 옮긴후에 45분이나 걸렸다. 이 문제는 버퍼 풀 크기와 다른 메모리 매개변수들을 줄여서 해결되었다.

플랫폼이 다르다면 문제도 달라진다. 유닉스와 Windows간 이동일 경우, 한 시스템에서 최적 조건이 다른 시스템에서는 그렇지 않을 수도 있다. 데이터베이스를 복사한다면 반복적으로 튜닝을 해야 한다. 데이터베이스를 zSeries ^TM으로 옮겨야 한다면 해당 매뉴얼과 레드북을 참고해야 한다. iSeries 시스템에서 물리적 설정과 튜닝은 데이터베이스 환경 밖에서 함께 수행되고 iSeries ^TM 시스템 관리 매뉴얼을 참조해야 한다.

결론

이 글에서는 데이터베이스 디자인과 퍼포먼스에 대한 극히 일부분만을 설명했다. 쿼리 최적화와 애플리케이션 고려사항까지 들어가지 않고 데이터베이스 디자인 문제들을 집중적으로 설명했다. 데이터베이스 설계는 가장 우선적인 일이다. 따라서 초기 플래닝은 포괄적이어야 한다. 여러분에게 도움이 되도록 온라인 지침서도 마련해 두었다.