Courseware Development Tools

Błąd! W dokumencie nie ma tekstu o podanym stylu.

Przegląd zagadnień

Dobry administrator Systemu Zarządzania Bazami Danych (w skrócie

SZBD) wie wszystko o bazach danych. W dzisiejszych czasach rola
administratora nie ogranicza się do zarządzania istniejącymi bazami danych, ale
również wymaga umiejętności tworzenia baz danych i ich obiektów. Jedną
z podstawowych

czynności

administracyjnych

stało

się

również

konfigurowanie baz danych.
W tym module omówiona zostanie struktura typowego SZBD na podstawie MS
SQL Server 2005. Dowiesz się również, jakie ustawienia baz danych są
najistotniejsze z punktu widzenia poprawnego działania tych baz.

Błąd! W dokumencie nie ma tekstu o podanym stylu.

Usługa serwera

Silnik

SZBD

odpowiedzialny

przechowywanie

danych,

utrzymywanie spójności danych i obsługę poleceń języka zapytań praktycznie
zawsze  jest  tożsamy  z  główną  usługą  serwera.  Aby  użytkownicy  mogli  stale
korzystać z tej usługi, powinna być ona uruchomiona praktycznie zawsze (nie
licząc  czasu  na  ewentualne  prace  administracyjne  wymagające  pracy  serwera
"offline").
Dodatkowo,  ponieważ  niektóre  czynności  wymagają  restartu  samej  maszyny,
usługa  ta  powinna  być  skonfigurowana  jako  uruchamiana  wraz  ze  startem
systemu  operacyjnego.  Niektóre  systemy  operacyjne  pozwalają  również  na
określenie  zachowań  usługi  w  momencie,  gdy  zostanie  ona  nieoczekiwanie
zatrzymana (nie przez użytkownika, a na przykład na skutek awarii).
Dla  przykładu,  w  systemie  Microsoft  Windows  Server  2003  można
skonfigurować  każdą  usługę  tak,  by  po  nieoczekiwanym  zatrzymaniu  była
podejmowana  próba  automatycznego  restartu  usługi  (czyli  ponownego  jej
uruchomienia).

Usługa automatyzacji zadań

Dobry administrator potrafi wykorzystać zdobycze techniki

i zautomatyzować  pracę  SZBD  tak,  by  mieć  przy  nim  jak  najmniej  pracy.  Do
automatyzacji najczęśćiej służy usługa, która albo jest oferowana przez system
operacyjny, albo jest dostarczana wraz z SZBD.
Usługa  ta  pozwala  między  innymi  na  tworzenie  harmonongramów  (ang.
schedule)  tworzenia  kopii  zapasowych  baz  danych.  Taką  usługą  w  systemie
Microsoft  SQL  Server  jest  SQL  Server  Agent.  Należy  zadbać  o  to,  by  taka
usługa  była  zawsze  uruchomiona,  a  często  domyślnie  usługi  te  są  wyłączone
lub zatrzymane.

Bezpieczeństwo usług

W trakcie konfiguracji usług SZBD należy kierować się pewnymi

zasadami, by uniknąć nieprawidłowości w ustawieniach i w działaniu serwera.
Zasady te dotyczą głównie kwestii związanych z bezpieczeństwem środowiska.

Pierwszą  ważną  zasadą  jest  zasada  minimalizacji  ilości  usług.  Mówi  ona,  że
należy  zawsze  instalować  /  uruchamiać  tylko  te  usługi,  z  których  w  danym
momencie korzysta nasz SZBD. Pozostałe usługi o ile mogą być zainstalowane
(w przyszłości może się okazać, że jakaś dodatkowa usługa będzie potrzebna),
o  tyle  ich  uruchamianie  powoduje,  że  administrator  ma  więcej  pracy,  zaś
w systemie znajduje się więcej potencjalnych słabych punktów.
Zasada  ta  obowiązuje  głównie  osoby  administrujące  systemami  i  sieciami
komputerowymi.  Stosowanie  się  do  niej  może  znacznie  zwiększyć
bezpieczeństwo systemu.
Druga  zasada  dotyczy  konfiguracji  kontekstu  usług.  Usługi  w  systemie
operacyjnym  działają  jak  użytkownicy  -  wykonują  operacje  i  mają  określone
uprawnienia.  W  niektórych  systemach  (Windows)  każdej  usłudze
przyporządkowane  jest  konto  użytkownika.  Mówimy,  że  "usługa  pracuje
w kontekście  użytkownika".  Oznacza  to,  że  usługa  działa  w  systemie
operacyjnym i w sieci na takich samych uprawnieniach, jakie zostały określone
dla użytkownika.
W  związku  z  tym  pojawia  się  problem  wyboru  właściwego  konta  dla  usług
SZBD. Problem ten dotyczy głównej usługi SZBD oraz usługi odpowiedzialnej
za automatyzację zadań w tym systemie.

