Monitorowanie obciążenia zasobów

Do baz danych Oracle lub SQL Server zainstalowanych na platformie Windows NT lub Windows 2000 Server są odpowiednie komponenty monitorowania wydajności w Performance System Monitor - złączu programowym (snap-in) do Microsoft Management Console. Performance System Monitor może dostarczyć szczegółowych informacji o zachowaniu się bazy danych.

Gdy narzędzia do monitorowania wydajności wykazują, że oprogramowanie bazy danych za bardzo angażuje CPU, nie należy od razu wymieniać serwera na nowy (szybszy lub z większą liczbą procesorów). DBA powinien wtedy podjąć próbę dopasowania parametrów konfiguracyjnych bazy danych, redukując maksymalną liczbę procesów lub wątków obsługujących zlecenia strony klienckiej.

Następnie należy sprawdzić osiągi po stronie klienckiej i wpływ nowych ustawień na użytkowanie CPU serwerów, wykorzystanie adapterów sieciowych oraz dostęp do dysków i pamięci operacyjnej. Jeżeli wydajność się poprawi, to oznacza, że parametry nowego strojenia zmniejszyły obciążenie procesami zarządzania oprogramowania bazodanowego do poziomu, na którym funkcje tych procesów mogą być łatwiej obsługiwane.

Jeżeli jednak nie odnotuje się żadnej poprawy, DBA powinien kontynuować śledztwo w celu znalezienia rzeczywistej przyczyny przeciążania CPU przez oprogramowanie bazodanowe.

Można na przykład zbadać, czy dyrektywy SQL wydawane przez aplikacje nie są złożone bardziej niż to potrzebne. Wszystkie cztery bazy danych mają bardzo wymyślne kompilatory SQL, interpretujące odbierane dyrektywy SQL. Jednak przekształcenie złożonych poleceń tekstowych (czym są dyrektywy SQL) w szereg operacji wybierania i modyfikowania rekordów bazy danych może być trudnym zadaniem nawet dla dobrze napisanego programu komputerowego.

Podobnie analiza użytkowania pamięci operacyjnej serwera (stronicowanej lub wymienianej) może pomóc w określeniu efektywności używania dostępnej pamięci przez oprogramowanie bazodanowe. W celu uzyskania większej wydajności wszystkie cztery bazy danych tworzą w pamięci operacyjnej kopie zawartości, czytanej lub zapisywanej przez klienta na dysku. Oprogramowanie baz danych może uniknąć relatywnie wolnego dostępu do pamięci dyskowej, jeżeli podczas przetwarzania kolejnego zlecenia klienta (np. dyrektywy SQL Select) znajduje żądany rekord w znacznie szybszej pamięci operacyjnej.

Dodanie fizycznej pamięci operacyjnej do serwera może znacząco zwiększyć wydajność bazy danych, ale nawet zwykła adjustacja rozmiaru pliku stronicowania w systemie operacyjnym często powoduje podobny skutek. Serwer bazy danych z wyjątkowo dużym plikiem stronicowania ma w praktyce dwie kopie bazy danych na dysku. Pliki baz danych na dysku są sformatowane w tablice i rekordy (wiersze tablic), natomiast pliki stronicowania są bajtową reprezentacją tych samych danych. Gdy uaktualniany jest rekord, serwer bazy danych musi je zapisać na dysku dwa razy - w każdym formacie osobno.

Jeżeli wykryto, że wąskim gardłem dla serwera bazy danych okazało się użytkowanie dysku twardego, to pierwszym zadaniem DBA będzie przesunięcie plików baz danych na inny dysk, a nawet inny kontroler dysku w celu zmniejszenia obciążenia pojedynczego dysku.

Ruch sieciowy baz danych

Nadmierne obciążenie adaptera sieciowego serwera bazy danych (ocena oparta na wynikach raportów narzędzi do monitorowania wydajności sieci) lub dużo gorsze od oczekiwanego działanie sieci (ocena oparta na analizie protokołów) mogą oznaczać wady projektowe aplikacji, pojawienie się wąskich gardeł w sieci i inne problemy.

Dostarczanie dyrektyw SQL do serwerów bazodanowych w SQL Server i ASE zapewnia protokół TDS (Tabular Data Stream), w Oracle natomiast TNS (Transparent Network Substrate). Większość narzędzi do analizy protokołów dekoduje pakiety TDS i TNS, ale bardzo rzadko obsługuje protokół transportowy SQL z DB2. Pomimo to, przeglądając kolekcję przechwyconych pakietów, można stosunkowo łatwo odnaleźć dyrektywy tekstowe SQL do tych wszystkich produktów - zawierające je pakiety są zazwyczaj dobrze widoczne na tle pozostałego ruchu sieciowego.

Jeżeli aplikacja strony klienckiej odbiera dużo rekordów, a kryteria ich filtrowania lub wyboru zastosowano na poziomie klienta, powoduje to zazwyczaj duży ruch sieciowy. "Cienki" klient, składający się na przykład z programów Visual Basic pracujących w komputerze klienckim, może generować duży ruch sieciowy w momencie przesyłania plików wykonywalnych do klienta lub gdy programy te wydają zlecenia SQL, co powoduje sprowadzanie większej liczby rekordów.

Powiększenie pasma może nie rozwiązać problemu nadmiernego użytkowania sieci. Często najlepszym wyjściem z sytuacji jest strojenie aplikacji bazodanowych przez rozszerzenia programowe, zapewniające użytkowanie sieci w sposób bardziej racjonalny. DBA może też modyfikować parametry strojenia bazy danych, ale to prawdopodobnie nie zmieni modelu użytkowania sieci w sposób tak istotny, jak można to zrobić na poziomie aplikacji.

Rozsądne posługiwanie się narzędziami do monitorowania wydajności serwera i analizy protokołów w celu zdiagnozowania problemów wydajnościowych bazy danych jest bardziej sztuką niż ścisłą wiedzą. Jednak wykorzystanie własnych doświadczeń i współpraca z DBA oraz projektantami aplikacji może znacznie pomóc w zoptymalizowaniu działania bazy danych, czyniąc ją "żwawszą" z punktu widzenia aplikacji.