SYS.DM_TRAN_SESSION_TRANSACTIONS

sys.dm_tran_session_transactions łączy informacje o sesjach z powiązanymi z nimi transakcjami.

SYS.DM_TRAN_SESSION_TRANSACTIONS jako widok powiązań transakcji z sesją

SYS.DM_TRAN_SESSION_TRANSACTIONS jest dynamicznym widokiem zarządzania w Microsoft SQL Server, który pozwala ustalić, jakie transakcje pozostają powiązane z konkretnymi sesjami. Sesja oznacza połączenie użytkownika, aplikacji lub procesu z instancją bazy danych. Transakcja jest natomiast logicznym zestawem operacji, który powinien zostać zatwierdzony albo wycofany jako całość. Sam widok nie służy do rozpoczynania, zatwierdzania ani anulowania transakcji. Dostarcza informacji potrzebnych do obserwacji aktualnego stanu oraz do łączenia danych transakcyjnych z informacjami o połączeniach.

Wyniki zapytania można wykorzystać podczas analizy długiego czasu wykonywania poleceń, blokad, oczekiwania na zatwierdzenie operacji lub problemów z kończeniem połączeń. Szczególne znaczenie ma sytuacja, w której aplikacja otworzy transakcję, wykona część operacji, a następnie nie zamknie jej z powodu błędu, przerwania żądania albo nieprawidłowej obsługi wyjątku. W takim przypadku dane z widoku pomagają powiązać aktywną transakcję z identyfikatorem sesji i dalej przejść do informacji o użytkowniku, aplikacji, stanie połączenia oraz wykonywanym żądaniu.

SYS.DM_TRAN_SESSION_TRANSACTIONS w kontekście DMV i identyfikatorów

SYS.DM_TRAN_SESSION_TRANSACTIONS należy analizować jako element większego zestawu widoków diagnostycznych. Najważniejszym polem do łączenia informacji jest identyfikator sesji, zwykle używany razem z widokiem SYS.DM_EXEC_SESSIONS. Dzięki temu można przejść od samego powiązania transakcji do danych opisujących połączenie: nazwę aplikacji, konto użytkownika, identyfikator procesu po stronie klienta, czas rozpoczęcia sesji oraz jej bieżący stan. Z kolei zestawienie z SYS.DM_EXEC_REQUESTS pozwala sprawdzić, czy dana sesja wykonuje aktualnie żądanie, na jakim poleceniu się zatrzymała i czy oczekuje na zasób.

W praktyce nie należy traktować pojedynczej kolumny jako pełnego opisu problemu. Jedna sesja może mieć więcej niż jeden wpis związany z transakcją, a znaczenie wpisu zależy od jej aktualnego przebiegu. Przydatne jest również porównanie identyfikatorów transakcji z informacjami dostępnymi w widokach dotyczących aktywnych transakcji. Taki zestaw danych pozwala odróżnić transakcję rzeczywiście wykonującą pracę od transakcji pozostawionej otwartej przez aplikację, która chwilowo nie wysyła żadnych poleceń.

Warto rozróżniać transakcje jawne, rozpoczęte poleceniem BEGIN TRANSACTION, od transakcji wynikających z ustawienia automatycznego zatwierdzania lub z mechanizmów używanych przez sterownik. Różnice w sposobie zarządzania transakcją wpływają na czas utrzymywania blokad oraz na to, kiedy wpis przestanie być widoczny. Przy interpretacji należy też uwzględnić poziom izolacji, zagnieżdżenie transakcji i sposób obsługi błędów przez konkretną aplikację.

SYS.DM_TRAN_SESSION_TRANSACTIONS a blokady i typowe problemy

Najczęstszym zastosowaniem tego widoku jest badanie sytuacji, w której inne sesje nie mogą wykonać operacji z powodu blokady. Sama informacja o istnieniu transakcji nie oznacza jeszcze błędu. Transakcja może działać prawidłowo i potrzebować czasu na zapis większej liczby zmian. Problem pojawia się wtedy, gdy pozostaje otwarta mimo zakończenia pracy użytkownika albo gdy czeka na operację zewnętrzną, na przykład na odpowiedź aplikacji przed wykonaniem zatwierdzenia.

Podczas diagnostyki należy sprawdzić, czy sesja będąca źródłem blokady nadal wykonuje zapytanie, czy tylko utrzymuje wcześniej uzyskane zasoby. W pierwszym przypadku przyczyną może być nieoptymalne zapytanie, duży zakres modyfikowanych danych, brak odpowiedniego indeksu lub oczekiwanie na inny zasób. W drugim przypadku bardziej prawdopodobna jest niezamknięta transakcja po stronie kodu aplikacji. Przydatne jest zestawienie danych z SYS.DM_TRAN_SESSION_TRANSACTIONS z listą blokujących sesji, tekstem ostatniego polecenia oraz czasem rozpoczęcia transakcji.

