Deadlock krytyczny

Deadlock krytyczny to zakleszczenie mające poważny wpływ na dostępność kluczowych operacji bazodanowych.

Deadlock krytyczny a zwykłe zakleszczenie transakcji

Deadlock krytyczny to sytuacja, w której co najmniej dwie transakcje lub procesy bazy danych wzajemnie oczekują na zasoby zablokowane przez drugą stronę, a zakleszczenie obejmuje operacje istotne dla działania systemu. Przykładowo pierwsza transakcja może posiadać blokadę rekordu w tabeli Klienci i oczekiwać na rekord w tabeli Zamówienia, podczas gdy druga transakcja ma już blokadę tego zamówienia i czeka na rekord klienta. Żadna z nich nie może przejść do kolejnego etapu bez zwolnienia zasobu przez drugą transakcję.

Określenie „krytyczny” opisuje przede wszystkim skutek operacyjny, a nie osobny, powszechnie znormalizowany typ blokady. Zakleszczenie dotyczące rzadko używanego raportu może być uciążliwe, ale nie musi zatrzymać pracy użytkowników. Jeżeli jednak obejmuje zapis zleceń, obsługę płatności, rejestrację urządzeń, kolejkę zadań albo inną centralną funkcję aplikacji, opóźnienie może szybko objąć wiele kolejnych żądań. W takiej sytuacji pojedynczy deadlock staje się incydentem o wysokim priorytecie, szczególnie gdy powtarza się przy normalnym obciążeniu.

Jak powstaje cykl oczekiwania na blokady

Mechanizm deadlocku można opisać za pomocą grafu oczekiwania. Wierzchołki grafu reprezentują transakcje, a krawędź skierowana od transakcji A do transakcji B oznacza, że A czeka na zasób utrzymywany przez B. Jeżeli graf zawiera cykl, na przykład A oczekuje na B, B oczekuje na C, a C oczekuje na A, system ma zamknięty łańcuch zależności. Samo długie oczekiwanie nie musi oznaczać deadlocku, ponieważ blokująca transakcja może jeszcze zakończyć pracę i zwolnić zasób. W cyklu żadna ze stron nie może jednak samodzielnie wykonać postępu.

Do powstania zakleszczenia często prowadzi niespójna kolejność modyfikowania danych. Jedna ścieżka kodu aktualizuje najpierw rekord użytkownika, a potem rekord zlecenia, natomiast inna robi to w odwrotnej kolejności. Ryzyko rośnie także przy zbyt długich transakcjach, przetrzymywaniu otwartej transakcji podczas operacji sieciowych oraz szerokim zakresie blokad wynikającym z nieefektywnego zapytania. Brak odpowiedniego indeksu może zwiększyć liczbę skanowanych i blokowanych wierszy, a tym samym powiększyć obszar konfliktu. Znaczenie ma również poziom izolacji, ponieważ określa, jakie blokady są zakładane i jak długo mogą być utrzymywane.

Objawy w logach i skutki dla przepływu danych

W logach aplikacji deadlock może pojawić się jako błąd wykonania transakcji, przerwanie zapisu, wycofanie operacji albo komunikat o zakleszczeniu zasobów. Warto sprawdzić nie tylko sam wpis o błędzie, lecz także identyfikator żądania, identyfikator transakcji, czas rozpoczęcia operacji oraz nazwę procedury lub zapytania. Istotne jest ustalenie, czy system bazodanowy wykrył cykl i wybrał jedną transakcję jako ofiarę do wycofania, czy wystąpiło jedynie przekroczenie czasu oczekiwania. Timeout może być skutkiem przeciążenia albo długiej blokady, ale nie dowodzi istnienia cyklu.

Deadlock krytyczny zaburza przepływ danych, ponieważ część operacji może zostać zatwierdzona, a część wycofana. Jeżeli aplikacja nie obsługuje poprawnie błędu wycofanej transakcji, użytkownik może zobaczyć komunikat o nieudanym zapisie, mimo że wcześniejsze czynności zostały wykonane. Jeszcze poważniejszym problemem jest błędna obsługa ponowienia: automatyczny retry bez limitu może powielać obciążenie i ponownie tworzyć konflikt. Bezpieczne ponowienie powinno obejmować całą logiczną transakcję, a nie tylko jej ostatnie zapytanie, oraz musi uwzględniać możliwość, że poprzednia próba została całkowicie wycofana. Analiza wymaga też porównania logów aplikacji z dziennikiem zdarzeń silnika bazy danych, ponieważ pojedynczy log klienta często nie pokazuje pełnego cyklu blokad.

Ograniczanie ryzyka i potwierdzanie przyczyny

Podstawową metodą ograniczania deadlocków jest ujednolicenie kolejności dostępu do współdzielonych zasobów we wszystkich ścieżkach kodu. Jeżeli każda transakcja modyfikuje najpierw rekord nadrzędny, a dopiero potem rekord zależny, liczba możliwych cykli maleje. Transakcje powinny być możliwie krótkie, zawierać tylko potrzebne operacje i nie obejmować oczekiwania na odpowiedź z zewnętrznej usługi. Należy również sprawdzić plan zapytań oraz indeksy, aby nie blokować większego zakresu danych niż jest konieczne. Samo zwiększenie limitu czasu oczekiwania nie usuwa przyczyny; może tylko opóźnić zgłoszenie problemu.