Transakcje ręczne

Transakcje ręczne wymagają jawnego rozpoczęcia i zakończenia przez programistę.

Jawne sterowanie granicami transakcji

SQL Server pracuje domyślnie w trybie automatycznego zatwierdzania: każda instrukcja stanowi osobną transakcję, kończoną natychmiast po wykonaniu. Transakcja ręczna wyłamuje się z tego schematu — programista otwiera ją instrukcją BEGIN TRANSACTION, wykonuje dowolną liczbę operacji i decyduje, czy całość ma zostać utrwalona przez COMMIT, czy wycofana przez ROLLBACK. Dzięki temu zestaw powiązanych zmian, jak zdjęcie towaru ze stanu i zapisanie pozycji dokumentu sprzedaży, jest niepodzielny: albo zapisze się wszystko, albo nic. Bieżący poziom zagnieżdżenia pokazuje zmienna @@TRANCOUNT, a stan transakcji po błędzie sprawdza funkcja XACT_STATE.

Zagnieżdżenie, punkty zapisu i tryb domyślny

Zagnieżdżanie transakcji w SQL Server jest pozorne. Kolejne BEGIN TRANSACTION zwiększa jedynie licznik, wewnętrzne zatwierdzenie nic nie utrwala, a jedno wycofanie unieważnia całą strukturę aż do poziomu zewnętrznego. Do częściowego cofania służą punkty zapisu zakładane instrukcją SAVE TRANSACTION, do których wraca się wycofaniem z podaną nazwą. Osobnym trybem jest ustawienie IMPLICIT_TRANSACTIONS na włączone — wtedy pierwsza instrukcja modyfikująca dane sama otwiera transakcję, ale zamknąć ją musi już programista. To ustawienie bywa źródłem najbardziej zagadkowych blokad, bo aplikacja pozostawia otwartą transakcję, o której nikt nie wie. Warto też włączać XACT_ABORT, dzięki czemu błąd w środku bloku przerywa i wycofuje całość zamiast kontynuować z połową zapisanych zmian.

Otwarta transakcja jako źródło awarii produkcyjnej

Niezamknięta transakcja trzyma blokady na zmienionych wierszach, a inne sesje czekają — użytkownicy zgłaszają wtedy, że program przestał odpowiadać przy zapisie dokumentu. Druga, groźniejsza konsekwencja dotyczy dziennika transakcji: jego nieaktywna część nie może zostać zwolniona, dopóki najstarsza otwarta transakcja żyje, więc plik dziennika rośnie aż do wypełnienia dysku i pojawia się komunikat o braku miejsca w bazie. Najstarszą aktywną transakcję wskazuje polecenie DBCC OPENTRAN, a łańcuch oczekiwań widać w widokach systemowych opisujących sesje i żądania. Osobnym zjawiskiem jest zakleszczenie dwóch sesji blokujących się nawzajem — serwer wybiera wtedy ofiarę i przerywa jej pracę błędem o numerze 1205, którą aplikacja powinna obsłużyć przez ponowienie operacji.

Bazy programów handlowych pod naszą opieką

Wdrażamy i serwisujemy oprogramowanie handlowe oparte o SQL Server — Subiekt, WAPRO i Comarch — więc objawy w rodzaju zawieszającego się zapisu faktury albo pęczniejącego dziennika transakcji znamy z codziennej praktyki. Sprawdzamy wtedy, która sesja trzyma blokadę, czy nie zostawiło jej stanowisko z zawieszonym programem i czy tryb odzyskiwania bazy pasuje do przyjętego planu kopii zapasowych. Pracujemy również w nocy i w weekendy, bo takie prace przy bazie danych rzadko da się wykonać w godzinach handlu.