Download: SysadminIbm

Konfiguracja DB2
SYSADMIN
Konfigurujemy IBM DB2
BAZA
POD KONTROLĄ
Uzyskanie optymalnej konfiguracji bazy danych wymaga obserwacji działającego już systemu.
Zanim jednak weźmiemy system pod lupę, nasza baza powinna być już skonfigurowana,
by nie zaczynać pracy od zera...
ARTUR WROŃSKI
W
ydajność bazy danych IBM DB2
zależy od wielu elementów, na
przykład od wykorzystywanego
sprzętu, konstrukcji aplikacji, rodzaju przetwarzania oraz od konfiguracji samej bazy danych. Baza danych utworzona z domniemanym zestawem parametrów jest zorientowana
na oszczędne wykorzystanie zasobów, dlatego
też powinniśmy zmodyfikować parametry
IBM DB2, tak by współgrały z wykorzystywanym środowiskiem. Przygotowanie właściwego
zestawu parametrów bazy danych można podzielić na dwa etapy:
– Wstępną konfigurację, w której parametry dobierane są na podstawie informacji
o używanym sprzęcie i o planowanym wykorzystaniu bazy danych.
– Strojenie zasadnicze, w którym obserwowane jest zachowanie systemu i dokonywane
są odpowiednie korekty konfiguracji.
W dalszej części artykułu zapoznamy się
z kluczowymi elementami konfiguracji IBM
DB2, które powinniśmy uwzględnić w pierwszej kolejności.
Tworzenie bazy danych
By utworzyć nową bazę danych wystarczy,
jeśli podłączymy się do systemu Linux jako
właściciel instancji IBM DB2 (zwykle
db2inst1) i w oknie terminala wykonamy polecenie:
db2 create database baza1
Może to potrwać od kilku do kilkudziesięciu
sekund, zależnie od wydajności komputera, na
którym wykonujemy polecenie. Podczas tworzenia bazy danych wykonywanych jest wiele
czynności. Między innymi alokowane są trzy
tzw. obszary tablicowe, bez których baza danych IBM DB2 nie mogłaby funkcjonować:
– Obszar danych systemowych (tzw. katalog systemowy), w którym przechowywane są
informacje o obiektach związanych z bazą
danych. W tej przestrzeni przechowywane są
informacje o definicji tabel, indeksów, widoków, itp.
– Obszar tymczasowych danych systemo wych. W tej przestrzeni przechowywane są
pośrednie wyniki zapytań, na przykład, jeśli
zajdzie konieczność posortowania lub złączenia dużej liczby wierszy.
– Obszar danych użytkownika, czyli miejsce na tabele i indeksy wykorzystywane przez
aplikacje.
Wszystkie te obszary tworzone są na ścieżce, na której powstaje baza danych. Jeśli nie
podamy takiej ścieżki jawnie, wtedy baza danych tworzona jest w katalogu domowym
właściciela instancji, czyli przykładowo
w katalogu /home/db2inst1.
Wybór katalogu, w którym będą znajdowały się pliki bazy danych jest pierwszą ważną
decyzją. Powinniśmy wybrać system plików
o stosownej pojemności oraz odpowiednich
parametrach wydajnościowych. Warto
uwzględnić nie tylko same parametry dysków czy liczbę wykorzystanych kontrolerów,
WWW.LINUX-MAGAZINE.PL
ale przede wszystkim ilość dysków. Bazy danych czytają informacje z dysków zwykle
małymi porcjami, często w blokach po kilka
bądź kilkanaście kilobajtów. Głowica dysku
jest wykonana z elementów mechanicznych
i nie może zmieniać swojej pozycji częściej
niż kilkadziesiąt do kilkuset razy na sekundę. Dlatego też w praktyce, by zapewnić wydajną obsługę znacznej liczby transakcji, wykorzystuje się dużą liczbę dysków. Średnio
od kilku do kilkunastu na jeden procesor.
Odpowiednia optymalizacja wykorzystania zasobów dyskowych jest jednym z ważniejszych elementów wpływających na wydajność bazy danych. IBM DB2 oferuje elastyczne mechanizmy konfiguracji przestrzeni dyskowych. Nie musimy znać zapotrzebowania na ilość miejsca i wydajność dysków
w momencie tworzenia bazy danych. Koniecznie jednak powinniśmy zaprojektować
i utworzyć odpowiednie obszary tabel jeszcze
przed załadowaniem danych do bazy.
Wygodną metodą utworzenia nowej przestrzeni tablicowej jest wykorzystanie odpowiedniego kreatora, dostępnego w narzędziu
do administracji bazami IBM DB2 – Centrum
Sterowania (ang. Control Center).
Centrum Sterowania uruchomimy poleceniem db2cc. Jeśli rozwiniemy drzewo obiektów dla wcześniej utworzonej bazy danych
i w lewej części okna zaznaczymy „Obszary
tabel”, to w prawej górnej części ekranu uzyskamy listę utworzonych już wcześniej przestrzeni, tak jak na Rysunku1.
NUMER 15 KWIECIEŃ 2005
73
SYSADMIN
Konfiguracja DB2
Rysunek 1: Centrum Sterowania wykorzystuje API IBM DB2 i pozwala na wykonanie wszystkich
zwiększać i zmniejszać istniejące. Operacje takie można wykonywać na pracującej bazie,
także wtedy, jeśli kontenery zawierają już dane
– w takim przypadku dane są automatycznie
przenoszone w wolne miejsce.
Dla optymalnej wydajności bazy danych,
dane użytkownika powinny być umieszczone
na przestrzeni zarządzanej przez bazę DMS.
Katalogi systemowe oraz systemowe tabele
tymczasowe powinny jednak pozostać na obszarach SMS. Katalogi systemowe zawierają
obiekty binarne, tzw. BLOB-y, które z definicji nie są buforowane przez IBM DB2,
a w przypadku obszarów SMS mogą być buforowane przez system operacyjny. W aplikacjach zorientowanych na przetwarzanie
transakcji nie ma konieczności przechowywania dużych struktur pośrednich, więc obszar typu SMS w zupełności wystarczy.
operacji administracyjnych.
Klikając prawym klawiszem na obiekt
„Obszary tabel” i wybierając z menu
„Utwórz...”, uruchomimy kreatora tworzenia
obszaru tabel.
Kreator składa się z kilku ekranów, które
krok po kroku pozwolą doprecyzować poszczególne parametry tworzonej przestrzeni
tablicowej. Każdy ekran zawiera szczegółowe
objaśnienia, więc początkujący użytkownicy
nie powinni mieć żadnych problemów
z utworzeniem nowej przestrzeni tablic.
Obszary SMS i DMS
Obszary tabel mogą być zarządzane dwoma
mechanizmami, o zupełnie różnych możliwościach:
– zarządzane przez system operacyjny – SMS
(ang. System Managed Space), albo
– zarządzane przez bazę danych – DMS
(ang. Database Managed Space).
Pierwszą różnicę pomiędzy tymi obszarami zauważymy już w momencie definicji
miejsca (kontenerów), w którym będą przechowywane dane. Dla obszaru SMS podaje
się tylko katalog, natomiast dla obszaru
DMS podaje się plik bądź urządzenie surowe
i jednocześnie określa się rozmiar kontenera.
Obszary SMS nie wymagają obsługi, gdyż
w podanym katalogu baza sama tworzy odpowiednie pliki, które są automatyczne rozszerzane i kurczone. Administrator musi jedynie zagwarantować odpowiednią ilość
miejsca na danym systemie plików. Nazwa
obszaru SMS bierze się stąd, że system operacyjny sprawuje bezpośrednią kontrolę nad
plikiem, przykładowo dane czytane przez
74
NUMER 15 KWIECIEŃ 2005
bazę przechodzą przez bufor systemu plików
Linuksa.
Obszary DMS dają większą kontrolę i oferują większą wydajność, szczególnie dla dużej
ilości danych. Szybsze jest wstawianie danych,
ponieważ miejsce na dysku jest zarezerwowane w momencie tworzenia przestrzeni i nie
musi być ciągle powiększane. Mechanizm czytania i pisania danych z DMS pozwala na ominięcie bufora plików systemu operacyjnego
(klauzula NO FILE SYSTEM CACHING
składni tworzenia przestrzeni tablicowych), co
zapobiega podwójnemu buforowaniu danych.
Możliwość wykorzystania surowych urządzeń,
czyli znakowych wolumenów logicznych bez
założonego systemu plików, dodatkowo pozwala na ominięcie narzutu sytemu plików.
Obszary DMS oferują także możliwość wykonywania częściowych archiwów na poziomie
obszaru tabel. Administrator ma pełną kontrolę nad kontenerami obszaru DMS, w dowolnym momencie może dodawać nowe, usuwać,
Rozmiar strony i wielkość
przydziału
Definiując obszary tabel, warto także zwrócić
uwagę na rozmiar strony oraz wielkość przydziału (extent), ponieważ są to parametry,
które można określić wyłącznie w momencie
tworzenia obszaru. Rozmiar strony definiuje
podstawową jednostkę czytania i pisania
z obszaru tabel. Dostępne są następujące rozmiary stron: 4 KB, 8 KB, 16 KB i 32 KB. Rozmiar strony wpływa na maksymalny rozmiar
przestrzeni tablicowej (dokładniej pojedynczej partycji przestrzeni tablicowej), który
przykładowo dla strony 4 KB wynosi 64 GB
oraz 512 GB dla strony 32 KB. W systemach
przetwarzania transakcyjnego mniejszy rozmiar strony jest bardziej odpowiedni, gdyż
jednorazowo czytane są niewielkie porcje danych. Dla systemów wspomagania decyzji
bardziej odpowiednie będą większe rozmiary
stron, ze względu na sekwencyjne odczyty odwołujące się do znacznej części danych.
Rysunek 2: Kreator tworzenia obszaru jest bardzo przydatny dla początkujących użytkowników.
WWW.LINUX-MAGAZINE.PL
Konfiguracja DB2
stępny jest przycisk „Pokaż SQL”, którym
możemy podejrzeć składnię wykonywanej
operacji. Tak przygotowane polecenie możemy zapisać na dysk i wykonać później, np.
korzystając z tekstowego interpretera db2.
Równoległa obsługa
dysków
Rysunek 3: IBM DB2 rozrzuca kolejne
extenty na dostępne kontenery.
Warto jeszcze wspomnieć o obowiązującej
regule, że każdy obszar tabel musi być skojarzony z jedną pulą buforów o takim samym
rozmiarze strony. Razem z bazą danych tworzona jest niewielka domniemana pula buforów IBMDEFAULTBP, służąca do buforowania obszarów o 4 KB rozmiarze stron. Jeśli
tworzony jest obszar o innym niż 4 KB rozmiarze strony, wtedy wcześniej należy utworzyć odpowiednią pulę buforów o takim samym rozmiarze strony. Można zrobić to także bezpośrednio z kreatora tworzenia przestrzeni tabel. Pule buforów mają kluczowy
wpływ na wydajność bazy danych, gdyż są
pamięcią podręczną optymalizującą dostęp
do dysku. IBM DB2 pozwala na tworzenie
wielu pul buforów i dynamiczne przywiązywanie ich do wybranych obszarów tabel.
Właściwe strojenie pamięci podręcznej bazy
należy wykonać obserwując zachowanie obciążonego systemu. Na starcie warto przydzielić ok. 10-20% pamięci operacyjnej komputera na potrzeby buforowania danych.
Extent określa rozmiar bloku, o jaki będzie rozszerzana tabela przy wstawianiu danych. Rozmiar extentu ma szczególne znaczenie, jeśli obszar tabel składa się z wielu
kontenerów. W takim przypadku, IBM DB2
będzie rozmieszczać kolejne extenty na dostępnych kontenerach. Jak zilustrowano na
Rysunku 3 pierwszy extent zostanie przydzielony na pierwszym kontenerze przestrzeni tablicowej, drugi na drugim, trzeci na
trzecim, a czwarty z powrotem na pierwszym
kontenerze, itd. Taki mechanizm obsługi
dysków pozwala na równomierny rozkład danych oraz zrównoważone obciążenie dysków.
Kreator tworzenia obszaru tabel, podobnie
jak kreatory innych obiektów, nie tylko ułatwia wykonanie danego zadania, ale także
jest bardzo pomocny w poznawaniu składni
poleceń. Na ostatnim ekranie kreatora do-
Jeśli zdefiniujemy przestrzeń dyskową składającą się z więcej niż jednego kontenera,
wtedy IBM DB2 będzie równolegle obsługiwać wszystkie dostępne kontenery. By
w maksymalnym stopniu wykorzystać możliwości systemu dyskowego, należy skonfigurować odpowiednią liczbę procesów piszących (NUM_IO_CLEANERS) i czytających
(NUM_IOSERVERS). Wartości tych parametrów zależą od wykorzystywanego sprzętu
oraz od sposobu korzystania z bazy. Startowe
wartości powinny być ustawione według następującej reguły:
SYSADMIN
Jeśli przestrzeń tablicowa tworzona jest na
macierzy dyskowej, wtedy najlepiej zdefiniować tylko jeden kontener i jednocześnie poinstruować bazę, by wykonywała równolegle
operacje dyskowe na jednym kontenerze.
Włączenie tej funkcji odbywa się przez ustawienie zmiennej rejestrowej IBM DB2_PARALLEL_IO. Zmienna ta czytana jest przy
starcie instancji, dlatego też, by włączyć tę
funkcjonalność, należy powtórnie wystartować motor bazy danych (polecenia: db2stop,
db2start).
Jeśli chcemy uaktywnić równoległe operacje na pojedynczym kontenerze dla wybranych obszarów tablicowych, wtedy ustawiając zmienną IBM DB2_PARALLEL_IO,
musimy podać listę obszarów przedzieloną
przecinkami:
db2set IBM DB2_PARALLEL_IO=U
"DANE1,INDEKSY1"
Rysunek 4: Podgląd składni pozwala precyzyjne zweryfikować wykonywaną operację.
NUM_IOSERVERS = liczba fizycznych dysków,
lecz nie mniej niż trzy i nie więcej niż liczba dostępnych procesorów przemnożona przez pięć,
NUM_IO_CLEANERS = liczba procesorów.
Poniższe polecenia możemy wykorzystać
do ustalenia startowej liczby procesów obsługi We/Wy, przy założeniu, że konfigurowana baza pracuje na komputerze z dwoma
procesorami i sześcioma dyskami:
db2 update db cfg for baza1 usingU
NUM_IOSERVERS 6
db2 update db cfg for baza1 usingU
NUM_IOCLEANERS 2
WWW.LINUX-MAGAZINE.PL
Jeśli zamierzamy włączyć tę funkcję dla
wszystkich obszarów tablicowych, wtedy należy użyć gwiazdki:
db2set IBM DB2_PARALLEL_IO="*"
Dziennik transakcji
Podczas tworzenia bazy danych powstają
także pliki dziennika transakcji, w których
zapisywane są informacje o dokonywanych
w bazie modyfikacjach. Baza danych wykorzystuje dziennik transakcji do wycofywania transakcji (SQL-owa komenda
ROLLBACK) oraz do przywracania syste-
NUMER 15 KWIECIEŃ 2005
75
SYSADMIN
Konfiguracja DB2
mu do spójnej postaci po awarii. Obszar
protokołowania (inne określenie nazwy
dziennika transakcji) jest także elementem archiwum i pozwala na odtworzenie
stanu bazy danych na dowolny punkt
w czasie. Protokołowanie powinno być odpowiednio skonfigurowane zaraz po utworzeniu bazy danych. Przy jego konfiguracji
powinniśmy:
– wybrać lokalizację. Standardowo dziennik transakcji znajduje się na ścieżce bazy
danych. Jeśli jest taka możliwość najlepiej,
gdy umieścimy dziennik transakcji na osobnym dysku. Każde zatwierdzenie transakcji
(COMMIT) inicjuje zapis bufora dziennika
transakcji na dysk. Jednocześnie wstrzymywana jest obsługa danej aplikacji, aż do momentu uzyskania potwierdzenia, że bufor
dziennika transakcji znalazł się na dysku.
Protokołowanie ma charakter sekwencyjny
(dopisywanie do pliku) i dla uzyskania najlepszej wydajności nie powinno być zakłócane przez inne procesy.
– określić rozmiar, czyli rozmiar pojedynczego pliku oraz ilość plików dziennika. Rozmiar dziennika transakcji ma wpływ na wielkość pojedynczej transakcji, która musi się
zmieścić w dostępnym obszarze dziennika.
Jeśli ten warunek nie może być zachowany,
wtedy taka transakcja jest wycofywana przez
system (ROLLBACK).
– określić tryb pracy. Dostępne są dwa tryby: cykliczny oraz archiwalny. Tylko tryb archiwalny pozwala na wykonywanie archiwów
na obciążonej bazie danych oraz późniejsze
odtwarzanie systemu do określonego punku
w czasie. Wybierając tryb archiwalny, musimy także wybrać metodę archiwacji starych
pliktów dziennika: automatyczną, ręczną
Rysunek 5: Parametry dziennika transakcji mogą być łatwo skonfigurowane przy pomocy
kreatora protokołowania.
bądź opartą o sparametryzowany program
USEREXIT.
Dziennik transakcji najłatwiej skonfigurować przy pomocy odpowiedniego kreatora.
Z poziomu Centrum Sterowania klikamy
prawym klawiszem nad konfigurowaną bazą
danych i wybieramy „Konfiguruj protokołowanie w bazie danych...”
Konfiguracja pozostałych
parametrów
IBM DB2 posiada wiele parametrów, które
pozwalają na precyzyjne dostrojenie systemu. Dla osoby, która dopiero stawia pierw-
sze kroki z IBM DB2, przygotowanie odpowiedniego zestawu parametrów startowych
może wydawać się skomplikowane. Z myślą
o takich osobach został przygotowany „Doradca konfigurowania”, który znacznie ułatwia ten proces. Narzędzie zbiera informacje o ilości pamięci, która ma być przeznaczona dla IBM DB2, rodzaju przetwarzania,
ilości poleceń SQL przypadających na jedną
transakcję, oczekiwanej przepustowość
transakcji oraz liczbie aplikacji. Na podstawie zebranych odpowiedzi narzędzie sugeruje odpowiedni zestaw parametrów. Wynikowe zmiany konfiguracji możemy zastosować od razu, bądź zapisać do pliku w celu
późniejszego wykonania. „Doradca konfigurowania” jest bardzo pomocny nie tylko
w przygotowaniu właściwego zestawu parametrów, ale także w zrozumieniu, które parametry należy zmienić dla określonych warunków obciążenia.
Więcej informacji na temat IBM DB2 i Linux jest dostępnych pod adresem [1]. Wiele
ciekawych artykułów o strojeniu IBM DB2
można znaleźć na stronach developerWorks
[2] oraz DB2 Magazine[3].
■
INFO
[1] http://www.ibm.com/db2/linux/
[2] http://www.ibm.com/developerworks/db2
Rysunek 6: Przygotowanie startowego zestawu parametrów IBM DB2 wcale nie musi być trudne.
76
NUMER 15 KWIECIEŃ 2005
WWW.LINUX-MAGAZINE.PL
[3] http://www.db2magazine.com/