lock_released

lock_released to zdarzenie Extended Events rejestrujące moment zwolnienia blokady zasobu.

lock_released jako sygnał zakończenia blokady

lock_released jest zdarzeniem rejestrowanym przez mechanizm Extended Events w środowisku Microsoft SQL Server. Pojawia się w chwili, gdy blokada założona na zasobie zostaje zwolniona. Zasobem może być między innymi wiersz, klucz indeksu, strona danych, obiekt, zakres kluczy albo inny element kontrolowany przez silnik bazy danych. Samo zdarzenie nie oznacza, że transakcja została zakończona. Informuje jedynie o ustaniu konkretnej blokady, która wcześniej ograniczała dostęp innym operacjom.

W praktyce lock_released stanowi drugą część obrazu potrzebnego do zrozumienia zjawiska blokowania. Najpierw może dojść do uzyskania blokady, następnie inna sesja może zostać zmuszona do oczekiwania, a po wykonaniu zatwierdzenia, wycofania lub innej operacji zwalniającej zasób pojawia się informacja o jego odblokowaniu. Dzięki temu można prześledzić czas życia blokady, zestawić go z aktywnością konkretnej sesji i sprawdzić, czy oczekiwanie wynikało z krótkiego, normalnego opóźnienia, czy z dłużej trwającej transakcji.

Warto odróżnić moment zwolnienia blokady od momentu rozpoczęcia oczekiwania. lock_released opisuje koniec ograniczenia dostępu, a nie przyczynę jego powstania. Do pełnej analizy potrzebne są zwykle także dane o sesji blokującej, sesji oczekującej, typie blokady, identyfikatorze zasobu, tekście polecenia oraz czasie rozpoczęcia i zakończenia operacji.

lock_released w kontekście blokad i oczekiwań

Blokady są mechanizmem ochrony spójności danych. Jeżeli jedna transakcja modyfikuje dane, druga transakcja nie zawsze może od razu odczytać albo zmienić ten sam fragment. Zakres ograniczenia zależy od poziomu izolacji, rodzaju wykonywanej instrukcji, planu zapytania oraz sposobu zarządzania transakcją. W tym kontekście lock_released pomaga ustalić, kiedy zasób ponownie stał się dostępny.

Przykładowo transakcja aktualizująca wiele wierszy może utrzymywać blokady przez cały czas trwania pracy. Jeżeli w tym okresie druga sesja próbuje zmodyfikować te same dane, pojawia się oczekiwanie. Po zatwierdzeniu pierwszej transakcji blokady mogą zostać zwolnione, a zdarzenia lock_released pozwalają określić, w jakiej kolejności odzyskiwano dostęp. Jeżeli od rozpoczęcia oczekiwania do zwolnienia blokady upływa dużo czasu, można skupić uwagę na długości transakcji, operacjach wejścia i wyjścia, przetwarzaniu dużego zbioru danych lub aplikacji, która zbyt późno kończy transakcję.

Nie każda blokada ma taki sam ciężar. Blokada o wąskim zakresie może dotyczyć pojedynczego rekordu, natomiast blokada o szerszym zasięgu może wpływać na większą liczbę operacji. W trakcie porównywania zdarzeń powinno się uwzględniać typ blokady, tryb dostępu oraz zasób, którego dotyczy wpis. Sam czas wystąpienia lock_released nie wystarcza do stwierdzenia, czy problem dotyczył pojedynczego wiersza, czy większej części tabeli.

Istotne jest również rozróżnienie blokowania od zakleszczenia. W przypadku blokowania jedna sesja czeka na zwolnienie zasobu przez inną sesję. Zakleszczenie oznacza cykl zależności, w którym sesje wzajemnie oczekują na zasoby i system musi przerwać jedną z transakcji. Zdarzenia lock_released mogą pojawić się w przebiegu obu sytuacji, lecz nie są samodzielnym raportem o zakleszczeniu. Do tego celu potrzebne są odpowiednie informacje diagnostyczne dotyczące ofiar, zależności oraz instrukcji wykonywanych przez uczestniczące sesje.

lock_released a typowe problemy z wydajnością

Jednym z częstych problemów jest transakcja pozostawiona otwarta przez aplikację. Polecenie modyfikujące dane zostaje wykonane, lecz zatwierdzenie następuje dopiero po dodatkowych czynnościach albo nie następuje wcale. W takiej sytuacji blokady mogą być utrzymywane znacznie dłużej, niż przewidziano w projekcie. Rejestr lock_released pozwala porównać czas zwolnienia zasobu z czasem wykonania zapytania i zidentyfikować sesje, które przeciągają zakończenie transakcji.

Inną przyczyną może być niekorzystny plan wykonania. Jeżeli wyszukiwanie obejmuje znacznie więcej danych, niż wymaga tego warunek, dłużej trwa również odczyt lub modyfikacja. W zależności od operacji mogą być zakładane blokady na większej liczbie elementów, a ich zwalnianie będzie widoczne dopiero po zakończeniu dłuższej pracy. Analiza powinna wtedy objąć tekst zapytania, używane indeksy, selektywność filtrów i liczbę przetwarzanych wierszy.

