database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
ㆍDB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DB2 Tutorials 234 게시물 읽기
No. 234
Tablespace Performance Guide
작성자
정재익(advance)
작성일
2001-12-17 20:13
조회수
8,743
첨부파일: SMSDMS.doc (788,480bytes)

Tablespace Performance Guide

 

SMS vs DMS

 

1. 테이블 공간의 성능상 고려사항

 

DB2에서 정의될 수 있는 테이블 공간은 SMS(System Managed Space)와 DMS(Database Managed Space) 두가지이다. 이 중의 어떤 형태로 테이블 공간을 구성하는가는 성능, 관리상에서 차이를 보이게 되는데 그 결정을 내리는데 있어 필요한 정보와 고려사항을 알고 있다면, 해당 시스템에서 좀 더 효율적인 선택을 내릴 수 있을 것이다.

이 문서에서는 상황에 따라 두가지 테이블 공간 관리 방법 중 어떠한 것을 사용하는 것이 더 유용한지와 테이블 공간을 사용하는데 있어서 좀 더 효과적인 방법을 쓸 수 있도록 각각의 특징을 살펴보도록 하겠다.

 

1.0 테이블 공간

 

"데이터베이스는 테이블 공간이라는 부분으로 구성됩니다. 테이블 공간은 테이블을 저장할 장소입니다. 테이블 작성시 나머지 테이블 데이터와는 별개로 색인과 대형 오브젝트(LOB) 데이터와 같은 특정 오브젝트를 유지하도록 결정할 수 있습니다. 또한 테이블 공간은 하나 이상의 물리적 저장 장치에 걸쳐 있을 수 있습니다. 다음과 같은 그림은 테이블 공간에서 데이터를 전개하는 유연성의 일부를 보여줍니다."

- DB2 UDB v7.1 관리 안내서 중에서

 

1.1 SMS 테이블 공간

SMS 방식의 테이블 공간은 운영체제의 디렉토리가 컨테이너가 된다. 이 방식의 특징은 UNIX 계열의 운영체제는 파일 시스템을 추가함으로써 테이블 공간의 크기를 쉽게 늘릴 수가 있고, Intel칩 계열의 운영체제는 테이블 공간이 위치하는 드라이브의 공간이 허용하는 한 테이블 공간의 크기가 자동으로 증가된다.

데이타는 각 컨테이너에 extent 크기만큼 나뉘어서 저장되고, 디폴트 값이라면 저장 공간은 한 번에 한 페이지씩 할당된다.

 

SMS 방식의 테이블 공간에서 데이타 오브젝트(테이블 데이타, 색인, Longvarchar, LOB)는 운영체제의 파일 이름을 갖는다.

각 컨테이너(디렉토리)는 서로 다른 파일 시스템에 위치시키는 것이 좋다. 그렇지 않으면, 테이블 공간의 용량은 하나의 파일 시스템에 의해 제한될 수 있기 때문이다.

 

다수의 컨테이너가 존재할 때, 다른 컨테이너 보다 커다란 컨테이너가 있다면 그 컨테이너는 다른 컨테이너에 비해 초과되는 분량만큼 더 많은 자원과 시간을 필요로 한다. 따라서 각 컨테이너들을 동일한 크기로 할당하는 것이 좋다.

 

SMS 방식의 테이블 공간은 다음과 같은 잇점을 갖는다.

- 공간이 필요시에 할당된다.

- DMS 방식에 비해 데이터베이스 생성시 초기화 작업이 간단하다(DMS 컨테이너 정의가 불필요).

1.2 DMS 테이블 공간

컨테이너는 운영체제의 파일 혹은 raw device가 될 수 있다.

가능하다면 각 컨테이너를 서로 다른 디스크에 위치시키는 것이 좋다. 이렇게 하면 병렬 I/O가 가능하고, 보다 큰 테이블 공간을 만들 수 있다.

 

DMS 방식에서는 ALTER TABLESPACE ADD CONTAINER 혹은 DB2 V7.1부터ALTER TABLESPACE 에 추가된 두가지 구문 resize, extend에 의해 컨테이너를 증가시킬 수 있다.

 

테이블 공간에 DMS device 컨테이너를 사용할 때, 다음과 같은 성능상의 고려사항을 이해할 필요가 있다.

 

- DMS file 컨테이너 대해 파일 시스템 caching이 운영체제에 의해 수행된다. AIX의 경우는 JFS 캐쉬다.

