Diagnostyka transakcji

Diagnostyka transakcji to proces analizy przebiegu i stanu operacji bazodanowych w celu identyfikacji problemów.

Zakres diagnostyki transakcji bazodanowej

Diagnostyka transakcji bazodanowej polega na odtworzeniu przebiegu operacji od momentu jej rozpoczęcia do zatwierdzenia albo wycofania. Analizuje się między innymi kolejność wykonywania instrukcji, odczyty i modyfikacje danych, blokady, czas oczekiwania oraz końcowy rezultat. Transakcja jest logiczną całością operacji, która powinna zachować spójność danych także wtedy, gdy jedna z instrukcji zakończy się błędem. W praktyce diagnostyka odpowiada na pytanie, czy problem wynika z błędnych danych wejściowych, nieprawidłowej logiki aplikacji, konfliktu współbieżnych operacji, przerwania połączenia czy niepoprawnego zarządzania zatwierdzaniem zmian.

Podczas analizy trzeba rozróżnić transakcję zakończoną pomyślnie, transakcję wycofaną oraz transakcję pozostawioną w stanie otwartym. Zatwierdzenie, określane jako commit, utrwala wykonane zmiany zgodnie z mechanizmem konkretnego silnika. Wycofanie, czyli rollback, usuwa skutki operacji objętych transakcją, o ile nie zostały wcześniej zatwierdzone lub wykonane poza jej zakresem. Sam komunikat o błędzie nie zawsze wskazuje przyczynę, ponieważ aplikacja może przechwycić wyjątek, pominąć rollback albo utracić połączenie przed zapisaniem pełnej informacji diagnostycznej.

Ślady wykonania, blokady i współbieżność

Jednym z najważniejszych elementów diagnostyki jest porównanie czasu rozpoczęcia transakcji z czasem wykonania poszczególnych instrukcji. Transakcja może działać długo nie dlatego, że pojedyncze zapytanie jest złożone, lecz dlatego, że oczekuje na blokadę założoną przez inną sesję. Blokada może dotyczyć zmodyfikowanego wiersza, większego zakresu danych albo obiektu używanego przez operację. W zależności od silnika i poziomu izolacji odczyt może czekać na zakończenie zapisu, odczytywać starszą wersję danych albo uczestniczyć w konflikcie prowadzącym do przerwania transakcji.

W logach i narzędziach monitorujących warto szukać identyfikatora sesji, identyfikatora transakcji, czasu oczekiwania, rodzaju blokady oraz instrukcji, która blokuje lub jest blokowana. Szczególnie istotny jest zakleszczenie, czyli deadlock. Powstaje ono wtedy, gdy co najmniej dwie transakcje wzajemnie oczekują na zasoby trzymane przez drugą stronę. Silnik zwykle wybiera jedną transakcję jako ofiarę i ją wycofuje, aby odblokować pozostałe. Aplikacja powinna rozpoznać taki błąd i, jeśli operacja jest powtarzalna, wykonać kontrolowaną próbę ponowienia z ograniczeniem liczby powtórzeń.

Spójność danych i poziom izolacji

Analiza transakcji obejmuje również sprawdzenie, jakie reguły spójności obowiązywały podczas jej wykonywania. Należy zweryfikować ograniczenia klucza głównego, kluczy obcych, wartości unikatowych, typów danych oraz warunków określonych przez ograniczenia kontrolne. Błąd naruszenia takiej reguły oznacza, że operacja nie może zostać utrwalona w danym kształcie. Jeżeli aplikacja obsłuży ten błąd bez wycofania całej transakcji lub bez prawidłowego zapisania stanu, kolejne operacje mogą zostać wykonane w nieoczekiwanym kontekście.

Ważnym parametrem jest poziom izolacji transakcji. Określa on, w jakim stopniu równoległe transakcje mogą wzajemnie obserwować swoje zmiany oraz jak silnie są chronione przed niespójnymi odczytami. Diagnostyka powinna ustalić, czy wystąpił odczyt niezatwierdzonych danych, powtórny odczyt zwrócił inny wynik, czy zakres danych zmienił się pomiędzy kolejnymi zapytaniami. Trzeba także sprawdzić, czy aplikacja nie utrzymuje transakcji przez czas obejmujący operacje niezwiązane z bazą, takie jak oczekiwanie na odpowiedź sieciową lub działanie interfejsu użytkownika. Takie rozszerzenie zakresu zwiększa czas blokowania zasobów.

Wnioski z analizy nieudanej operacji

Poprawna diagnostyka powinna zakończyć się ustaleniem konkretnego miejsca, w którym przepływ danych odbiega od oczekiwanego. Należy wskazać, czy transakcja rozpoczęła się, jakie instrukcje zostały wykonane, która instrukcja zakończyła się błędem, czy nastąpił rollback oraz czy połączenie zostało zwolnione. W przypadku braku zatwierdzenia trzeba rozstrzygnąć, czy był to zamierzony rollback, automatyczne wycofanie po błędzie, przekroczenie limitu czasu, zerwanie sesji czy rezultat błędnej obsługi wyjątków.

Przydatne jest odtworzenie scenariusza na kopii danych testowych z takim samym porządkiem operacji i podobnym poziomem współbieżności. Nie należy zmieniać danych produkcyjnych wyłącznie w celu potwierdzenia hipotezy. W środowisku diagnostycznym można porównać plan wykonania zapytań, czas operacji, liczbę odczytanych rekordów oraz wpływ indeksów, ale sama optymalizacja zapytania nie naprawi błędnego zakresu transakcji. Jeżeli problem dotyczy komputera, na którym uruchomiono aplikację bazodanową, analiza powinna objąć także stabilność połączenia, błędy systemowe, synchronizację czasu i dostępne zasoby, ponieważ przerwanie procesu może pozostawić operację niedokończoną z punktu widzenia aplikacji.