Log typu undo

• Dodatkowy rodzaj wpisu do logu
  • <T,X,v> - transakcja T zmienia wartość elementu X (na coś, nie wiemy, na co); przed zmianą X miał wartość v

  
  

• Warunki, jakie musi spełniać undo log
  • wpis <T,X,v> ma się pojawić na dysku zanim na dysk zostanie zapisana nowa wartość X,
  • jeśli T kończy się COMMITem, <COMMIT T> ma się pojawić w logu możliwie szybko po zapisie wszystkich zmienionych przez T elementów na dysk, ale nie wcześniej.

  
  

  Przykad 1   Przykład logu dla transakcji, która wykonuje następujące czynności:

      READ(A,t); t:=t*2; WRITE(A,t);
      READ(B,t); t:=t*2; WRITE(B,t);
  

  Niech A ma początkowo wartość 4, a B 9.

  krok	akcja	log
  1		<START T>
  2	READ(A,t)
  3	t:= t*2
  4	WRITE(A,t)	<T,A,4>
  5	READ(B,t)
  6	t:=t*2
  7	WRITE(B,t)	<T,B,9>
  8	FLUSH LOG
  9	OUTPUT(A)
  10	OUTPUT(B)
  11		<COMMIT T>
  12	FLUSH LOG

  
  

• Przywracanie spójności bazy danych z logiem undo
  Czytamy log od końca.
  1. Dla każdego wpisu <T,X,v>:
     • jeśli był <COMMIT T>, to nic (wszystkie zmiany dokonane przez transakcję zostały zapisane na dysk)
     • wpp - T jest niezakończoną transakcją i być może nie wszystkie zmiany, które miała wykonać zostały zapisane na dysk; w takiej sytuacji T jest cofana, czyli X bedzie miał zmienioną wartość na v
  2. Dla każdej wycofanej transakcji T:
     • wpisz do logu <ABORT T>
  3. FLUSH LOG

  
  

  Przykad 2   Rozważmy sekwencje akcji z poprzedniego przykładu.

  1. Jeśli awaria nastąpiła po 12. kroku, transakcja T nie jest cofana, nic się nie zmiania
  2. Jeśli ostatnim wpisem w logu jest <T,B,9>, to awaria nastąpiła po kroku 7. i przed 12. Zmiany dokanane przez T mogły zostać zapisane na dysku lub nie, nie wiadomo, wobec czego T jest cofana, wartość B zostaje zmieniona na 9, a A na 4. Na końcu logu pojawia się napis <ABORT T>.

  
  

• Checkpoint Chcielibyśmy móc powiedzieć, że log od pierwszego wpisu do któregoś miejsca nie będzie już nam nigdy potrzebny i np. wykorzystać miejsce, które zajmuje.
  Po zakończeniu transakcji T, kiedy w logu pojawi się wpis <COMMIT T>, żadne informacje dotyczące T nie będą nam już potrzebne. Nie można jednak skasować zawartości logu przed <COMMIT T>, gdyż być może inne transakcje rozpoczęły się i nie zakończyły.
  
  Najprostszym sposobem na rozwiązanie tego problemu jest blokujący checkpoint:
  • zablokuj nowe transakcje,
  • poczekaj na zakończenie aktualnie działających transakcji,
  • wstaw do logu znacznik <CKPT>,
  • FLUSH LOG,
  • odblokuj oczekujące transakcje.
  Zawartość logu przed punktem kontrolnym <CKPT> może zostać usunięta.

  
  

• Nonquiescent checkpoint - nieblokujący punkt kontrolny Poprzednie rozwiązanie wymaga, aby na pewnien czas, być może długi, zablokować dostęp do bazy danych. Nie zawsze jest to możliwe. Musimy zatem mieć inną metodę, która nie wymaga blokowania transakcji.

  
  

• Nonquiescent checkpoint:
  • wpisz do logu <START CKPT(T$_1$,...,T$_k$)>, gdzie T$_1$,..., T$_k$ są wszystkimi aktualnie aktywnymi transakcjami, FLUSH LOG,
  • czekaj na zakończenie T$_1$,...,T$_k$, nie blokując przy tym innych transakcji,
  • wpisz do logu <END CKPT>, FLUSH LOG.

  
  

• Przywracanie spójności z logiem undo i checkpointami Czytamy log od końca. Możemy spotkać wcześniej <END CKPT> albo <START CKPT(T$_1$,...,T$_k$)>
  • Jeśli najpierw napotkamy <END CKPT>, to wiemy, że wszystkie transakcje, które mogły się nie zakończyć, zaczeły się po poprzednim <START CKPT(T$_1$,...,T$_k$)>, stąd nie musimy czytać wcześniejszych wpisów
  • Jeśli najpierw znajdziemy <START CKPT(T$_1$,...,T$_k$)>, to awaria miała miejsce podczas checkpointa. Jedyne transakcje, które mogły się nie zakończyć przed awarią to te, które zaczeły sięe po <START CKPT(T$_1$,...,T$_k$)> oraz T$_1$,...,T$_k$, więc wystarczy czytać log do <START T$_i$>, gdzie T$_i$ jest tą transakcją sposród T$_1$,...,T$_k$, która rozpoczęła się najwcześniej.
    ( Nie przejdziemy dalej niż do poprzedniego znacznika początku checkpointa )

  
  

  Przykad 3   Mamy następujący log:
  

  1	<START T$_1$>
  2	<T$_1$,A,5>
  3	<START T$_2$>
  4	<T$_2$,B,10>
  5	<START CKPT(T$_1$,T$_2$)>
  6	<T$_2$,C,15>
  7	<START T$_3$>
  8	<T$_1$,D,20>
  9	<COMMIT T$_1$>
  10	<T$_3$,E,25>
  11	<COMMIT T$_2$>
  12	<END CKPT>
  13	<T$_3$,F,30>

  • Jeśli awaria nastąpiła po 13. wpisie, jedyną transakcją wycofaną będzie T$_3$
  • Jeśli awaria nastąpiła po 10. wpisie, wycofane zostaną zmiany dokonane przez transakcje T$_2$ i T$_3$. Cofamy się w logu do wpisu nr 3.