SYS.DM_TRAN_DATABASE_TRANSACTIONS

sys.dm_tran_database_transactions zwraca szczegóły transakcji w kontekście konkretnej bazy danych.

SYS.DM_TRAN_DATABASE_TRANSACTIONS — czym jest ten widok DMV

sys.dm_tran_database_transactions jest dynamicznym widokiem zarządzania w Microsoft SQL Server, który pokazuje stan transakcji z perspektywy poszczególnych baz danych. Jego zadaniem jest uzupełnienie informacji uzyskiwanych z widoków dotyczących transakcji na poziomie instancji, sesji i zadań. Dzięki temu można ustalić, że dana transakcja istnieje nie tylko jako obiekt związany z połączeniem lub jednostką pracy, lecz także aktywnie uczestniczy w przetwarzaniu w konkretnej bazie.

Widok bywa używany podczas analizy długotrwałych transakcji, opóźnionego obcinania dziennika transakcji, blokad oraz sytuacji, w których polecenie zatwierdzające albo wycofujące nie zostało wykonane w oczekiwanym czasie. Nie jest to dziennik wszystkich operacji wykonywanych w bazie. Reprezentuje stan widoczny w chwili odczytu i obejmuje informacje potrzebne do powiązania transakcji z bazą danych oraz z innymi elementami mechanizmu transakcyjnego.

W praktyce zapytanie do tego DMV powinno być traktowane jako punkt wyjścia do dalszego rozpoznania. Sam rekord nie zawsze wyjaśnia, jaka aplikacja rozpoczęła transakcję, jaki użytkownik ją utworzył ani które zapytanie zatrzymało jej zakończenie. Takie informacje należy zestawić z innymi widokami systemowymi, bieżącymi żądaniami, sesjami, procesami roboczymi oraz stanem dziennika.

SYS.DM_TRAN — kontekst techniczny i porównanie z innymi widokami

Najważniejszą cechą sys.dm_tran_database_transactions jest poziom obserwacji. Widok opisuje powiązanie transakcji z bazą danych, podczas gdy sys.dm_tran_current_transaction przedstawia transakcję przypisaną do bieżącego kontekstu wykonania. Z kolei sys.dm_tran_session_transactions pomaga ustalić, które sesje mają aktywne transakcje, a sys.dm_tran_active_transactions dostarcza szerszego obrazu transakcji działających w instancji.

Porównanie tych źródeł jest przydatne, ponieważ jedna transakcja może mieć kilka powiązań zależnych od sposobu wykonywania operacji. W przypadku transakcji obejmującej wiele baz danych widok bazodanowy może zwrócić osobne informacje dla każdej uczestniczącej bazy. Nie należy więc utożsamiać liczby wierszy z liczbą niezależnych transakcji bez sprawdzenia identyfikatora transakcji oraz bazy, której dotyczy dany rekord.

Wśród pól szczególnie istotnych diagnostycznie znajdują się identyfikatory transakcji i bazy danych, informacje o stanie transakcji, typie transakcji oraz liczbie stron dziennika związanych z daną transakcją. Konkretna dostępność i znaczenie kolumn zależą od wersji SQL Server, dlatego przy tworzeniu skryptu diagnostycznego należy sprawdzić dokumentację używanej wersji oraz metadane widoku. Nie powinno się zakładać, że każdy serwer udostępnia dokładnie taki sam zestaw kolumn.

Przykładowe zapytanie pozwalające rozpocząć analizę może wyglądać następująco:

SELECT database_id, transaction_id, transaction_begin_time, transaction_type, transaction_state
FROM sys.dm_tran_database_transactions
ORDER BY transaction_begin_time;

Takie zestawienie pokazuje transakcje przypisane do baz, ale nie rozstrzyga jeszcze, czy dana transakcja jest problemem. Długi czas trwania może wynikać z uzasadnionej operacji, oczekiwania na użytkownika, otwartego kursora, błędnej obsługi połączenia albo procesu, który utracił możliwość prawidłowego zakończenia pracy.

SYS.DM_TRAN_DATABASE_TRANSACTIONS — typowe problemy i interpretacja

Jednym z najczęstszych zastosowań tego widoku jest poszukiwanie przyczyny rosnącego dziennika transakcji. Jeżeli aktywna transakcja utrzymuje najstarszy punkt wymagany do odzyskiwania, część wpisów dziennika nie może zostać zwolniona zgodnie z normalnym cyklem. W efekcie plik dziennika może zajmować coraz więcej miejsca, mimo że wykonywane operacje nie wydają się szczególnie duże. W takim przypadku trzeba ustalić, czy transakcja nadal wykonuje pracę, oczekuje na zasób, czy pozostaje otwarta z powodu błędu w aplikacji.

Inny problem stanowią blokady. Otwarta transakcja może utrzymywać blokady na obiektach potrzebnych innym sesjom. Sam widok bazodanowy nie pokazuje pełnej hierarchii blokowania, dlatego należy zestawić go z informacjami o żądaniach i oczekiwaniach. Pomocne jest sprawdzenie, czy transakcja ma powiązaną sesję, jakie polecenie jest aktualnie wykonywane oraz czy sesja oczekuje na blokadę, wejście i wyjście, zasób dyskowy lub inny element środowiska wykonawczego.

