Obsługa transakcji nondurable

Transakcje nietrwałe przyspieszają zapis kosztem ryzyka utraty ostatnich zmian przy nagłym zatrzymaniu instancji.

Transakcja nondurable a potwierdzenie zapisu

Obsługa transakcji nondurable oznacza przyjęcie takiej konfiguracji zapisu, w której zakończenie transakcji może zostać potwierdzone aplikacji, zanim wszystkie odpowiadające jej zmiany zostaną trwale zapisane na nośniku. Silnik bazy danych może umieścić informacje w pamięci operacyjnej albo w buforze systemu operacyjnego i uznać operację za zakończoną, nie czekając na fizyczne zakończenie zapisu. Dzięki temu czas odpowiedzi jest krótszy, ponieważ proces aplikacyjny nie musi oczekiwać na operacje wejścia-wyjścia.

Nondurable nie oznacza, że transakcja jest od razu nieważna ani że jej instrukcje są ignorowane. Do momentu awarii może być widoczna i używana zgodnie z pozostałymi właściwościami transakcji. Ograniczenie dotyczy przede wszystkim gwarancji trwałości, czyli pewności, że zatwierdzone zmiany przetrwają nagłe zatrzymanie procesu, systemu operacyjnego, instancji bazy danych albo całego komputera.

Co może zostać utracone po awarii

Jeżeli instancja zostanie zatrzymana przed opróżnieniem buforów na trwały nośnik, ostatnie transakcje nondurable mogą nie odtworzyć się po ponownym uruchomieniu. W praktyce utrata obejmuje zwykle część zmian, które zostały już potwierdzone klientowi, ale nie zostały jeszcze utrwalone. Rozmiar takiego okna zależy od sposobu buforowania, obciążenia wejścia-wyjścia, opóźnień nośnika oraz ustawień konkretnego silnika. Nie można więc utożsamiać szybkiego potwierdzenia z trwałym zapisem.

Podczas odzyskiwania po awarii silnik analizuje dostępne informacje dziennika transakcji, pliki danych i metadane potrzebne do przywrócenia spójnego stanu. Zmiany, które zostały zapisane wystarczająco wcześnie, mogą zostać zachowane, natomiast zmiany pozostające wyłącznie w pamięci zostają utracone. Może to prowadzić do sytuacji, w której aplikacja otrzymała odpowiedź o powodzeniu operacji, lecz po restarcie nie znajdzie utworzonego rekordu, zaktualizowanej wartości albo usunięcia, które wcześniej zostało potwierdzone.

Różnica między trwałością a pozostałymi właściwościami transakcji

Trwałość jest jednym z odrębnych aspektów modelu transakcyjnego. Nie należy jej mylić z atomowością, spójnością ani izolacją. Atomowość określa, czy zestaw zmian zostanie wykonany w całości albo wycofany jako całość. Spójność odnosi się do zachowania reguł i ograniczeń danych. Izolacja opisuje widoczność równocześnie wykonywanych transakcji. Konfiguracja nondurable zmienia przede wszystkim gwarancję przetrwania zatwierdzonego wyniku po awarii, a nie samą logikę zatwierdzania i wycofywania operacji.

Transakcja nondurable może więc nadal być atomowa w czasie normalnej pracy. Jeżeli wystąpi błąd instrukcji przed zatwierdzeniem, silnik może wycofać jej częściowe zmiany zgodnie ze swoim modelem transakcyjnym. Problem pojawia się po nagłym zatrzymaniu, gdy stan pamięci nie zostaje już prawidłowo zapisany. Z tego powodu aplikacja nie powinna traktować samego komunikatu o zatwierdzeniu jako dowodu, że dane przetrwają każdą awarię, jeśli używany tryb celowo ogranicza trwałość.

Dobór trybu i diagnostyka zachowania zapisu

Tryb nondurable ma sens tylko wtedy, gdy krótszy czas odpowiedzi jest ważniejszy niż możliwość odtworzenia każdej ostatniej zmiany. Przykładem może być zapis danych tymczasowych, których źródło można ponownie odczytać, albo obszar roboczy, w którym utrata niewielkiej liczby najnowszych wpisów nie powoduje nieakceptowalnych skutków. Nie jest to właściwy wybór dla danych, których odtworzenie jest niemożliwe lub których utrata zmienia stan rozliczeń, zamówień, konfiguracji albo procesów biznesowych.

Podczas diagnostyki należy porównać moment potwierdzenia transakcji z momentem trwałego zapisu oraz sprawdzić, czy ustawienie dotyczy całej instancji, konkretnej bazy, połączenia czy pojedynczej operacji. Warto także przeanalizować dzienniki awarii, przebieg automatycznego odzyskiwania, komunikaty o opróżnianiu buforów i opóźnienia urządzenia magazynującego. Test powinien obejmować kontrolowane przerwanie pracy, ponowne uruchomienie oraz sprawdzenie, które zatwierdzone rekordy rzeczywiście przetrwały. Sama obecność danych przed restartem nie potwierdza trwałości, ponieważ mogą one nadal znajdować się wyłącznie w pamięci.

Jeżeli po awarii występują braki wśród ostatnich zatwierdzonych zmian, należy ustalić, czy wynik jest zgodny z zamierzonym trybem nondurable, czy też wskazuje na błędną konfigurację, awarię nośnika, problem z dziennikiem albo nieprawidłowe zamykanie procesu. W razie potrzeby tryb zapisu trzeba dobrać ponownie do znaczenia danych, wymagań aplikacji i akceptowanego okna utraty zmian. Zmiana ustawienia powinna być poprzedzona kopią zapasową oraz testem odzyskiwania, ponieważ zwiększenie trwałości może poprawić bezpieczeństwo zapisu kosztem większych opóźnień wejścia-wyjścia.