- DMS device 컨테이너에 대한 파일 시스템 caching은 일어나지 않는다.

 

DMS 방식의 테이블 공간은 다음과 같은 잇점을 갖는다.

 

- 컨테이너를 추가하고 확장할 수 있다.

- 커다란 테이블은 데이타를 형식(LOB, 색인, 데이타)에 따라 여러 테이블 공간에 걸쳐 저장할 수 있다.

- 디스크에 위치하는 DMS device는 논리 볼륨 관리자를 사용하여 조정할 수 있다.

- 대부분의 경우 SMS비해 나은 성능을 보인다.

 

1.3 SMS vs DMS

SMS와 DMS 중 어느 방식을 쓸 것인가를 결정하는 문제는 고려해야 할 사항이 다양하기 때문에 상황에 따라 달라진다. 하지만, 만약 성능을 우선시 한다면 DMS방식의 device 타입을 사용하는 것이 좋다. 데이타베이스가 파일시스템을 통해 작업을 하는 것 보다 직접 디스크 블럭에 접근하여 작업을 하는 것이 성능에 좋은 까닭이다.

하지만, 상황에 따라 각 방식의 장점을 따져서 좀더 알맞은 형식을 선택하는 것이 무엇 보다 중요하다.

 

DMS 방식의 raw device를 사용하면 DB2는 디스크 상에 페이지를 인접시켜 위치시킨다. 반면에 SMS 방식과 DMS방식의 file은 페이지를 어디에 위치시킬지를 파일 시스템이 결정한다. 페이지를 인접한 곳에 위치시키는 것은 테이블 스캔과 같은 작업에 상당한 속도향상을 가져오기 때문에, DMS device 방식을 쓰는 것이 성능향상에는 더 좋다.

 

1.4 데이타 테이블용 테이블 공간 선택하기

I/O를 통한 작업효율을 최대화하는 등 최적화된 성능을 발휘하기 위해서 어떤 타입의 테이블 공간을 선택할 지 결정하기 위해서 다음의 개념을 이해해야할 필요가 있다.

 

- big block 읽기 : 한 번의 요청에 몇 개의 페이지(보통 한 extent)가 동시에retrieve된다.

 

- prefetch : 쿼리 회답 속도를 줄이기 위해 페이지 미리 읽어오기.

 

- page cleaning : 메모리에 새로운 페이지를 위한 공간을 만들기 위해 buffer pool의 수정된 페이지 를 디스크에 쓰기.

 

DB2는 한번의 작업에 데이타 읽기 성능을 극대화하기 위해서 가능하다면 big block 읽기를 하려 한다. DMS device 컨테이너를 사용하게 되면, 데이타는 대부분의 경우 디스크에 인접하게 위치하게 되고 이렇게 되면 탐색시간을 줄일 수 있다. 반면에 SMS혹은 DMS file 방식의 컨테이너를 사용하면 운영체제의 파일 시스템이 파일을 조각내는 경우가 발생할 수도 있고, 하나 또는 여러 디스크의 다른 위치에 저장할 수도 있다. 이는 파일이 fragment되는 것을 의미한다. 이렇게 되면 읽기 성능이 저하되는 것은 말할 필요도 없다

 

1.4.1 데이타 테이블 공간

 

raw 데이타와 색인은 일반 사용자 데이타로 분류된다. 이러한 타입은 성능을 극대화하기 위해서라면 DMS device를 사용하는 것이 좋다. SMS 방식은 기본적으로 성능을 생각하기 보다는 관리상의 편의에 더 중점을 두는 방식이다. 하지만 V7.1부터 DMS 방식에도 컨테이너 크기를 늘릴 수 있는 방법이 추가되었기 때문에, DMS 방식의 관리도 많이 향상되었고 볼 수 있다.

 

그러나 long 데이타(LOB, longvarchar, longvargraphic)의 경우는 DMS device방식을 사용하기 보다 DMS file 혹은 SMS 방식으로 사용하는 것이 좋다. long 데이타는 기본적으로 buffer pool을 사용하지 않기 문에 위의 두 방식을 사용하게 되면 파일 시스템의 캐쉬를 사용할 수 있는 잇점이 있다. 하지만 long 데이타만 별도의 테이블 공간에 저장할 수 있다는 점에서 SMS 보다는 DMS file 형태가 더 바람직 하다고 할 수 있다.

 

