Sp_lock

sp_lock to starsza procedura systemowa wyświetlająca aktywne blokady w instancji, zastąpiona widokami sys.dm_tran_locks.

Sp_lock jako starszy interfejs diagnostyczny SQL Server

sp_lock jest starszą procedurą systemową Microsoft SQL Server służącą do wyświetlania informacji o blokadach utrzymywanych przez sesje. Procedura może pokazać blokady związane z aktywnymi procesami użytkowników oraz zasobami, do których te procesy uzyskały dostęp. W praktyce używano jej do szybkiego sprawdzenia, czy sesja posiada blokadę na obiekcie albo oczekuje na zasób zajęty przez inną sesję.

Procedura należy do historycznych mechanizmów diagnostycznych i nie powinna być traktowana jako podstawowe narzędzie w nowym kodzie administracyjnym. Jej wynik jest tabelaryczny, ale zakres prezentowanych informacji oraz sposób ich powiązania z konkretnym zapytaniem jest ograniczony. Sam fakt wyświetlenia blokady nie wyjaśnia jeszcze, które polecenie ją założyło, jak długo trwa transakcja ani czy dana sesja rzeczywiście blokuje wykonanie innej operacji.

Jak interpretować wynik procedury

Wywołanie bez dodatkowego identyfikatora służy do przeglądu blokad dotyczących wielu sesji. W zależności od wersji i kontekstu wykonania wynik może zawierać między innymi identyfikator procesu serwera, identyfikator bazy danych, identyfikator obiektu, typ zasobu, tryb blokady oraz stan blokady. Identyfikator procesu, często określany jako SPID, pozwala powiązać rekord blokady z konkretną sesją SQL Server.

Tryb blokady opisuje rodzaj uzyskanego dostępu lub zamiaru dostępu. Przykładowo blokada współdzielona jest typowa dla odczytu, a blokada wyłączna wiąże się z modyfikacją danych. SQL Server stosuje również blokady zamiaru, które sygnalizują planowane blokady na niższym poziomie hierarchii zasobów. Ocena konfliktu wymaga więc uwzględnienia zarówno typu zasobu, jak i trybu blokady; nie każda blokada widoczna w wyniku oznacza błąd lub bezpośrednie oczekiwanie.

Wynik sp_lock jest migawką stanu serwera z chwili wykonania procedury. Blokada może zniknąć przed rozpoczęciem dalszej analizy, jeżeli transakcja zostanie zatwierdzona, wycofana albo zakończy się oczekujące polecenie. Z tego powodu pojedynczy wynik nie powinien być automatycznie uznawany za dowód trwałego problemu. Przydatne jest powtarzanie obserwacji oraz zestawienie jej z czasem trwania transakcji, aktywnym poleceniem i stanem oczekiwania sesji.

Sys.dm_tran_locks i nowsza ścieżka analizy

Współczesna diagnostyka blokad w SQL Server opiera się przede wszystkim na dynamicznym widoku zarządzania sys.dm_tran_locks. Widok ten udostępnia informacje o zasobach blokad i ich właścicielach w formie przeznaczonej do łączenia z innymi widokami systemowymi. Dzięki temu można dokładniej ustalić, czy zasób dotyczy bazy danych, obiektu, strony, klucza, zakresu kluczy albo innego elementu używanego przez mechanizm blokowania.

sys.dm_tran_locks warto łączyć z sys.dm_exec_requests, aby zobaczyć bieżące żądania, stan wykonywania, czas oczekiwania oraz identyfikator sesji. Do analizy relacji oczekujący–blokujący przydatny jest także sys.dm_os_waiting_tasks, ponieważ pozwala sprawdzić, czy sesja faktycznie czeka na zasób zajęty przez inną sesję. Tekst wykonywanego polecenia można uzyskać przez funkcje i widoki dynamicznego zarządzania związane z pamięcią podręczną planów, o ile dane zapytanie jest nadal dostępne.

Takie zestawienie oddziela trzy różne sytuacje: sesję posiadającą blokadę, sesję oczekującą na blokadę oraz sesję, która wykonuje długą transakcję i przez to utrzymuje zasoby dłużej, niż oczekuje aplikacja. Samo znalezienie blokady nie uzasadnia zabicia procesu. Najpierw należy ustalić właściciela transakcji, rodzaj operacji, zależności między sesjami oraz ryzyko wycofania pracy po przerwaniu połączenia.

Ograniczenia użycia podczas rozwiązywania blokad

Przy analizie problemu nie należy utożsamiać każdego opóźnienia z blokadą wykrytą przez sp_lock. Żądanie może oczekiwać również na operację wejścia i wyjścia, pamięć, synchronizację albo zasób związany z równoległym wykonaniem planu. Jeżeli procedura pokazuje blokadę, trzeba sprawdzić, czy istnieje odpowiadające jej oczekiwanie oraz czy czas oczekiwania jest wystarczająco długi, aby wyjaśniał obserwowane spowolnienie.

Istotne znaczenie ma poziom uprawnień konta wykonującego diagnostykę. Widoki dynamicznego zarządzania mogą zwracać pełniejsze informacje użytkownikowi posiadającemu odpowiednie uprawnienia serwerowe, natomiast konto o ograniczonym dostępie może otrzymać niepełny obraz aktywności innych sesji. Brak rekordu w ograniczonym wyniku nie musi więc oznaczać braku blokady na całej instancji.

W środowisku SQL Server sp_lock może być przydatne jako szybki, historyczny punkt orientacyjny, lecz do dokumentowania przyczyny incydentu lepiej wykorzystać nowsze widoki dynamiczne oraz dane o aktywnym zapytaniu i oczekiwaniu. Szczególnie ważne jest zachowanie zgodności z wersją silnika, ograniczenie obserwacji do potrzebnego zakresu oraz unikanie zmian sesji przed zebraniem informacji diagnostycznych. Czynności takie jak zakończenie sesji albo wymuszenie wycofania transakcji mogą usunąć objaw, ale jednocześnie zmienić stan danych i utrudnić odtworzenie pierwotnej przyczyny.