przeciążenie bazy danych

Przeciążenie bazy danych to stan, w którym liczba zapytań przekracza możliwości jej obsługi w rozsądnym czasie.

Jak rozpoznać przeciążenie bazy danych

Przeciążenie bazy danych występuje wtedy, gdy system otrzymuje więcej pracy, niż może wykonać w wymaganym czasie. Źródłem obciążenia są między innymi zapytania od aplikacji, raporty, zadania okresowe, importy danych oraz operacje wykonywane przez użytkowników. Sam wzrost liczby zapytań nie musi jeszcze oznaczać awarii. O przeciążeniu można mówić wtedy, gdy rosną czasy odpowiedzi, zwiększa się kolejka oczekujących operacji, pojawiają się przekroczenia limitów czasu albo system przestaje dotrzymywać wymagań aplikacji.

Objawy mogą być widoczne na kilku poziomach jednocześnie. Aplikacja zaczyna wolniej otwierać widoki, zapis danych kończy się błędem timeoutu, a użytkownicy otrzymują nieaktualne wyniki, jeżeli system korzysta z pamięci podręcznej. Po stronie komputera lub serwera mogą pojawić się wysokie użycie procesora, niewystarczająca ilość pamięci operacyjnej, intensywne operacje dyskowe albo oczekiwanie na blokady. Jeden wskaźnik nie wystarcza do postawienia rozpoznania, ponieważ wysokie użycie procesora może wynikać z obliczeń zapytania, a wysokie użycie dysku z odczytu danych, zapisu dziennika transakcji lub operacji systemowych.

Zapytania, indeksy i blokady jako źródła problemu

Jedną z częstych przyczyn przeciążenia jest nieefektywne zapytanie. Odczyt dużej tabeli bez odpowiedniego ograniczenia może wymagać skanowania wielu rekordów, nawet jeżeli wynik końcowy zawiera tylko kilka wierszy. Podobny efekt występuje przy filtrowaniu po kolumnie, która nie ma użytecznego indeksu, przy sortowaniu dużego zbioru danych oraz przy łączeniu tabel według nieindeksowanych kluczy. Dodatkowe obciążenie może powodować pobieranie zbyt wielu kolumn lub rekordów, gdy aplikacja potrzebuje tylko niewielkiej części wyniku.

Ważnym elementem analizy jest plan wykonania zapytania, czyli opis sposobu, w jaki silnik odczytuje dane i wykonuje operacje pośrednie. Plan może wskazać skan tabeli, kosztowne sortowanie, wielokrotne wykonywanie podzapytania albo użycie dużej ilości pamięci tymczasowej. Nie każdą sytuację należy naprawiać przez dodanie indeksu. Indeks przyspiesza niektóre odczyty, ale zajmuje miejsce, zwiększa koszt zapisu i może wydłużyć operacje modyfikujące dane. Trzeba również sprawdzić blokady: długa transakcja może zatrzymać inne operacje, a oczekujące zapytania mogą tworzyć łańcuch zależności i zwielokrotniać opóźnienia.

Pomiar obciążenia i odróżnienie przyczyny od objawu

Diagnostyka powinna obejmować czas trwania zapytań, ich liczbę, częstotliwość, rozmiar zwracanych wyników oraz liczbę operacji oczekujących. Przydatne jest porównanie aktualnych wartości z okresem, w którym system działał prawidłowo. Należy odnotować moment rozpoczęcia problemu i sprawdzić, czy w tym samym czasie uruchomiono raport, kopię zapasową, import danych, zmianę aplikacji albo zadanie konserwacyjne. Jeżeli opóźnienie dotyczy tylko jednego rodzaju operacji, prawdopodobna przyczyna może znajdować się w konkretnym zapytaniu lub tabeli. Jeżeli spowolnienie obejmuje cały system, trzeba uwzględnić zasoby sprzętowe, współbieżność oraz komunikację z aplikacją.

Wyniki pomiarów powinny być interpretowane razem, a nie jako pojedyncze alarmy. Wysokie użycie procesora przy krótkich czasach oczekiwania może oznaczać intensywne obliczenia, natomiast niski poziom użycia procesora nie wyklucza problemu, gdy zapytania czekają na dysk, blokadę lub połączenie sieciowe. Należy także sprawdzić pulę połączeń aplikacji. Zbyt duża liczba jednoczesnych połączeń może zwiększyć koszt przełączania i konkurencję o zasoby, a zbyt mała może powodować kolejkę po stronie aplikacji mimo dostępnych zasobów bazy. Logi powinny być analizowane z uwzględnieniem czasu, identyfikatora operacji i powtarzalności błędu.

Ograniczanie skutków i bezpieczne przywracanie wydajności

Doraźne działania mogą polegać na zatrzymaniu nietypowego raportu, ograniczeniu równoległych importów, skróceniu zakresu zapytania albo rozłożeniu ciężkich operacji w czasie. Jeżeli przyczyną jest blokada, trzeba ustalić, która transakcja przetrzymuje zasób i czy jej zakończenie jest bezpieczne. Przerywanie procesu bez sprawdzenia stanu transakcji może pozostawić rollback, dodatkowo obciążając system. Zmiana indeksów, parametrów pamięci lub konfiguracji współbieżności powinna być poprzedzona kopią zapasową, pomiarem oraz oceną wpływu na zapisy i odtwarzanie danych.

Trwała poprawa zwykle wymaga optymalizacji konkretnych zapytań, właściwego doboru indeksów, skrócenia transakcji i ograniczenia niepotrzebnych odczytów. Warto ustalić progi alarmowe dla czasu odpowiedzi, liczby oczekujących operacji, błędów timeoutu, użycia pamięci i dostępnego miejsca na dysku. Po zmianie należy ponownie wykonać pomiary oraz sprawdzić, czy poprawa jednego typu operacji nie pogorszyła zapisów, raportowania lub odtwarzania po awarii. Diagnostyka i naprawa powinny obejmować także komputer, na którym działa aplikacja, jego nośnik danych, pamięć operacyjną, system operacyjny i połączenie sieciowe, ponieważ problem przypisywany bazie może faktycznie powstawać poza samym silnikiem bazy danych.