Lokalizowanie problemów w bazach danych
- NetWorld,
- 07.02.2003
Relacyjne bazy danych łatwo mogą stać się żarłocznym pochłaniaczem zasobów sieciowych. Po dostarczeniu i zainstalowaniu nowej aplikacji bazodanowej zespół projektowy praktycznie kończy działalność, a na placu boju pozostają zarządcy sieci.
Relacyjne bazy danych łatwo mogą stać się żarłocznym pochłaniaczem zasobów sieciowych. Po dostarczeniu i zainstalowaniu nowej aplikacji bazodanowej zespół projektowy praktycznie kończy działalność, a na placu boju pozostają zarządcy sieci.
Jednak to właśnie zarządcy sieci są odpowiedzialni za niezawodność, połączenia i całościowe osiągi aplikacji. Najbardziej prawdopodobnym problemem, z jakim mogą się spotkać po wdrożeniu aplikacji bazy danych, jest mała wydajność.
Zachowanie się i wydajność relacyjnej bazy danych zależy od wielu czynników: serwera, środowiska sieciowego, parametrów strojenia, projektu aplikacji i obciążenia ze strony użytkowników. Co więcej, większość baz danych pracuje na różnych platformach systemów operacyjnych i różnych typach komputerów. Czynniki te i wybór platformy są tak złożone i wzajemnie powiązane, że poradzenie sobie z problemami wymaga rozległych ekspertyz.
Zapoznajmy się pokrótce ze sposobami radzenia sobie z wydajnością baz danych na przykładzie czterech rozpowszechnionych relacyjnych baz danych: Oracle 9i, Sybase Adaptive Server Enterprise (ASE) 12.5, Microsoft SQL Server 2000 i IBM DB2 Universal Database 7.2. Próby prześledzenia kwestii wydajności w sieci wykonano na sprzęcie Compaq ML570 ProLiant z systemem operacyjnym Windows 2000 Advanced Server.
Z perspektywy sieci problemy wydajności baz danych można zaliczyć do jednej z czterech podstawowych kategorii: monopolizowanie CPU serwera, długi czas oczekiwania na dostęp do dysku lub pamięci operacyjnej, przeciążenie adapterów sieciowych serwerów lub emitowanie znacznie większego ruchu sieciowego niż zakładano.
Właściwe skonfigurowanie
Zespół sieciowy musi zwracać szczególną uwagę na to, jak administrator bazy danych (DBA - DataBase Administrator) konfiguruje ją, zwłaszcza w wypadku rozpoczynania eksploatacji nowych aplikacji. DBA, postępujący ściśle według zasad strojenia podanych przez dostawcę, może utworzyć serwer bazy danych, który zmonopolizuje zasoby sieciowe lub zablokuje cały serwer sprzętowy.
Przez ustawianie lub modyfikowanie parametrów, stanowiących rodzaj przepustnicy ograniczającej liczbę i charakterystyki procesów serwerowych, wszystkie cztery produkty dają DBA prawie całkowitą kontrolę nad wykorzystaniem CPU, pamięci operacyjnej, dysków, a nawet adapterów sieciowych.
Sposób, w jaki oprogramowanie serwera baz danych Oracle używa parametrów ustawianych przez DBA do powoływania i uruchamiania procesów odbierających i dystrybuujących zlecenia SQL, jest dobrym przykładem tego, co można osiągnąć.
Jeśli natomiast ruch transakcji bazodanowych jest duży i serwer Oracle uruchomi zbyt wiele modułów koordynujących, to mogą one zdominować wykorzystanie pamięci operacyjnej lub CPU serwera.
Oprogramowanie SQL Server uruchamia porównywalną z Oracle liczbę wątków i procesów zarządzających. ASE i DB2 są trochę bardziej "powściągliwe" w obciążaniu CPU i pamięci serwera, ale również mogą stwarzać sytuacje, w których wykorzystanie tych zasobów nadmiernie rośnie, jeżeli administrator niewłaściwe zestroi bazę danych.