Monitorowanie deadlocków

Monitorowanie deadlocków to zbieranie grafów zakleszczeń, pozwalające ustalić, które zapytania wzajemnie się blokują.

Jak powstaje graf zakleszczenia

Deadlock, czyli zakleszczenie, występuje wtedy, gdy co najmniej dwie transakcje oczekują na zasoby zablokowane przez siebie nawzajem. Przykładowo transakcja A może posiadać blokadę na wierszu w tabeli Zamowienia i oczekiwać na blokadę w tabeli Platnosci, podczas gdy transakcja B ma już blokadę w tabeli Platnosci i czeka na zasób należący do transakcji A. Żadna z nich nie może przejść do kolejnego polecenia, ponieważ zwolnienie blokady nastąpi dopiero po zatwierdzeniu albo wycofaniu transakcji.

System monitorujący przedstawia taką sytuację jako graf oczekiwania. Wierzchołki grafu reprezentują transakcje lub sesje wykonujące zapytania, a krawędzie pokazują zależność: jedna transakcja czeka na zasób zajęty przez inną. Cykl w grafie oznacza wzajemne oczekiwanie, a więc deadlock. Taki graf powinien zawierać identyfikator sesji, tekst wykonywanego zapytania, rodzaj żądanej blokady, zasób objęty blokadą oraz transakcję, która aktualnie przetrzymuje zasób.

Informacje potrzebne do odtworzenia zdarzenia

Samo odnotowanie komunikatu o zakleszczeniu nie wystarcza do ustalenia przyczyny. Użyteczny zapis obejmuje moment wykrycia, identyfikatory uczestniczących transakcji, kolejność żądań blokad i stan każdej transakcji w chwili wystąpienia problemu. Istotne jest także rozróżnienie między blokadą odczytu i zapisu, blokadą na pojedynczym wierszu, zakresem wierszy lub całej tabeli oraz zasobem związanym z indeksem. Te informacje pozwalają sprawdzić, czy konflikt wynika z kolejności operacji, zbyt długiej transakcji, braku indeksu albo zbyt szerokiego zakresu blokowania.

Monitoring powinien rejestrować również zapytania poprzedzające moment zakleszczenia. Dwa zapytania mogą wyglądać poprawnie osobno, lecz tworzyć cykl przy równoległym wykonaniu. Przydatne są czasy rozpoczęcia i zakończenia transakcji, czas oczekiwania na blokadę, liczba zmodyfikowanych rekordów oraz poziom izolacji transakcji. Warto zachować dane w formie umożliwiającej korelację z logami aplikacji, ponieważ deadlock często pojawia się tylko przy określonej kolejności żądań generowanych przez różne procesy.

Wykrywanie, wybór ofiary i obsługa błędu

System zarządzania bazą danych może okresowo analizować zależności blokad i wykrywać cykl bez czekania na upływ zwykłego limitu czasu oczekiwania. Po wykryciu deadlocku zazwyczaj przerywana jest jedna z uczestniczących transakcji, aby druga mogła kontynuować pracę. Wybrana transakcja jest nazywana ofiarą zakleszczenia. Kryterium wyboru zależy od silnika i jego konfiguracji; może uwzględniać między innymi koszt wycofania wykonanych zmian albo priorytet transakcji.

Aplikacja powinna rozpoznawać błąd deadlocku i obsługiwać go inaczej niż zwykłe odrzucenie danych. Transakcja wybrana jako ofiara zostaje wycofana, dlatego operację można ponowić dopiero po zakończeniu pełnego rollbacku i utworzeniu nowej transakcji. Ponowienie powinno mieć ograniczoną liczbę prób, kontrolowane opóźnienie oraz mechanizm rejestrowania kolejnych wystąpień. Bez tego aplikacja może generować lawinę identycznych żądań, zwiększając obciążenie i utrudniając analizę. Ponowienie nie powinno być stosowane automatycznie do każdego błędu blokady, ponieważ timeout i deadlock mają różne przyczyny.

Wnioski z monitorowania dla kolejności operacji

Analiza powtarzających się grafów często ujawnia, że różne ścieżki kodu modyfikują te same zasoby w odmiennej kolejności. Ujednolicenie kolejności dostępu do tabel, indeksów lub rekordów zmniejsza ryzyko utworzenia cyklu. Drugim obszarem jest długość transakcji: operacje niezwiązane z bazą danych, oczekiwanie na dane wejściowe albo rozbudowane przetwarzanie wykonywane wewnątrz transakcji wydłużają czas utrzymywania blokad. Monitoring pozwala sprawdzić, czy deadlocki występują przy konkretnych typach operacji, porach dnia lub wielkości partii danych.

Nie każde zakleszczenie wskazuje na uszkodzenie bazy danych. Jest to konflikt wynikający ze współbieżnego dostępu, który może być skutkiem projektu transakcji, planu wykonania zapytania, niewłaściwego indeksowania albo zbyt szerokiego zakresu modyfikacji. Diagnostyka powinna rozpocząć się od zachowania kompletnego grafu i odtworzenia kolejności zdarzeń, a dopiero potem obejmować zmianę zapytań, indeksów, poziomu izolacji lub strategii ponawiania. Takie podejście pozwala odróżnić pojedynczy incydent od stałego problemu w przepływie danych i ograniczyć ryzyko wprowadzenia poprawki, która tylko przesuwa konflikt w inne miejsce.