1.4.2 임시 테이블 공간

거의 모든 시스템에서 SMS 방식이 사용자 임시 테이블 공간과 시스템 테이블 공간에 적합한 타입이다, 임시 테이블 공간을 SMS 방식으로 사용하면 얻을 수 있는 가장 큰 잇점은 임시테이블 자체의 특성과 관련이 있다. 임시 테이블 공간에 저장되는 데이타는 거의 대부분 순간적으로 생성되었다가 사라지는 데이타이기 때문에 필요한 순간에만 디스크 공간이 할당될 필요가 있다. SMS 방식은 필요시에 한 페이지씩 할당을 하기 때문에 임시 테이블 공간의 성격에 적합하다. 반면에 DMS방식으로 사용한다면, 미리 디스크를 할당해 놓아야 하기 때문에 디스크의 낭비가 발생한다. 따라서 SMS 방식을 쓰는 것이 디스크를 효율적으로 사용할 수 있는 방법이 된다.

 

만약 서로 다른 페이지 크기를 가진 테이블 공간이 존재한다면, 가장 큰 데이타 테이블의 페이지 크기와 같게 임시 테이블 공간 하나를 만드는 것이 좋다. 예를 들어 4k와 32k 의 페이지 크기로 이루어진 두개의 테이블 공간이 있다면, 32k의 페이지 크기로 임시 테이블 공간을 만드는 것이 바람직하다는 얘기다. 4k짜리 테이블 공간은 32k의 테이블 공간에 얼마든지 포함될 수 있지만, 32k의 테이블 공간은 그렇지 못하기 때문이다.

하나의 임시 테이블 공간을 만드는 것은 다음의 이유에서 필요하다. 만약 같은 크기의 페이지를 사용하는 여러 임시 테이블 공간이 존재한다면, DB2 optimizer는 그 중에 큰 buffer pool을 갖는 임시 공간을 사용하게 된다.

 

1.4.3 카탈로그 테이블 공간

시스템 카탈로그에는 LOB 데이타가 포함되어 있다. 데이타베이스 관리자가 LOB 데이타의 페이지를 retrieve해야할 필요가 있다면 buffer pool과 같은 데이타 베이스에서 제공하는 캐쉬를 사용할 수 없다. 따라서 이러한 경우에는 성능을 향상시키기 위해서 SMS 혹은 DMS file 방식의 컨테이너를 사용하는 것이 파일 시스템의 buffering을 조금이라도 사용할 수 있게 해 주기 때문에 바람직하다. 따라서 카탈로그 테이블 공간은 SMS 혹은 DMS file을 사용하는 것이 좋다.

또한, 작은 extent 크기(2 혹은 4 페이지) 를 갖는 것이 좋은데, 그 이유는 다음과 같다. 카탈로그 테이블은 연관성이 많은 작은 테이블들로 구성되어 있는데, DMS 방식을 쓰게 되면 테이블당 기본적으로 2개의 추가 페이지(Extent Map Page + 첫번째 extent)가 필요한 반면 SMS는 1 페이만 있으면 된다.

 

1.5 테이블 공간과 테이블의 수 결정하기

데이타베이스를 설계하는 데 있어서 가장 일반적인 질문은 "하나의 테이블 공간에 몇개의 테이블을 넣어야 하는가?" 혹은 "몇개의 테이블 공간을 만들어야 하는가?" 일 것이다. 이러한 물음의 결과 어떻게 나오더라도 그것은 특정 테이블과 테이블 공간의 성능에 상당한 영향을 미치게 되는데, 보다 나은 성능을 위해서 위의 질문에 대해 어떻게 결정을 해야 좋은 지에 대해서 알아보자.

 

다음은 테이블을 어떻게 위치시킬 것인지에 대한 고려사항이다.

 

- 테이블 공간을 복구하는 데 있어서 RI(Referential Integrity) constraints 혹은 summary 테이블이 포함되어 있는 테이블 공간이고, 그 테이블을 복구해야 할 필요가 존재한다면 이 테이블들은 모두 한 시점까지(point in time) roll forward되어야 한다. 그렇게 되지 않으면 check pending에 빠지게 된다.

 

