lock_acquired to zdarzenie Extended Events rejestrujące moment założenia blokady na zasobie bazy danych.
Jak działa zdarzenie lock_acquired w SQL Server
lock_acquired jest zdarzeniem Extended Events dostępnym w silniku Microsoft SQL Server. Rejestruje moment, w którym żądanie uzyskało blokadę na określonym zasobie bazy danych. Informacja ta dotyczy faktycznego przyznania blokady, a nie samego zgłoszenia żądania. Jeżeli transakcja musi czekać, ponieważ inna sesja utrzymuje konfliktową blokadę, samo oczekiwanie nie oznacza jeszcze wystąpienia lock_acquired dla czekającej sesji.
Zakres zdarzenia może obejmować blokady związane między innymi z obiektami, stronami danych, kluczami indeksów, wierszami, zakresami kluczy oraz metadanymi. SQL Server dobiera poziom i tryb blokady zgodnie z operacją, izolacją transakcji, zasadami eskalacji oraz aktualnym stanem zasobów. W danych zdarzenia można analizować między innymi tryb blokady, typ właściciela, identyfikator transakcji, identyfikator bazy oraz wartości opisujące zasób w polach resource_0, resource_1 i resource_2. Dokładny zestaw kolumn należy sprawdzić w metadanych konkretnej instalacji SQL Server.
Tryby blokad i relacja między sesjami
Najczęściej spotykane tryby to S dla blokady współdzielonej, U dla blokady aktualizacyjnej oraz X dla blokady wyłącznej. Blokady współdzielone pozwalają wielu sesjom odczytywać ten sam zasób, natomiast blokada wyłączna uniemożliwia innym sesjom uzyskanie konfliktowej blokady na tym zasobie. Tryb aktualizacyjny jest używany w określonych ścieżkach operacji odczytu poprzedzającego modyfikację i ogranicza ryzyko wzajemnego zakleszczenia kilku wykonawców.
Przy interpretacji lock_acquired nie wystarczy policzyć liczbę zdarzeń. Trzeba powiązać je z sesją, transakcją, tekstem zapytania i czasem wystąpienia. Jedna instrukcja może uzyskać wiele blokad, a pojedyncza transakcja może utrzymywać je do momentu zatwierdzenia lub wycofania. Długi czas życia blokady nie wynika więc z samego zdarzenia jej założenia; wymaga porównania z dalszymi zdarzeniami, takimi jak lock_released, oraz z informacjami o oczekiwaniach blokujących.
Konfiguracja śledzenia Extended Events
Sesję Extended Events można utworzyć na poziomie serwera z użyciem zdarzenia sqlserver.lock_acquired. Praktyczna konfiguracja powinna ograniczać zakres przez predykaty, na przykład do wybranej bazy danych, sesji lub aplikacji. Do zdarzenia można dołączyć akcje takie jak sqlserver.session_id i sqlserver.sql_text, aby później powiązać uzyskanie blokady z wykonującym ją żądaniem. Warto wcześniej sprawdzić dostępne kolumny i akcje w widokach katalogowych Extended Events, ponieważ ich nazwy i dostępność zależą od wersji SQL Server.
Do dłuższych analiz właściwszy jest cel package0.event_file, który zapisuje dane do plików odczytywanych funkcją sys.fn_xe_file_target_read_file. Cel ring_buffer przechowuje dane w pamięci i może nadpisywać starsze wpisy, dlatego nadaje się głównie do krótkich obserwacji. Sesja obejmująca wszystkie uzyskiwane blokady może generować bardzo duży wolumen zdarzeń, zwłaszcza na obciążonym serwerze. Nadmierna liczba akcji, zbyt szeroki zakres oraz długie przechowywanie plików zwiększają koszt diagnostyki i utrudniają analizę.
Wykorzystanie danych lock_acquired w analizie blokowania
Analiza powinna rozpocząć się od ustalenia, jakie zasoby są blokowane i przez które sesje. Identyfikatory zasobów nie zawsze są bezpośrednio czytelne, dlatego trzeba je interpretować razem z typem zasobu, bazą danych, trybem blokady i kontekstem zapytania. Przydatne jest porównanie zdarzeń z widokami dynamicznego zarządzania, w szczególności sys.dm_exec_requests, sys.dm_tran_locks oraz sys.dm_os_waiting_tasks. Widoki pokazują jednak stan bieżący, a Extended Events dostarcza zapis przebiegu w czasie, więc oba źródła odpowiadają na nieco inne pytania.
Powtarzające się uzyskiwanie blokad na wielu stronach lub kluczach może wskazywać na skan, dużą modyfikację albo niekorzystny plan wykonania, ale samo zdarzenie nie dowodzi jeszcze błędu indeksowania. Należy sprawdzić plan zapytania, czas trwania transakcji, poziom izolacji, kolejność dostępu do tabel oraz występowanie eskalacji blokad. Jeżeli problemem jest zakleszczenie, właściwym materiałem uzupełniającym będzie zdarzenie xml_deadlock_report, ponieważ lock_acquired opisuje pojedyncze uzyskania blokad, a nie pełny graf cyklu zależności.
