Your SlideShare is downloading. ×
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
PROPOSAL
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PROPOSAL

460

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
460
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Tablespace Performance Guide SMS vs DMS 2001 년 3 월 22 일 이전건 한국 IBM 소프트웨어 기술지원부
  • 2. SMS VS DMS SMSvsDMS 한국 IBM 소프트웨어 기술지원부
  • 3. SMSVSDMS 1. 테이블 공간의 성능상 고려사항 DB2 에서 정의될 수 있는 테이블 공간은 SMS(System Managed Space)와 DMS(Database Managed Space) 두가지이다. 이 중의 어떤 형태로 테이블 공간을 구성 하는가는 성능, 관리상에서 차이를 보이게 되는데 그 결정을 내리는데 있어 필요한 정보 와 고려사항을 알고 있다면, 해당 시스템에서 좀 더 효율적인 선택을 내릴 수 있을 것이 다. 이 문서에서는 상황에 따라 두가지 테이블 공간 관리 방법 중 어떠한 것을 사용하는 것 이 더 유용한지와 테이블 공간을 사용하는데 있어서 좀 더 효과적인 방법을 쓸 수 있도 록 각각의 특징을 살펴보도록 하겠다. 1.0 테이블 공간 "데이터베이스는 테이블 공간이라는 부분으로 구성됩니다. 테이블 공간은 테이블을 저 장할 장소입니다. 테이블 작성시 나머지 테이블 데이터와는 별개로 색인과 대형 오브젝 트(LOB) 데이터와 같은 특정 오브젝트를 유지하도록 결정할 수 있습니다. 또한 테이블 공간은 하나 이상의 물리적 저장 장치에 걸쳐 있을 수 있습니다. 다음과 같은 그림은 테 이블 공간에서 데이터를 전개하는 유연성의 일부를 보여줍니다." - DB2 UDB v7.1 관리 안내서 중에서 한국 IBM 소프트웨어 기술지원부 SMSvsDMS
  • 4. SMS VS DMS 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 비해 나은 성능을 보인다. SMSvsDMS 한국 IBM 소프트웨어 기술지원부
  • 5. SMSVSDMS 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 을 사용하지 않기 문에 위의 두 방식을 사용하게 되면 파일 시스템의 캐쉬 한국 IBM 소프트웨어 기술지원부 SMSvsDMS
  • 6. SMS VS DMS 를 사용할 수 있는 잇점이 있다. 하지만 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 테이블 공간과 테이블의 수 결정하기 데이타베이스를 설계하는 데 있어서 가장 일반적인 질문은 "하나의 테이블 공간에 몇개 의 테이블을 넣어야 하는가?" 혹은 "몇개의 테이블 공간을 만들어야 하는가?" 일 것이다. 이러한 물음의 결과 어떻게 나오더라도 그것은 특정 테이블과 테이블 공간의 성능에 상 당한 영향을 미치게 되는데, 보다 나은 성능을 위해서 위의 질문에 대해 어떻게 결정을 해야 좋은 지에 대해서 알아보자. 다음은 테이블을 어떻게 위치시킬 것인지에 대한 고려사항이다. SMSvsDMS 한국 IBM 소프트웨어 기술지원부
  • 7. SMSVSDMS - 테이블 공간을 복구하는 데 있어서 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 명령어를 사용하면 현재 테이블이 사용하고 있는 페이지 수와 남은 페이지 수등을 알 수 있다. 따라서 실제 테이블이 얼마나 증가하는 지를 쉽게 파악 할 수 있다. - 전체 테이블 공간의 숫자는 최소화하는 것이 바람직하다. 한국 IBM 소프트웨어 기술지원부 SMSvsDMS
  • 8. SMS VS DMS 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 이 테이블 공 간이 생성되는 시점에 만들어지고 크기가 할당이 된다고 하더라도 운영체제의 파일 시 스템은 여전히 파일을 조각낼 수 있는 가능성을 지닌다. 따라서 어떠한 경우에 페이지가 불연속적으로 위치할 가능성이 생긴다. 이렇게 되면 성능에는 나쁜 영향을 일으키게 된 다. SMSvsDMS 한국 IBM 소프트웨어 기술지원부
  • 9. SMSVSDMS 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 작업) 이 주 작업이다. 따라서 속도에 대한 문제 보다는 저장할 수 있는 저장장치의 용량 증가가 더욱 큰 문제이다. 또한 이것은 지속적으로 새로운 디스크가 필요하기 때문에 읽 한국 IBM 소프트웨어 기술지원부 SMSvsDMS
  • 10. SMS VS DMS 기 작업보다 훨씬 고가의 비용이 들어간다. 따라서 하나의 디스크에 읽기/쓰기의 비율을 고려해서 많은 수의 저장 장치를 갖춰야할 필요가 있다. 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(전송률) SMSvsDMS 한국 IBM 소프트웨어 기술지원부
  • 11. SMSVSDMS 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 의 제어 정보를 할당한 다는 것도 고려해야 한다. 한국 IBM 소프트웨어 기술지원부 SMSvsDMS
  • 12. SMS VS DMS 페이지 크기를 크게 사용하면 더 많은 색인키가 색인의 각 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 방식을 사용하는 것이 바람직하다. SMSvsDMS 한국 IBM 소프트웨어 기술지원부
  • 13. SMSVSDMS Table Space Creation container tag 1 page per container header for table space 1 extent table space space map 1 extent meta data object table data 1 extent 3 extents + 1 page Table (Object) Creation extent map 1 extent extent for data 1 extent 5 extents + 1 page 디폴트 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 그 밖의 고려사항 - 테이블 공간의 수는 가능한한 작게 한다. 한국 IBM 소프트웨어 기술지원부 SMSvsDMS
  • 14. SMS VS DMS - log 파일에 대해서도 색인과 사용자 데이타와 마찬가지로 DMS device 방식을 쓰는 것 이 성능에 좋다. 지금까지 tablespace 의 구성에 대해 참고해야 할 다양한 고려사항을 살펴 보았다. DB2 에서는 조인의 요건이 발생하는 모든 테이블을 하나의 데이타베이스로 구성하기를 권장한다. 하나의 데이타베이스로 묶여 관리가 되지만 테이블 공간을 어떻게 구현하느 냐에 따라 다양한 형태의 구성이 가능해진다. 그렇다면 이러한 다양한 형태를 어떻게 적 용할 것인가? 위에서 언급된 내용은 어디까지나 권장사항일 뿐이다. 사용자는 위의 내용을 참고하여 자신의 시스템에 가장 적합한 테이블 공간을 작성하고 관리해야 할 것이다. SMSvsDMS 한국 IBM 소프트웨어 기술지원부

×