- 만약 DMS 방식의 테이블 공간이고 하나의 테이블이 여러 테이블 공간에 걸쳐서 작성 (예를 들어, 일반 데이타는 한 테이블 공간에, 색인은 다른 테이블 공간에, LOB 데이타는 다른 공간에 저장된 형태) 되었다면, 색인을 별도의 테이블 공간에 두었기 때문에 색인용 buffer pool을 따로 줄 수가 있다. 이렇게 되면 색인 페이지를 별개의 메모리에 올려 놓고 사용할 수 있다.

 

- 테이블에 얼마나 많은 row 데이타가 있는가도 중요하다. 작은 양의 데이타를 갖는 작은 테이블이 많이 있고 잦은 변경이 일어나지 않는다면, 이러한 테이블들을 하나의 테이블 공간에 모아 두는 것이 좋다. 많은 데이타를 갖고 잦은 변경이 일어나는 테이블은 한DMS 방식의 테이블 공간에 두는 것이 좋다. 성능 측면에서 하나의 테이블 공간에 대형 테이블 하나를 위치시키는 것은 전용 bufferpool을 사용할 수 있기 때문에 성능이 좋아진다.

 

- 중요한 테이블의 경우 전용 테이블 공간에 두는 것이 바람직하다. DB2는 테이블 공간 별로 백업과 복구가 가능하기 때문에, 이러한 테이블을 하나의 테이블 공간에 할당해 놓으면 관리에 용이해지고, 복구가 필요할 경우 빠르게 복구할 수 있다. 또한 필요한 경우 전용 bufferpool을 사용할 수 있다.

 

- 자주 사용되지 않는 데이타는 비교적 성능이 좋지 않은 컨테이너를 사용하는 것이 가격대 성능비로 볼 때 바람직하다.

 

- 복구 작업을 비교적 간단하게 수행하기 위해서 테이블 공간간에 RI와 같은 관계를 최소화하는 것이 바람직하다.

 

- 테이블 공간의 한계 용량을 고려해야 한다. V.71 EE(Enterprise Edition) 의 경우 62GB( 4k 페이지), 128GB(8k 페이지), 512GB(32k 페이지)이고, long 테이블 공간은2TB 이다. EEE는 한 파티션 당 위의 숫자만큼이다.

 

- 현재 남아 있는 공간을 고려해야 한다. 테이블을 reorg할 때 현재 사용하고 있는 테이블 공간을 이용하는 것이 임시 테이블 공간을 사용하는 것 보다 빠르다. 임시 테이블 공간을 사용하게 되면 임시 테이블 공간에 기록한 후 다시 원래 테이블로 복사해와야 하기 때문에 시간이 더 걸리게 된다.

 

- 모니터링이 비교적 많이 필요한 테이블은 전용 테이블 공간을 사용하는 것이 좋다. List Tablespaces show detail 명령어를 사용하면 현재 테이블이 사용하고 있는 페이지 수와 남은 페이지 수등을 알 수 있다. 따라서 실제 테이블이 얼마나 증가하는 지를 쉽게 파악할 수 있다.

 

- 전체 테이블 공간의 숫자는 최소화하는 것이 바람직하다.

 

1.5.1 "연관된" 테이블 공간의 복구 가능성

 

테이블을 테이블공간에 할당할 때, 테이블 공간을 복구해야 할 필요가 있다면 다른 테이블 공간과의 "연관성"은 중요한 고려사항이 된다. 예를 들어, 현재 TS1, TS2라는 두개의 테이블 공간을 사용하고 있다면, 필요에 따라TS1을 백업 이미지로 부터 복구를 하고 필요한 시점까지 roll-forward하고 나서 생각해 보니 TS1에 TS2에 존재하는 테이블의 요약 테이블이 있었다면, 현재 TS1과 TS2의 시점이 다른 상황이기 때문에 TS1의 요약테이블은 check pending 상태에 빠지게 된다.

 

1.6 테이블 공간 컨테이너 선택하기

DB2에서 컨테이너란 데이타가 실재로 저장되는 물리적 저장장치이다. 각 컨테이너는 하나의 테이블 공간에 할당이 되고, 테이블 공간은 복수의 컨테이너를 가질 수 있다. 컨테이너는 file, directory, device가 될 수 있고, 테이블 공간에 어떤 타입의 컨테이너를 사용하던 간에 데이터는 컨테이너에 존재하게 된다. 만약 하나의 테이블 공간에 여러 컨테이너 타입을 섞어서 사용한다면 성능면에 있어서 좋지 않은 결과를 가져오게 된다.

 