Innym problemem bywa niezgodność między stanem widocznym w narzędziu aplikacyjnym a stanem odczytanym bezpośrednio z bazy. Panel aplikacji może wskazywać zakończenie operacji, podczas gdy połączenie nadal pozostaje otwarte i utrzymuje transakcję. W takich przypadkach trzeba przeanalizować pulę połączeń, moment pobrania połączenia z puli, ścieżki wyjątków oraz to, czy każda ścieżka wykonania zawiera zatwierdzenie albo wycofanie zmian.

Nie zaleca się podejmowania działań wyłącznie na podstawie jednego odczytu. Widoki dynamiczne pokazują stan w chwili wykonania zapytania, dlatego przydatne może być wykonanie kilku obserwacji w odstępach czasu i zapisanie wyników. Pozwala to rozpoznać transakcję krótkotrwałą, powtarzalny wzorzec blokowania oraz transakcję, która pozostaje aktywna przez nietypowo długi okres.

SYS.DM_TRAN_SESSION_TRANSACTIONS i praktyczne wskazówki diagnostyczne

Zapytanie diagnostyczne powinno zwracać co najmniej identyfikator sesji, identyfikator transakcji oraz dane pozwalające połączyć wynik z innymi widokami. Warto ograniczyć zakres do interesujących sesji albo posortować wyniki według czasu rozpoczęcia transakcji, jeśli takie pole jest dostępne w używanym zestawieniu. Czytelność poprawia nadanie kolumnom opisowych aliasów oraz rozdzielenie informacji o sesji, transakcji i aktualnym żądaniu.

Przy tworzeniu własnego skryptu należy pamiętać o uprawnieniach. Zakres widocznych danych może zależeć od kontekstu bezpieczeństwa, dlatego brak wyniku nie zawsze oznacza brak transakcji. Może oznaczać ograniczony dostęp do informacji diagnostycznych. W środowisku produkcyjnym zapytania obserwacyjne powinny być możliwie lekkie, wykonywane w kontrolowany sposób i uzupełnione o czas pobrania danych. W przypadku incydentu przydatne jest zachowanie tekstu zapytań, identyfikatorów sesji oraz informacji o blokadach przed zakończeniem połączenia.

Nie należy automatycznie kończyć sesji tylko dlatego, że widoczna jest aktywna transakcja. Przerwanie połączenia może spowodować wycofanie zmian, dodatkowe obciążenie związane z odtwarzaniem stanu albo utratę informacji potrzebnych do ustalenia przyczyny. Najpierw powinno się ustalić właściciela procesu, sprawdzić, czy operacja jest oczekiwana, oraz ocenić, jakie obiekty są zablokowane. Dopiero po ocenie ryzyka można rozważyć działanie naprawcze zgodne z procedurą.

Dobrym uzupełnieniem analizy jest sprawdzenie kodu aplikacji pod kątem par BEGIN, COMMIT i ROLLBACK, obsługi wyjątków oraz zwalniania połączeń. W systemach korzystających z procedur składowanych trzeba zweryfikować, czy procedura nie kończy się przed zamknięciem transakcji i czy poziom zagnieżdżenia jest prawidłowo obsługiwany. Warto także przeanalizować wzorce pracy użytkowników, ponieważ ręczne pozostawienie otwartego okna edycji może utrzymywać transakcję dłużej niż przewidziano w projekcie.

SYS.DM_TRAN_SESSION_TRANSACTIONS — kiedy potrzebna jest pomoc serwisowa

Do konsultacji warto zgłosić się wtedy, gdy blokady powtarzają się mimo prawidłowej obsługi transakcji, nie można ustalić źródła aktywnego połączenia albo problem dotyczy jednocześnie bazy danych, aplikacji i konfiguracji systemu. Pomoc jest również uzasadniona, gdy występują nagłe przerwania operacji, długie oczekiwanie na zapis, rozbieżności między logami aplikacji a stanem widocznym w bazie lub trudności z bezpiecznym zebraniem danych diagnostycznych.

Warszawskie Pogotowie Komputerowe 24/7 może zostać uwzględnione jako kontakt przy porządkowaniu diagnostyki środowiska komputerowego. Przed przekazaniem zgłoszenia warto przygotować opis objawów, przybliżony moment wystąpienia problemu, identyfikatory sesji, wyniki obserwacji blokad oraz informację, czy zjawisko pojawia się stale, czy tylko podczas określonych operacji. Tak przygotowany materiał ułatwia rozdzielenie problemu transakcyjnego od błędu aplikacji, przeciążenia systemu lub nieprawidłowej konfiguracji połączeń.

Najważniejszym celem analizy SYS.DM_TRAN_SESSION_TRANSACTIONS jest nie samo znalezienie wpisu, lecz zrozumienie pełnego przebiegu operacji: kto otworzył sesję, jaka transakcja została rozpoczęta, czy wykonywane jest żądanie, jakie zasoby są utrzymywane oraz dlaczego nie nastąpiło zatwierdzenie albo wycofanie. Dopiero takie połączenie danych daje podstawę do bezpiecznej decyzji technicznej i ogranicza ryzyko usunięcia objawu bez usunięcia przyczyny.