INFO
Sylabus
Transakcje w bazach danych
1. Po co transakcje? - Współbieżność
2. Po co transakcje? - Przeciwdziałanie awariom
3. Transakcja: jednostka działalności systemu
4. Przykładowa transakcja
5. Kryterium poprawności transakcji
6. Implementacja szeregowalności poprzez zamki
7. Zakleszczenie
8. Walka z zakleszczeniem
9. Metody bez zakleszczeń oparte na stemplach czasowych
10. Metody optymistyczne
11. Ziarnistość mechanizmu transakcji
12. Zmienna ziarnistość
13. Typy awarii i reakcje na awarie
14. Odtwarzanie po awarii - środki, terminy
15. Odtwarzanie po zerwaniu
16. Podstawowe algorytmy z zamkami
17. Komendy w SQL do przetwarzania transakcji
18. Zagnieżdżone transakcje
19. Przykład zagnieżdżonej transakcji
20. 2PC w systemach rozproszonych
21. Długie transakcje (transakcje projektowe)
22. Podsumowanie
Skorowidz
Wyście:
Wyklad VI. Wprowadzenie do transakcji w bazach danych (KURS SSR)
I II III IV V VI VII VIII IX X XI XII XIII XIV
« poprzedni punkt   następny punkt »

15. Odtwarzanie po zerwaniu

Warunek atomowości transakcji wymaga, aby w przypadku zerwania wszelkie wykonane przez nią czynności zostały odwrócone: baza danych ma wrócić do stanu sprzed transakcji.

Dwie strategie:
  1. Transakcje działają na własnych kopiach, które podmieniają z oryginalnymi obiektami w fazie commit. Wady: zwiększone zapotrzebowanie na pamięć, większa możliwość awarii w fazie commit (bardzo niebezpieczne).
  2. Transakcje działają bezpośrednio na bazie danych, ale w specjalnym pliku zwanym dziennikiem (log) zapisują wszelkie operacje aktualizacyjne których dokonały, wraz z obiektami przed i ew. po aktualizacji. W razie zerwania - baza danych jest odtwarzana do poprzedniego stanu poprzez czytanie logu “od tyłu”.
relation LOG( trans_id, obiekt_id, operacja, stary_obiekt, nowy_obiekt)
Write ahead log: w dzienniku zapisywane są zmiany przed ich dokonaniem. W razie awarii wiadomo, co było zrobione, czyli możliwe jest poprawne cofnięcie.

Czasami (SQL) stosuje się tryb oszczędny, w którym zmiany są zaznaczane w dzienniku, ale nie są naniesione w bazie danych. Prowadzi to do tego, że transakcja “nie widzi” własnych zmian, co jest sporą uciążliwością przy programowaniu i prowadzi do błędów.


16. Podstawowe algorytmy z zamkami

Dynamiczne dwufazowe blokowanie (2PL): transakcje ustanawiają zamki do czytania (S) które następnie mogą podwyższyć do zamków do aktualizacji (X). Jeżeli zamek jest S, to odrzucana jest próba założenia zamka X, jeżeli zamek jest X, to odrzucana jest jakakolwiek próba założenia innego zamka. System prowadzi dziennik i graf czekania, umożliwiając odtworzenie po zerwaniu i przeciwdziałając zakleszczeniu.

Czekasz-umieraj (wait-die) dwufazowy (WD): Tak jak dla 2PL, ale transakcja której odmówiono dostępu ginie. Są odmiany tego algorytmu: z dwóch transakcji w konflikcie ginie młodsza, ginie starsza, ginie ta, co się mniej narobiła, ginie ta, która jest mniej ważna, itd.

Dynamiczne dwufazowe blokowanie bez podwyższania zamków: tak jak 2PL, ale nie ma podwyższania zamków z S do X.

Wstępne żądanie zasobów (opis już był).


« poprzedni punkt   następny punkt »