각 컨테이너 타입을 벤치마킹한 결과 device(raw logical volume) 타입의 컨테이너가 directory 혹은 file(JFS file system)에 비해 10-35% 가량 디스크 I/O를 줄일 수 있는 것으로 나타났다. 물론 이 결과치는 상황(I/O workload, 각종 어플리케이션,....) 에 따라 많은 다양성을 나타낼 수 있다.

대량의 불규칙적인 I/O를 일으키는 OLTP 환경에서는 DMS device(raw logical volume) 를 사용하는 것이 성능면에서 바람직하고 반면에, 대량의 연속적 I/O가 일어나는 DSS(Decision Support System) 환경에서는 DMS file 혹은 SMS를 사용하여JFS 파일 시스템의 연속적(sequential) read-ahead 속성을 사용하는 것이 더 나을 수도 있다. 하지만, DSS 환경이라 할 지라도 DMS device를 사용하여 DB2가 페이지를 연속적으로 위치시킬 수 있게끔 하는 것이 더 나을 수도 있다(prefetch 측면에서).

 

1.6.1 directory

directory는 SMS 방식의 테이블 공간 관리 방법에서만 사용할 수 있고, 만드는 시점에 모든 컨테이너(directory)를 결정해야 하며, 일단 만들어지고 나면 새로운 컨테이너를 추가할 수 없다. 이러한 타입의 컨테이너를 사용함에 있어 성능을 향상시키고자 한다면 병렬 I/O를 발생시키기위해 다른 물리적 드라이브에 각각의 컨테이너를 위치시켜야 한다.

 

 

1.6.2 file

file은 DMS 방식의 테이블 공간 관리 방법에서 사용 가능하고 크기는 미리 결정되어야 한다. DMS는 기본적으로 file과 device를 동일한 방법으로 처리한다. file이 테이블 공간이 생성되는 시점에 만들어지고 크기가 할당이 된다고 하더라도 운영체제의 파일 시스템은 여전히 파일을 조각낼 수 있는 가능성을 지닌다. 따라서 어떠한 경우에 페이지가 불연속적으로 위치할 가능성이 생긴다. 이렇게 되면 성능에는 나쁜 영향을 일으키게 된다.

 

DMS 테이블 공간을 사용한다면 대부분의 경우 file 컨테이너는 device 컨테이너에 비해 성능상 떨어지는 결과를 보이게 된다. 그 이유는 file 컨테이너의 경우 데이타베이스 관리자가 컨테이너를 다루는 데 있어서 device 컨테이너와 달리 운영체제의 파일시스템 레이어를 통해야 하기 때문이다.

이와 같은 일반적인 경우의 예외로 LOB 데이타를 포함하고 있는 컨테이너는 file 방식을 사용할 것을 더 권장한다. device 방식과 달리 file 방식은 운영체제의 파일 시스템의 캐쉬를 사용할 수 있기 때문이다.

 

1.6.3 device

AIX에서 device 컨테이너는 raw logical volume이다. 이 방식의 컨테이너는 DMS에서만 쓸 수 있다. device 방식은 만들어질 때 크기가 미리 할당된다는 것은 file 방식과 마찬가지이지만, DB2가 raw device를 직접 조작, 관리한다는 것이 다르다. 이렇게 되면 데이타 페이지의 연속성을 보장할 수 있게 되는 장점이 있다.

만약 성능을 최대화하는 것이 목적이라면 device 컨테이너를 사용하는 것이 좋다. 단, 앞에서 언급된 것과 같이 LOB 데이타의 경우는 예외이다.

 

성능 측면에서, 다음과 같은 도식이 가능하다.

Device > File
Device(LOB 데이타 포함) < File(LOB 데이타 포함)

 

DMS device 방식과 SMS 혹은 DMS file방식을 혼용해서 쓰는 것은 이중 buffering이 발생하기 때문에 자원의 낭비가 발생한다. 따라서 이와 같은 방식으로 쓰는 것은 좋지 않다.

 

1.7 테이블 공간 컨테이너 구성

테이블 공간을 구성하기 전에 컨테이너의 구성이 테이블 공간 전체 성능에 어떤 영향을 줄 것인가에 대해 생각해 볼 필요가 있다. 지금부터 테이블 공간 컨테이너 구성의 중점사항을 살펴보도록 한다.

 