Błąd! W dokumencie nie ma tekstu o podanym stylu.

Większość  systemów  operacyjnych  oferuje  wbudowane  konta  o  kreślonych
uprawnieniach.  Niestety,  uprawnienia  te  na  ogół  są  zbyt  duże,  by  konta
systemowe  można  było  wykorzystać  do  pracy  z  usługami  SZBD. Przykładem
takiego  konta  jest  konto  Local  System  (Lokalne  Systemowe)  w  systemach
Microsoft Windows.
Konto to działa jako element systemu operacyjnego, co w praktyce oznacza, że
ma  uprawnienia  nawet  większe  od  tych,  jakie  posiada  administrator  systemu.
Stąd  pierwszy  wniosek  -  na  ogół  nie  wybieramy  wbudowanych  kont
systemowych  dla  usług  SZBD.  Powstaje  pytanie  -  jakich  w  takim  razie  kont
używać?

Jeśli  serwer  ma  pracować  w  środowisku  rozproszonym,  ma  mieć  możliwość
dostępu do innych serwerów i dodatkowo maszyna znajduje się w domenie, to
wybieramy  dla  usług  SZBD  konto  domenowe,  specjalnie  utworzone
i skonfigurowane. Konto to powinno mieć ustawienia, które pozwolą w sposób
nieprzerwany pracować usłudze.
Zatem - należy ustawić dla tego konta silne hasło, które: nie powinno mieć daty
wygasania  ("hasło  nigdy  nie  wygasa")  i  nie  powinno  być  zmieniane  przez
użytkowników ("użytkownik nie może zmieniać hasła", bez opcji "użytkownik
musi  zmienić  hasło  przy  pierwszym  logowaniu").  Co  do  uprawnień  konta,
należy  rozważyć  przydzielenie  konta  do  roli  lokalnego  administratora  (dla
potrzeb  na  przykład  automatycznego  restartu  usługi  w  przypadku
nieoczekiwanego jej zatrzymania).
Czasami taka konfiguracja jest wymagana (na przykład przy instalacji systemu
Microsoft  SQL  Server  w  klastrze  Microsoft  Windows).  Dla  głównych  usług
SZBD  możesz  skonfigurować  jedno  konto  (ułatwia  to  zdecydowanie
administrację  kontami).  Nazwa  konta  to  dla  zwiększenia  bezpieczeństwa  nie
powinna kojarzyć się z SZBD.

Narzędzia konfiguracji usług

Większość

systemów

operacyjnych

oferuje

narzędzie

zcentralizowanego  zarządzania  usługami  zainstalowanymi  w  systemie.  Jednak
ponieważ  ogólna  ilość  usług  w  systemach  operacyjnych  jest  ogromna,
a dodatkowo  bardzo  często  usługi  SZBD  wymagają  dodatkowych  ustawień,
producenci  zazwyczaj  dodają  do  SZBD  narzędzie  (lub  zestaw  narzędzi)  do
zarządzania usługami tylko samego SZBD.
Dla  przykładu,  W  systemie  Microsoft  SQL  Server  2005  są  dwa  narzędzia  do
zarządzania  usługami:  Configuration  Manager  oraz  Surface  Area
Configuration.  Pierwszy  program  umożliwia  zarządzanie  usługami
i protokołami  sieciowymi,  zaś  drugi  pozwala  włączać  domyślnie  wyłączone
dodatkowe mechanizmy SZBD.

Błąd! W dokumencie nie ma tekstu o podanym stylu.

Konfiguracja dotycząca sprzętu

Jedne z pierwszych ustawień, jakich dokonuje administrator serwera

baz danych, to ustawienia dotyczące sprzętu. Rozwój informatyki i przemysłu
komputerowego  sprawił,  że dzisiejszy  serwer  to  na  ogół  maszyna  o  ogromnej
mocy  obliczeniowej,  wyposażona  w  wielką  ilość  pamięci  masowej,  kilka  lub
nawet  kilkanaście  procesorów  (dodatkowo  na  ogół  wielordzeniowych),  kilka
szybkich  kart  sieciowych.  Pojawiły  się  też  maszyny  64-bitowe,  które  oferują
wydajność dotąd niespotykaną (miliony transakcji na sekundę).

Jeżeli serwer jest dedykowany, to znaczy przeznaczony do pracy tylko z SZBD,
konfiguracja właściwie nie nastręczna problemów, ponieważ zasoby maszyny
mogą być niemal w całości wykorzystane przez SZBD.

Jeśli  jednak  serwer  nie  jest  dedykowany  tylko  do  pracy  z  SZBD,  najczęściej
potrzebna  jest  dodatkowa  konfiguracja.  Konfiguracja  ta  dotyczy  na  ogół
ograniczenia  wykorzystania  pamięci  operacyjnej  serwera  przez  SZBD  oraz
użycia  określonego  zestawu  procesorów  spośród  wszystkich  procesorów
serwera.

Microsoft  SQL  Server  2005  daje  możliwość  skorzystania  z  technologii  AWE
(ang.  Address  Windowing  Extensions),  która  umożliwia  wykorzystanie
nieprawdopodobnej  ilości  64GB  pamięci  RAM  nawet  na  platformach  32-
bitowych  (które  mają  naturalne  ograniczenie  obsługi  do  4GB  RAM).
Warunkiem  jest  wykorzystanie  systemu  operacyjnego  Microsoft  Windows
2000 Server lub Microsoft Windows Server 2003.
Możliwe jest ustawienie minimalnego i maksymalnego poziomu wykorzystania
pamięci  RAM  przez  SZBD.  W  przypadku,  gdy  SZBD  współdzieli  zasoby
z innym  oprogramowaniem,  należy  zapewnić  odpowiednie  wykorzystanie
pamięci.  Także  w  przypadku  zaawansowanych  instalacji  trzeba  pomyśleć
o odpowiedniej konfiguracji RAM.
Dla  przykładu,  w  klastrze  o  architekturze  aktywny-aktywny  (dwa  SZBD
współdzielone  przez  dwa  węzły  klastra)  należy  ustawić  odpowiednio  niski
maksymalny  poziom  wykorzystania  pamięci  przez  obie  instancje  SZBD.
W przeciwnym wypadku po przejściu w awaryjny tryb pracy jednej z instancji
pojedyncza  maszyna  może  nie  poradzić  sobie  z  dwiema  instancjami  SZBD.

Jeśli Twoja maszyna ma więcej niż jeden procesor, możesz chcieć ograniczyć
liczbę  używanych  przez  SZBD  procesorów  przez  ustawienie  tzw.  maski
afiniczności (ang. affinity mask). Jest to konfiguracja binarna mówiąca o tym,
które z procesorów będą wykorzystane przez SZBD.
Które procesory wybrać? Łatwiej zdecydować, których nie wybierać. Procesor
0  (pierwszy)  zazwyczaj  jest  wykorzystywany  przez  system  operacyjny,  zatem
często  administratorzy  decydują  się  na  wykluczenie  go  z  grupy  procesorów
wykorzystywanych przez SZBD. Ponadto ostatni procesor jest wykorzystywany
przez  kartę  sieciową,  więc  często  administratorzy  serwerów  baz  danych
wybierają również ten procesor jako ten, który nie będzie wykorzystywany na
potrzeby operacji na bazach danych.

Konfiguracja ustawień programowych serwera

Oprócz ustawień dotyczących wykorzystania sprzętu, administrator

musi dokonać konfiguracji ustawień programowych. Ustawienia te dotyczą
m.in.

konfiguracji

wszelkich

dodatkowych

funkcjonalności,

opcji

bezpieczeństwa czy opcji połączeń. Wszelkie ustawienia można zmieniać na

Błąd! W dokumencie nie ma tekstu o podanym stylu.

dwa sposoby: korzystając z narzędzi graficznych (jak SQL Server Management
Studio) lub używając odpowiednich składni języka zapytań (procedury
systemowe). Na przykład poniższy kod powoduje włączenie obsługi
wspomnianej technologii AWE na serwerze Microsoft SQL Server.

-- aktywacja zaawansowanych opcji
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO

-- włączenie awe
EXEC sp_configure 'awe enabled', 1
RECONFIGURE
GO

Konfiguracja  ustawień  programowych  z  użyciem  interfejsu  użytkownika
w systemie  Microsoft  SQL  Server  2005  polega  na  wykorzystaniu  dwóch
aplikacji:  SQL  Server  Management  Studio  oraz  SQL  Server  Surface  Area
Configuration (SAC).

Praktycznie każdy SZBD posiada narzędzie do zcentralizowanego zarządzania
ustawieniami  serwera.  W  przypadku  systemu  Microsoft  SQL  Server  2005
narzędziem tym jest SAC. SAC pozwala na definiowanie zasad działania usług,
włączanie  i  wyłączanie  dodatkowych  funkcjonalności  systemu,  kontrolę  nad
połączeniami  i  protokołami  sieciowymi.  Co  jest  najważniejsze,  w  systemie
zastosowano  zasadę  "domyślnie  wyłączone",  dzięki  czemu  serwer  po
zainstalowaniu  jest  wolny  od  potencjalnych  zagrożeń.  Jeżeli  masz  do
skonfigurowania  wiele  serwerów,  narzędziem,  którym  powinieneś  się
zainteresować  jest  sac.exe  (z  linii  poleceń).  Narzędzie  to  umożliwia  eksport  /
import ustawień konfiguracji serwera, co daje możliwość poprzez jednorazową
konfigurację  wybranego  serwera,  implementację  tych  samych  ustawień  na
wielu serwerach.

Rys. 1.3.1 Surface Area Configuration

Rys. 3.2 Centralne zarządzanie MS SQL Server 2005

Błąd! W dokumencie nie ma tekstu o podanym stylu.

Rozmieszczenie plików bazy danych

Baza danych składa się z plików. Plik bazy można podzielić na pliki

danych  i  pliki  dziennika  transakcji.  W  plikach  danych  przechowywane  są
obiekty  baz  danych,  takie  jak  tabele  (wraz  z  danymi),  indeksy  czy  procedury
składowane.  W  plikach  dziennika  transakcji  system  zapisuje  strony  (w
przypadku systemów SQL Server strona to blok 8kB)  zawierające modyfikacje
danych.

Rozmieszczenie  plików  odgrywa  znaczącą  rolę  w  procesie  tworzenia
i optymalizacji   bazy  danych.  Istnieje  szereg  zasad  przydatnych  w  planowaniu
fizycznej implementacji bazy danych. Zasady te to m.in.:

1. Pliki dziennika transakcji należy umieszczać na innym dysku fizycznym

niż pliki danych - w przypadku awarii jednego z dysków tracimy tylko
część bazy.

2. Tabele często występujące razem w złączeniach (ang. joins) należy

umieszczać w osobnych plikach (grupach plików) na osobnych dyskach
fizycznych - dzięki temu możliwe jest równoległe pobieranie danych z tych
tabel.

3. Indeksy nieklastrowane należy umieszczać na innych dyskach fizycznych

niż ich bazowe tabele - zyskujesz większą wydajność zapisu danych.

4. Tabele często modyfikowane należy oddzielić fizycznie (umieścić na

innym dysku) od tabel rzadko modyfikowanych - w przypadku większych
baz danych upraszcza to proces wykonywania kopii zapasowych.

Jednoczesne spełnienie wszystkich wymienionych punktów jest raczej
niemożliwe, ale w idealnym przypadku oddzielenie dziennika transakcji od
danych i maksymalne rozczłonkowanie danych pomiędzy tak wiele dysków, jak
się da, byłoby rozwiązaniem dającym maksymalne bezpieczeństwo i wydajność
bazy.

Bezpieczeństwo fizyczne danych

Dane, jak i dziennik transakcji można dodatkowo zabezpieczyć przed

ewentualnymi awariami dysków fizycznych. Do tego celu należy użyć
macierzy dyskowych z zaimplementowanymi konfiguracjami RAID (ang.
Redundant Array of Independent Disks).

Istnieje wiele konfiguracji RAID, ale do najbardziej znanych i zarazem
najczęściej stosowanych należą: RAID-0, RAID-1, RAID-5 oraz RAID-10.
Więcej o systemach RAID i bezpieczeństwie SZBD znajdziesz w module 12.

Błąd! W dokumencie nie ma tekstu o podanym stylu.

Ustawienia dotyczące plików

Po wybraniu odpowiedniej struktury bazy i określeniu jej nazwy

przychodzi pora na ustawienie pewnych właściwości plików bazy danych.
Ustawienia te to:



ilość i lokalizacja plików,



wielkość początkowa plików,



sposób powiększania plików (powinien zostać wybrany automatyczny
przyrost rozmiaru),



maksymalny rozmiar dla każdego z plików (alternatywnie można
maksymalny



rozmiar pozostawić nieokreślony, ale wówczas administrator jest
zmuszony do monitorowania wolnego miejsca na dysku twardym),



nazwy logiczne plików.

Rys. 3.3 Opcje plików bazy danych w Microsoft SQL Server 2005

W  praktyce  należy  pamiętać  o  takim  ustawieniu  rozmiaru  początkowego
plików,  by  znalazło  się  w  nich  miejsce  na  nowe  dane.  Proces  powiększania
rozmiaru  pliku  może  niepotrzebnie  obciążyć  bazę  danych.  Co  za  tym  idzie,
należy też zadbać o to, by przyrost rozmiaru pliku nie był zbyt mały.
Najlepszym  nawykiem  jest  manualne  powiększanie  rozmiarów  plików  poza
godzinami,  w  których  baza  jest  używana  przez  największą  liczbę
użytkowników.  Opcja  automatycznego  powiększania  plików  powinna  być
ustawiona  na  wszelki  wypadek  (gdyby  administrator  zapomniał  o  swoich
obowiązkach lub wystąpiła nieoczekiwana sytuacja wymagająca powiększenia
pliku).
Dziennik  transakcji  należy  ustawić  na  początek  na  20-30%  rozmiaru  plików
danych. W trakcie pracy bazy danych rozmiar ten można zmienić wedle potrzeb
.

Błąd! W dokumencie nie ma tekstu o podanym stylu.

Ustawienia dotyczące bazy danych

Równie ważne, jak ustawienia plików, są ustawienia samej bazy

danych. Ustawienia te, to na przykład:



ustawienia dotyczące języka, metod sortowania tekstu, znaków
dialektycznych,



ustawienia dotyczące zapisu zmian w dzienniku transakcji (tzw. model
przywracania bazy, ang. recovery model),



ustawienia dotyczące statystyk (statystyki to zapis rozkładu danych w
kolumnach najczęściej wykorzystywanych w tabelach, mogą być
tworzone i utrzymywane automatycznie),



ustawienia dotyczące dostępu do bazy danych (w niektórych
sytuacjach niezbędne jest ograniczenie dostępu do bazy danych dla
użytkowników, np. przy przywracaniu bazy danych z kopii zapasowej).

Rys.3.4 Opcje bazy danych w Microsoft SQL Server 2005

Ustawienia opcji bazy danych zmieniają się w trakcie działania bazy. Zmiany
dokonywane są przy pomocy narzędzi graficznych (np. SQL Server
Management Studio) lub poleceń SQL (np. ALTER DATABASE)