Trwałość transakcji

Trwałość transakcji to zasada ACID gwarantująca, że zatwierdzone zmiany przetrwają nawet awarię serwera.

Co oznacza trwałość transakcji w bazie danych

Trwałość transakcji, określana w skrócie jako „D” w modelu ACID, oznacza, że system zarządzania bazą danych powinien zachować skutki transakcji po jej zatwierdzeniu. Jeżeli aplikacja otrzyma potwierdzenie wykonania operacji, zapisane dane nie powinny zniknąć tylko dlatego, że chwilę później nastąpiła awaria procesu, systemu operacyjnego, serwera albo zasilania. Przykładem może być zatwierdzenie przelewu, zmiana stanu magazynowego lub zapis konfiguracji programu. Po ponownym uruchomieniu system powinien odtworzyć stan obejmujący zatwierdzone zmiany.

Trwałość nie oznacza, że każda operacja wpisana do formularza została zapisana. Dotyczy wyłącznie transakcji zakończonych zatwierdzeniem, zwykle wykonywanym przez instrukcję COMMIT albo mechanizm o równoważnym znaczeniu. Zmiany wykonane w transakcji zakończonej ROLLBACK nie są objęte gwarancją trwałości, ponieważ zostały wycofane. Podobnie dane znajdujące się jedynie w pamięci aplikacji, buforze systemu operacyjnego lub formularzu użytkownika mogą zostać utracone przed zatwierdzeniem.

Dziennik transakcyjny i zapis przed właściwymi danymi

Typowym mechanizmem realizacji trwałości jest dziennik transakcyjny, nazywany także logiem zapisu. Zanim system uzna transakcję za zatwierdzoną, zapisuje w dzienniku informacje potrzebne do odtworzenia zmian albo do ich bezpiecznego dokończenia. Stosowana w wielu systemach zasada WAL, czyli Write-Ahead Logging, wymaga, aby odpowiedni rekord dziennika trafił na trwały nośnik przed zapisaniem zmodyfikowanej strony danych w głównych plikach bazy. Dzięki temu po awarii można wykorzystać dziennik, nawet jeśli właściwe strony danych nie zostały jeszcze zapisane w docelowym miejscu.

Po zatwierdzeniu transakcji system może zwrócić aplikacji potwierdzenie dopiero wtedy, gdy uzna zapis dziennika za wystarczająco bezpieczny. W praktyce obejmuje to przekazanie danych do systemu operacyjnego, a przy określonej konfiguracji również wymuszenie ich opróżnienia z buforów urządzenia. Szczegóły zależą od konkretnego silnika, sterownika, systemu plików, kontrolera oraz nośnika. Dysk SSD, dysk twardy, pamięć podręczna kontrolera RAID i zasilanie awaryjne mogą mieć własne mechanizmy buforowania. Sama obecność pliku dziennika nie wystarcza więc do oceny gwarancji; liczy się cały łańcuch zapisu od silnika bazy do fizycznego nośnika.

Odtwarzanie zatwierdzonych zmian po awarii

Po niekontrolowanym zatrzymaniu systemu baza danych wykonuje procedurę odzyskiwania. Najpierw analizuje dziennik, aby ustalić, które operacje zostały zapisane przed awarią, a następnie ponawia zmiany należące do transakcji zatwierdzonych. Takie działanie nazywa się ponownym wykonaniem lub redo. Operacje rozpoczęte, lecz niezatwierdzone, są wycofywane przez undo albo równoważny mechanizm. Celem jest uzyskanie spójnego stanu, w którym zatwierdzone transakcje pozostają widoczne, a niezatwierdzone nie pozostawiają częściowych efektów.

Trwałość może być wspierana przez kopie zapasowe oraz archiwizowanie dzienników, ale nie jest tym samym co backup. Dziennik chroni przede wszystkim przed utratą zmian wskutek awarii podczas pracy, natomiast kopia zapasowa pozwala odtworzyć dane po uszkodzeniu plików, błędzie użytkownika, awarii całego urządzenia albo innym zdarzeniu obejmującym podstawowy nośnik. Jeżeli awaria zniszczy zarówno bazę, jak i jedyną kopię dziennika, sama gwarancja ACID nie zapewni odzyskania danych. Dlatego w zastosowaniach wymagających ciągłości pracy sprawdza się także regularność kopii, możliwość ich odczytu i czas potrzebny na odtworzenie.

Co warto zweryfikować na komputerze przed dalszymi krokami

Na komputerze użytkownika problemy z trwałością transakcji mogą wynikać z niestabilnego zasilania, uszkodzenia dysku, błędów pamięci masowej, przegrzewania, wadliwego sterownika lub nagłego resetowania systemu. Objawem bywa komunikat o odzyskiwaniu bazy po uruchomieniu programu, brak ostatnich zatwierdzonych wpisów, uszkodzony plik danych albo wielokrotne sprawdzanie systemu plików. Diagnostyka powinna obejmować analizę komunikatów aplikacji, stan dysku, temperatury, przewody i zasilacz, a także sprawdzenie, czy na urządzeniu pozostaje wolne miejsce potrzebne do zapisu dziennika i plików tymczasowych.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego przy problemach z utratą zapisów można rozpocząć od sprawdzenia nośnika, zasilania oraz objawów awarii systemu. Sama wymiana dysku nie zastępuje jednak poprawnie wykonanej kopii danych ani weryfikacji, czy program korzysta z właściwego mechanizmu zatwierdzania. Po naprawie warto odtworzyć kopię na sprawnym nośniku, uruchomić kontrolowany test zapisu i ponownego otwarcia danych oraz obserwować, czy po bezpiecznym restarcie zatwierdzone operacje nadal są dostępne.