1.7.1 디스크 고려사항

데이타 저장에 사용할 물리적 디스크의 갯수는 실재 저장될 데이타가 얼마냐에 따라 달라지는데, 성능 측면에서 보자면 DB2가 병렬 I/O를 일으킬 수 있도록 복수개의 디스크를 컨테이너로 사용하는 것이 바람직하고, 물리적 디스크를 하나의 컨테이너로 설정하는 것이 더 좋다. 예를 들어, 고속의 저장장치로 컨테이너를 구성하고, 물리적 디스크에 복수의 컨테이너를 설정하는 것보다, 비교적 저속 저장장치지만 물리적 디스크 하나를 컨테이너 하나로 설정하는 것이 병렬 I/O를 발생시키기 때문에 더 좋은 성능을 보인다.

 

OLTP 와 같은 불규칙적인 엑세스가 일어나는 환경에서는 쓰기 작업(지속적인 append 작업) 이 주 작업이다. 따라서 속도에 대한 문제 보다는 저장할 수 있는 저장장치의 용량 증가가 더욱 큰 문제이다. 또한 이것은 지속적으로 새로운 디스크가 필요하기 때문에 읽기 작업보다 훨씬 고가의 비용이 들어간다. 따라서 하나의 디스크에 읽기/쓰기의 비율을 고려해서 많은 수의 저장 장치를 갖춰야할 필요가 있다.

 

DSS와 같은 순차적인 엑세스가 일어나는 환경에서는 OLTP와는 달리 데이타를 읽는 작업이 주요 관심사이다. 이는 디스크의 I/O 속도에 크게 의존적이다. 따라서 OLTP 시스템 보다 디스크 수는 적게 필요하지만 좀더 효율적인 데이타 retrieve 속도를 필요로 한다. 따라서 고속의 저장장치가 필요하고, 디스크 caching이나 prefetch를 신경써야 한다.

그 밖의 고려사항으로는 다음과 같은 것들이 있다.

 

- 가능하다면 보다 많은 디스크에 테이블 공간을 펼쳐서 디스크 I/O가 병렬로 일어날 수 있기 한다. 빈번히 조회가 일어나는 대형테이블은 하나의 디스크에 두어서는 않된다.

 

- 사용할 수 있는 디스크의 수가 많지 않다면, 하나의 디스크에 하나의 테이블 공간을 할당하는 것 보다는 모든 디스크에 모든 테이블 공간을 할당하는 것이 성능에 더 좋다.

 

1.7.2 overhead 와 transfer rate

 

create tablespace나 alter tablespace 명령문을 통해서 결정할 수 있는 두가지 구성 변수가 있는데 이는 테이블 공간 컨테이너의 성능에 영향을 미친다. 이 정보는 SYSCAT.TABLESPACES 카탈로그 테이블에 저장되어 있다.

 

DB2 optimizer는 특정 테이블 공간의 데이타를 엑세스하는 I/O cost를 이 두가지 구성변수를 통해 결정한다. 예를 들어 색인을 이용할 것인가, 조인을 할 것인가 조인을 한다면 어떤 방식의 조인을 할 것인가를 결정하는데 overhead와 transfer rate를 참조한다.

 

1.7.2.1 overhead

 

overhead는 데이타가 메모리로 올라가기까지 컨테이너(물리적 디스크)에 필요한 시간으로 미리초 (milliseconds) 로 표현된다. 다음 도식은 overhead를 계산하는데 사용할 수 있다.

 

overhead = 평균 검색 시간(milliseconds) + (0.5 * rotational latency)

 

rotational latency = (1 / 디스크의 RPM) * 60 * 1000

 

만약 디스크의 RPM이 10000 이라고 한다면,

rotational latency = (1 / 10000) * 60 * 1000 = 6.0 milliseconds이다.

 

만약 이 디스크 타입의 평균 검색 시간을 5.4 milliseconds 라고 한다면 전체 overhead는 다음과 같다.

overhead = 5.4 + (0.5 * 6.0) = 8.4 milliseconds

 

1.7.2.2 transfer rate(전송률)

 

transfer rate는 데이타 한 페이지가 메모리로 올라가는 시간으로 역시 미리초(milli -seconds) 로 표현된다.

 

