deadlock_graph

deadlock_graph to zdarzenie rozszerzone SQL Server rejestrujące szczegółową strukturę wykrytego zakleszczenia transakcji.

Rola zdarzenia deadlock_graph w SQL Server

deadlock_graph jest zdarzeniem rozszerzonym SQL Server służącym do rejestrowania szczegółowego opisu zakleszczenia wykrytego przez mechanizm blokad. Zakleszczenie, czyli deadlock, powstaje wtedy, gdy co najmniej dwie sesje wzajemnie oczekują na zasoby zablokowane przez siebie. Przykładowo jedna transakcja może posiadać blokadę na wierszu tabeli A i oczekiwać na wiersz tabeli B, podczas gdy druga transakcja posiada blokadę na tabeli B i oczekuje na zasób należący do pierwszej transakcji. SQL Server wykrywa taki cykl oczekiwania i wybiera jedną z transakcji jako ofiarę, aby przerwać zakleszczenie.

Zdarzenie nie opisuje wyłącznie faktu wystąpienia błędu. Rejestruje strukturę zależności pomiędzy uczestniczącymi procesami i zasobami. Dzięki temu można ustalić, które sesje brały udział w konflikcie, jakie instrukcje wykonywały, jakie blokady posiadały oraz na jakie blokady oczekiwały. Informacje są przedstawiane w formacie XML jako graf zakleszczenia, dlatego nazwa zdarzenia odnosi się do graficznego modelu relacji między procesami i zasobami, a nie do wykresu generowanego w postaci obrazu.

Elementy raportu XML i interpretacja zależności

Raport generowany przez deadlock_graph zawiera elementy opisujące procesy uczestniczące w zakleszceniu oraz zasoby będące przedmiotem oczekiwania. W części dotyczącej procesów można znaleźć identyfikatory sesji i żądań, nazwę aplikacji, nazwę hosta, identyfikator logowania, poziom izolacji transakcji, stan transakcji, czas oczekiwania oraz informacje o wykonywanym poleceniu. Dla analizy istotne są również elementy inputbuf i executionStack. Pierwszy pokazuje bufor wejściowy związany z żądaniem, a drugi może zawierać stos wykonania z nazwą procedury, numerem instrukcji i fragmentem kodu Transact-SQL.

Część resource-list opisuje zasoby, takie jak klucze indeksu, strony danych, obiekty, metadane lub inne wewnętrzne zasoby blokad. Przy każdym zasobie raport może wskazywać właścicieli blokad oraz procesy oczekujące. Atrybuty trybu blokady, między innymi S dla blokady współdzielonej, U dla aktualizacyjnej i X dla wyłącznej, pozwalają odtworzyć kolejność konfliktu. Należy analizować relacje pomiędzy właścicielem a oczekującym, ponieważ sama nazwa tabeli nie wskazuje jeszcze, która kolejność operacji doprowadziła do cyklu.

W raporcie występuje także informacja o wybranej ofierze zakleszczenia. SQL Server może preferować transakcję o niższym koszcie wycofania, a aplikacja może wpływać na ten wybór przez ustawienie priorytetu zakleszczenia. Jeżeli priorytety są takie same, znaczenie ma między innymi koszt wycofania pracy. Raport pozwala sprawdzić, czy przerwana została krótka instrukcja, czy transakcja, której cofnięcie wymagało odtworzenia większej liczby zmian.

Rejestracja przez Extended Events i analiza powtarzalności

deadlock_graph jest związane z mechanizmem Extended Events, czyli systemem zdarzeń diagnostycznych SQL Server. W praktyce raporty mogą być przechwytywane przez sesję Extended Events zapisującą dane do pliku zdarzeń albo przekazującą je do innego celu obsługiwanego przez sesję. W wielu instalacjach informacje o zakleszczeniach są dostępne w systemowej sesji system_health, jednak zakres i sposób przechowywania danych zależy od konfiguracji oraz od tego, jak długo pliki sesji pozostają dostępne.

Jednorazowy raport należy traktować jako zapis konkretnego cyklu oczekiwania, a nie jako pełne wyjaśnienie wszystkich problemów z wydajnością. Przy analizie serii zdarzeń trzeba porównywać obiekty, indeksy, tryby blokad, kolejność instrukcji i identyfikatory procedur. Powtarzające się raporty z tym samym układem zasobów wskazują na wzorzec, który można odtworzyć. Różne raporty mogą natomiast dotyczyć odmiennych ścieżek wykonania, nawet gdy dotyczą tej samej tabeli. Warto także zestawić czas wystąpienia zakleszczenia z historią zmian schematu, obciążeniem aplikacji, planami wykonania i długością transakcji.

Podczas odczytu danych z sesji Extended Events trzeba zachować oryginalny dokument XML. Ręczne kopiowanie tylko nazw tabel lub zapytań może usunąć informacje o indeksie, kluczu, partycji, poziomie izolacji albo stanie transakcji. Istotna jest również różnica między identyfikatorem sesji a identyfikatorem żądania: jedna sesja może wykonywać różne żądania w czasie, a w raporcie trzeba analizować kontekst konkretnego żądania uczestniczącego w zakleszczeniu.

Wnioski z grafu przed zmianą kodu lub indeksów

Raport deadlock_graph powinien być podstawą do odtworzenia kolejności operacji, ale nie należy automatycznie usuwać blokad ani dodawać indeksów bez sprawdzenia danych. Częstą przyczyną jest wykonywanie przez różne ścieżki aplikacji operacji na tych samych obiektach w odmiennej kolejności. Innym problemem może być zbyt długo otwarta transakcja, która utrzymuje blokady podczas dodatkowych operacji, albo zapytanie skanujące większy zakres danych niż zakładano. Graf może też ujawnić niezgodność między używanym indeksem a predykatem zapytania, jeżeli oczekiwanie dotyczy kluczy indeksu, a nie całej tabeli.

Możliwe działania naprawcze zależą od konkretnego układu przedstawionego w XML. Stosuje się między innymi ujednolicenie kolejności dostępu do tabel, skrócenie zakresu transakcji, ograniczenie liczby modyfikowanych wierszy, poprawę predykatów, dobór indeksów oraz kontrolę poziomu izolacji. Aplikacja powinna również obsługiwać błąd zakleszczenia i ponowić całą transakcję zgodnie z zasadami właściwymi dla danego kodu, ponieważ SQL Server kończy wybraną transakcję błędem, a ponowienie pojedynczego polecenia może pozostawić logikę biznesową w niespójnym stanie.

Diagnostyka na komputerze używanym do pracy z SQL Server powinna obejmować sprawdzenie dzienników aplikacji, konfiguracji połączenia, wersji sterownika oraz miejsca, w którym aplikacja rozpoczyna i zatwierdza transakcję. Samo wystąpienie deadlock_graph nie oznacza uszkodzenia sprzętu. Jeżeli jednak analiza pokazuje równoczesne problemy z dyskiem, pamięcią lub stabilnością systemu, należy oddzielić przyczynę zakleszczenia od skutków przeciążenia. W przypadku diagnostyki laptopa lub komputera PC pomocne jest zachowanie pliku XML i pełnego kontekstu zdarzenia przed ponownym uruchomieniem aplikacji, aby możliwe było porównanie kolejnych przypadków.