Problemy mogą wynikać także z niewłaściwej kolejności operacji. Dwie części aplikacji mogą modyfikować te same obiekty w różnej kolejności, przez co jedna sesja utrzymuje pierwszy zasób i oczekuje na drugi, a inna postępuje odwrotnie. W takim układzie lock_released staje się elementem chronologii potrzebnej do odtworzenia przebiegu zdarzeń. Porównanie identyfikatorów sesji, zasobów i znaczników czasu może wskazać, gdzie zależności zaczynają się nakładać.

Nie należy jednak traktować każdego wpisu lock_released jako dowodu awarii. Krótkie blokady są naturalnym elementem pracy systemu zarządzania bazą danych. Znaczenie ma ich czas trwania, częstotliwość, wpływ na użytkowników oraz powtarzalność w określonych porach. Zasadna ocena wymaga odniesienia danych do zwykłego obciążenia i do oczekiwanego czasu obsługi konkretnego procesu.

lock_released podczas zbierania danych diagnostycznych

Do rejestrowania zdarzeń Extended Events powinno się dobrać zakres odpowiadający konkretnemu problemowi. Zbyt szeroka sesja może wygenerować dużą ilość danych, utrudniając znalezienie istotnych wpisów. Zbyt wąski zakres może natomiast pominąć początek blokowania albo informacje o sesji oczekującej. Warto zapisać zarówno dane o zwolnieniu blokady, jak i zdarzenia opisujące jej uzyskanie, oczekiwanie oraz zakończenie transakcji, o ile są dostępne w wybranej konfiguracji.

Przy analizie należy zachować spójne znaczniki czasu. Różnica między chwilą rozpoczęcia oczekiwania a chwilą wystąpienia lock_released może wskazywać przybliżony czas blokowania. Warto także zestawić ten okres z czasem procesora, operacjami dyskowymi i aktywnością aplikacji. Jeżeli zwolnienie następuje szybko, lecz podobne zdarzenia występują bardzo często, przyczyną może być duża konkurencja o ten sam zasób. Jeżeli zdarzenia są rzadkie, lecz blokady trwają długo, większe znaczenie może mieć pojedyncza transakcja albo konkretne zapytanie.

Przydatne jest grupowanie wpisów według identyfikatora sesji, nazwy bazy danych, typu zasobu oraz rodzaju blokady. Taki sposób porządkowania umożliwia odróżnienie powtarzalnego wzorca od pojedynczego incydentu. Warto zachować także informacje o użytkowniku, aplikacji i hoście, ponieważ pomagają powiązać zdarzenie z procesem, który je wywołał. Dane diagnostyczne powinny być przechowywane przez czas wystarczający do porównania kilku przypadków, z uwzględnieniem ich rozmiaru i wpływu na dostępne miejsce.

W interpretacji trzeba uwzględnić, że kolejność prezentowana w narzędziu może zależeć od sposobu zapisu i od obróbki danych. Najpewniejsze wnioski wynikają z porównania wielu pól, a nie z jednego wpisu. Czas zwolnienia, zasób, sesja, tryb blokady i tekst instrukcji powinny tworzyć jeden kontekst. Dopiero wtedy można ocenić, czy lock_released wskazuje zwykłe zakończenie krótkiej operacji, czy fragment dłuższego łańcucha oczekiwania.

lock_released i moment zgłoszenia problemu

Do serwisu warto zgłosić się wtedy, gdy blokowanie powtarza się, opóźnia pracę aplikacji albo powoduje przerwy w dostępie do danych. Pomoc diagnostyczna może być przydatna także wtedy, gdy w logach pojawiają się zdarzenia lock_released, lecz nie jest jasne, która sesja utrzymywała blokadę i dlaczego trwało to tak długo. Nazwa Warszawskie Pogotowie Komputerowe 24/7 może zostać uwzględniona przy wyborze podmiotu, któremu przekazane zostaną informacje o problemie.

Przed zgłoszeniem dobrze jest przygotować przybliżony czas wystąpienia opóźnień, opis operacji wykonywanych przez użytkowników oraz dostępne fragmenty sesji Extended Events. Pomocne bywają również informacje o tym, czy problem dotyczy wszystkich operacji, jednej tabeli, konkretnego modułu aplikacji albo wybranych godzin. Nie powinno się usuwać danych potrzebnych do porównania, ale należy ograniczyć zakres przekazywanych informacji do elementów związanych z diagnozą.

W przypadku powtarzających się blokad znaczenie ma szybkie rozróżnienie kilku scenariuszy: zbyt długo trwającej transakcji, nieefektywnego zapytania, konfliktu kolejności operacji, nadmiernej konkurencji o zasób oraz zakleszczenia. lock_released pomaga ustalić, kiedy ograniczenie przestało działać, lecz dopiero zestawienie tego zdarzenia z pełnym przebiegiem pracy pozwala wskazać źródło problemu i dobrać właściwe działanie naprawcze.