하나의 물리적 디스크에 테이블 공간 콘테이너가 있다고 가정할 때 "DB2 UDB 관리 안내서 : 성능"에 있는 transfer rate 산출을 위한 다음과 같은 도식을 사용할 수 있다.

 

transfer rate = ( 1 / spec_rate ) * 1000 / 1024000 * pagesize

 

spec_rate는 전송률(MB/sec)에 대한 하드 디스크 설명서를 참조하도록 한다.

pagesize는 이 물리적 디스크를 컨테이너로 사용할 테이블 공간의 페이지 크기이다.

 

DB2는 다음과 같은 디폴트 값을 사용한다.

 

overhead = 24.1 milliseconds

transfer rate = 0.9 milliseconds

 

만약 여러 디스크를 하나의 테이블 스페이스에 컨테이너로 할당하였을 때는 동일한 overhead와 transfer rate를 갖도록 하는 것이 좋다. 다시 말하면, 동일한 물리적 디스크를 쓰는 것이 더 나은 결과를 보이게 된다.

 

만약에 디스크들의 크기가 같지 않은 상황이거나, 위의 도식에 필요한 하드웨어적 문서정보를 갖고 있지 않은 상황이라면, 테이블 공간의 모든 물리적 디스크의 평균값으로 overhead를 책정하는 것이 바람직하다.

transfer rate는 OLTP 환경의 경우 임의로 하나의 디스크에 맞추거나 가장 속도가 느린 디스크에 맞춰서 설정하는 것이 좋다. DSS 환경의 경우 모든 디스크의 합계를 내어 설정하는 것이 좋다. OLTP와 DSS가 공존하는 환경이라면 위의 OLTP 혹은 DSS상황 중 하나로 설정하는 것이 바람직하다.

 

1.7.3 페이지 크기

테이블 공간의 전체 성능은 create tablespace 명령문에서 설정하는 페이지 크기에 상당한 영향을 받는다. 테이블 공간내의 각 테이블에 어떠한 workload를 갖는 데이타가 들어가느냐에 따라 최적의 페이지 크기를 정할 수 있을 것이다.

OLTP환경의 경우 작은 크기로 페이지를 설정하는 것이 buffer pool의 공간활용에 더 좋다. 하지만 만약에 업무 성격이 OLTP 보다 DSS라면 페이지 크기를 크게하는 것이 성능에 더 좋을 수 있다.

DSS환경에서 실재 테이블이 위치한 테이블 공간의 페이지 크기와 임시 테이블 공간의 페이지 크기를 맞추는 것이 바람직하다.

하지만, 다음과 같은 예외가 있을 수 있다.

DSS 환경이라 하더라도 한 페이지당 들어갈 수 있는 row의 수가 255로 제한되기 때문에 255 row의 데이타 크기가 한 페이지 보다 작으면 각각의 페이지에 공간 낭비가 발생할 수 있다. 이러한 경우에는 페이지 크기를 작게하는 것이 더 효율적이다.

또한 데이타베이스 관리자는 페이지당 크기와 상관없이 76byte의 제어 정보를 할당한다는 것도 고려해야 한다.

 

페이지 크기를 크게 사용하면 더 많은 색인키가 색인의 각 leaf 페이지에 들어갈 수 있기 때문에 색인의 레벨을 감소시킬 수 있다. 하지만 각 색인 페이지에 들어갈 수 있는 색인 entry수가 255로 제한되어 있기 때문에 색인 키의 크기가 작다면, 페이지크기가 클수록 공간의 낭비가 올 수 있다.

 

만약, 데이타베이스 내에 다양한 크기의 페이지 크기를 사용하고 임시 테이블 공간을 사용하여 테이블을 reorg할 필요가 있다면, 해당 테이블의 페이지 크기와 동일한 임시 테이블 공간이 있어야 한다.

 

다음은 페이지 크기에 따른 row의 최대 길이와 최대 컬럼 수이다.

페이지크기 row의 최대 길이	최대 컬럼 수
4 KB	4,005 bytes 	500
8 KB	8,101 bytes 	1012
16 KB	16,293 bytes	1012
32 KB	32,677 bytes	1012

1.7.4 extent 크기

extent 크기란 DB2가 다음 컨테이너에 데이타를 쓰기 전까지 하나의 컨테이너를 사용하는 페이지 크기이다.

