Zgodnie z właściwościami ACID dotyczącymi wykonywania transakcji wymaganie trwałości (ang. durability) oznacza, że
A. dane zatwierdzone przez transakcję powinny być dostępne niezależnie od tego, co się będzie działo po jej zakończeniu.
B. transakcja może być w pewnych warunkach podzielona na dwa niezależne etapy.
C. w czasie wykonania transakcji dane mogą być modyfikowane przez inne transakcje.
D. w przypadku naruszenia spójności bazy danych transakcja usuwa tabele z kluczami obcymi.
Pytanie z egzaminu CKE, czerwiec 2018 (arkusz E.14-X-18.06).
Właściwość trwałości w ACID oznacza, że po zatwierdzeniu transakcji, czyli po wykonaniu operacji COMMIT, jej wynik nie powinien zniknąć nawet wtedy, gdy później wystąpi awaria systemu, restart serwera, błąd zasilania albo problem z aplikacją. Innymi słowy: jeśli bank zaksięgował przelew i transakcja została zatwierdzona, to po ponownym uruchomieniu bazy danych ten przelew nadal ma być zapisany. To jest właśnie sens durability. W praktyce systemy baz danych realizują to przez dzienniki transakcyjne, mechanizmy WAL, zapisy na trwałym nośniku, punkty kontrolne oraz procedury odtwarzania po awarii. Moim zdaniem to jedna z najważniejszych cech baz danych, bo użytkownik nie musi się zastanawiać, czy zapisane dane naprawdę zostały zapisane. Dobra praktyka branżowa polega na tym, żeby nie uznawać operacji za zakończoną tylko dlatego, że aplikacja wyświetliła komunikat. Liczy się dopiero poprawne zatwierdzenie transakcji przez silnik bazy danych. Trwałość współpracuje z pozostałymi cechami ACID: atomowością, spójnością i izolacją, ale odpowiada konkretnie za to, że zatwierdzone dane przetrwają po zakończeniu transakcji.
W tym pytaniu łatwo pomylić różne cechy ACID albo nawet dopisać bazie danych zachowania, których ona absolutnie nie powinna wykonywać. Naruszenie spójności danych nie oznacza, że transakcja usuwa tabele z kluczami obcymi. To byłoby bardzo niebezpieczne i zupełnie sprzeczne z dobrymi praktykami projektowania baz danych. Gdy reguły integralności, na przykład klucz obcy, ograniczenie UNIQUE albo CHECK, zostaną naruszone, system bazodanowy zwykle odrzuca operację lub wycofuje transakcję. Nie kasuje struktury bazy, bo schemat danych jest osobną warstwą i powinien być chroniony. Z mojego doświadczenia taki błąd myślowy bierze się z tego, że ktoś kojarzy klucze obce z problemami przy usuwaniu rekordów, ale to nadal nie ma nic wspólnego z durability. Stwierdzenie, że w czasie wykonania transakcji dane mogą być modyfikowane przez inne transakcje, dotyczy raczej izolacji i poziomów izolacji, takich jak Read Committed, Repeatable Read czy Serializable. Izolacja określa, jak bardzo jedna transakcja widzi działania innych transakcji i czy mogą pojawić się problemy typu dirty read, non-repeatable read albo phantom read. Trwałość nie mówi o współbieżnym dostępie, tylko o tym, co dzieje się po zatwierdzeniu danych. Również podział transakcji na dwa niezależne etapy nie opisuje cechy durability. Transakcja w modelu ACID powinna być traktowana jako logiczna całość: albo wszystkie jej operacje zostaną wykonane i zatwierdzone, albo całość zostanie wycofana. Można spotkać różne techniki zarządzania transakcjami rozproszonymi, na przykład protokół two-phase commit, ale to nie znaczy, że durability polega na dzieleniu transakcji. Poprawne rozumienie jest takie: po COMMIT baza danych ma zapewnić, że zapisane dane będą możliwe do odtwórzenia nawet po awarii. Dlatego używa się logów transakcyjnych, kopii zapasowych, replikacji i sprawdzonych mechanizmów odzyskiwania.