Warto też zwrócić uwagę na różnicę między transakcją aktywną a transakcją, która tylko przez krótki moment pojawia się w odczycie. DMV-y są odczytem dynamicznym. Dwa zapytania wykonane w niewielkim odstępie czasu mogą zwrócić różne wyniki, ponieważ transakcje mogły zostać zatwierdzone, wycofane lub zakończone między odczytami. W diagnostyce incydentu przydatne jest wykonywanie kilku obserwacji i zapisywanie czasu pomiaru.

Nie należy również wyciągać wniosku, że każda transakcja obejmująca wiele wpisów dziennika jest błędna. Duże operacje wsadowe, przebudowa danych, masowe aktualizacje albo importy mogą prawidłowo generować znaczną aktywność. Znaczenie ma zestawienie czasu trwania, wielkości operacji, blokad, stanu sesji i oczekiwanego zachowania aplikacji.

SYS.DM_TRAN_DATABASE_TRANSACTIONS — praktyczne wskazówki diagnostyczne

Analizę najlepiej rozpocząć od ustalenia bazy danych, identyfikatora transakcji i czasu jej rozpoczęcia. Następnie należy odszukać powiązanie z sesją oraz bieżącym żądaniem. Pozwala to odróżnić transakcję wykonywaną od transakcji, która pozostaje otwarta bez postępu. Przydatne jest także sprawdzenie tekstu ostatniego polecenia, nazwy aplikacji przekazanej w połączeniu, nazwy hosta oraz loginu, o ile takie informacje są dostępne i wiarygodne.

Podczas zbierania danych należy unikać pochopnego kończenia sesji. Wymuszenie wycofania może uruchomić długotrwały proces cofania zmian, a jego skutki mogą być bardziej odczuwalne niż pierwotne oczekiwanie. Najpierw powinno się potwierdzić, że sesja rzeczywiście blokuje pracę lub uniemożliwia prawidłowe odzyskanie miejsca w dzienniku. W razie potrzeby należy zabezpieczyć wyniki zapytań, informacje o blokadach i komunikaty aplikacji, aby później odtworzyć przebieg zdarzenia.

Dobrym rozwiązaniem jest przygotowanie powtarzalnego skryptu kontrolnego, który pokazuje identyfikator transakcji, bazę, czas rozpoczęcia, stan, informacje o dzienniku oraz powiązanie z sesją. Skrypt powinien obsługiwać brak danych, sytuacje z wieloma bazami i zmiany wersji silnika. Warto też ograniczyć częstotliwość odpytywania, ponieważ diagnostyka nie powinna sama generować zauważalnego obciążenia.

Jeżeli problem powraca, należy przeanalizować kod aplikacji. Częstą przyczyną jest rozpoczęcie transakcji przed operacją wymagającą udziału użytkownika, brak obsługi wyjątku, niewykonanie zatwierdzenia po pomyślnym zakończeniu albo pozostawienie połączenia w puli z aktywnym kontekstem transakcyjnym. W systemach korzystających z procedur składowanych trzeba sprawdzić także ścieżki błędów i zachowanie przy częściowym wykonaniu operacji.

SYS.DM_TRAN_DATABASE_TRANSACTIONS — kiedy zgłosić się do serwisu

Do konsultacji warto przekazać sprawę, gdy aktywna transakcja przez dłuższy czas blokuje inne operacje, dziennik systematycznie się powiększa, aplikacja zgłasza błędy zatwierdzania albo odczyty DMV wskazują na niespójność między sesją, żądaniem i bazą danych. Zgłoszenie powinno zawierać wersję SQL Server, nazwę bazy, czas wystąpienia problemu, wyniki zapytań diagnostycznych oraz opis tego, co użytkownicy obserwują. Nie powinno się przesyłać haseł ani pełnych danych wrażliwych.

Ważne jest także rozróżnienie problemu silnika bazy od problemu komputera, systemu operacyjnego, sieci lub aplikacji klienckiej. Jeżeli komputer nie wykonuje poleceń, połączenie jest niestabilne, system zawiesza się albo narzędzie administracyjne nie uruchamia się prawidłowo, potrzebna może być szersza diagnostyka stanowiska. Warszawskie Pogotowie Komputerowe 24/7 może zostać wskazane jako punkt kontaktu przy analizie problemów ze sprzętem komputerowym i środowiskiem pracy, natomiast interpretację konfiguracji SQL Server powinno się prowadzić z uwzględnieniem uprawnień, wersji silnika oraz procedur obowiązujących w danym środowisku.

Najważniejsza zasada brzmi: sys.dm_tran_database_transactions należy odczytywać razem z kontekstem sesji, żądania, blokad i dziennika transakcji. Dopiero takie połączenie pozwala ocenić, czy widoczna transakcja jest normalnym etapem pracy, chwilowym oczekiwaniem, czy sygnałem błędu wymagającym interwencji.