DMS 방식을 사용할 때, extent 크기에 해당하는 공간을 한번에 할당하고, 할당된 extent를 다 쓰고나면, 다음 extent 를 통째로 할당한다. 반면에 SMS 방식에서는 한번에 한 페이지씩만 할당을 한다.

 

이러한 개념에 의해 테이블 공간의 성능이 크게 좌우될 수 있는데, 하나의 테이블 공간에 하나의 그룹으로 묶고 싶은 작은 테이블들이 많이 있다고 가정해 보자.

만일 DMS 방식이라면 새로운 테이블을 만드는 순간에 두개의 페이지(다음 그림을 참조)가 할당된다. 데이타의 크기가 크다면 상관이 없겠지만, 작은 양의 데이타라면 두개의 페이지는 낭비라고 할 수 있다.

따라서 이러한 상황이라면, extent 크기를 작게 설정하는 것을 권장한다. 혹은 성능문제가 그렇게 중요하지 않은 상황이라면 SMS 방식을 사용하는 것이 바람직하다.

 

디폴트 extent 크기인 32 페이지는 대부분의 시스템에서 무리없이 사용할 수 있지만, 다수의 작은 테이블로 구성된 테이블 공간이라면 줄이는 것이 바람직하다.

 

query-only 테이블이거나 데이타의 증가 속도가 빠르다면 extent 크기를 크게 하는 것이 성능에 좋다.

 

1.7.5 prefetch 크기

 

prefetch 크기를 잘 설정해 놓으면 데이타베이스 관리자로 하여금 미리 페이지를 읽어 실행시 수행 속도를 향상시킬 수 있다. prefetch의 디폴트 값은 데이타베이스 구성 변수인 DFT_PREFETCH_SZ에 정의된다.

대부분의 환경에서 prefetch 의 권장 크기는 (컨테이너 수 * extent 크기)이다. 최적화된 병렬 프리페치를 위해서 테이블 공간의 컨테이너가 각각 독립적 물리 디스크에 위치해야 한다. 이것은 DMS device 방식을 사용할 때 특히 중요한데, 그 이유는 운영체제의 caching이나 prefetch를 사용할 수 없기 때문이다.

 

좀더 적극적으로 prefetch를 사용하려면 권장 크기의 배수로 사용하는 것이 바람직하다.

 

그 밖에 NUM_IOSERVERS라는 구성변수가 있는데, 이는 데이타베이스에서 prefetch를 수행하는 I/O 서버 수를 정해 주므로써, 보다 효율적으로 prefetch를 할 수 있게 한다.

일반적으로 NUM_IOSERVERS는 물리적 디스크의 갯수로 설정한다.

 

만약 prefetch를 사용하고 싶지 않다면, alter tablespace 명령에서 prefetch를 0으로 설정하여 사용할 수 있다.

 

1.8 그 밖의 고려사항

- 테이블 공간의 수는 가능한한 작게 한다.

 

- log 파일에 대해서도 색인과 사용자 데이타와 마찬가지로 DMS device 방식을 쓰는 것이 성능에 좋다.

 

지금까지 tablespace의 구성에 대해 참고해야 할 다양한 고려사항을 살펴 보았다.

DB2에서는 조인의 요건이 발생하는 모든 테이블을 하나의 데이타베이스로 구성하기를 권장한다. 하나의 데이타베이스로 묶여 관리가 되지만 테이블 공간을 어떻게 구현하느냐에 따라 다양한 형태의 구성이 가능해진다. 그렇다면 이러한 다양한 형태를 어떻게 적용할 것인가?

위에서 언급된 내용은 어디까지나 권장사항일 뿐이다. 사용자는 위의 내용을 참고하여 자신의 시스템에 가장 적합한 테이블 공간을 작성하고 관리해야 할 것이다.

[Top]
No.
제목
작성자
작성일
조회
237ASP for DB2 UDB vs. JSP for DB2 UDB
정재익
2001-12-17
8782
236DB2 Java Stored Procedures Learning by Example
정재익
2001-12-17
8249
235DB2 UDB 성능 가이드
정재익
2001-12-17
7014
234Tablespace Performance Guide
정재익
2001-12-17
8743
233DB2 UDB Stored Procedure Builder 가이드
정재익
2001-12-17
8328
160[자료/IBM] Case Study : 리눅스에 DB2 포팅
문태준
2001-10-23
6468
158DB2 UDB 제품군 정의 [1]
이전건
2001-10-23
6148
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.050초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다