Log typu redo

• Dodatkowy rodzaj wpisu do logu
  • <T,X,v> - transakcja T zmienia wartość elementu X na v

  
  

• Warunki, jakie musi speniac redo log
  • wpis <T,X,v> ma się pojawić na dysku zanim na dysk zostanie zapisana nowa wartość X,
  • <COMMIT T> ma się pojawić na dysku przed zapisem na dysku pierwszego zmodyfikowanego przez T elementu

  
  

  Przykad 4   Zawartość logu dla transakcji mnożącej wartość elementów A i B przez 2 (A ma początkowo wartość 4, B 9):
  

  
  

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

  
  

• Przywracanie spójności bazy danych z logiem redo Jeśli dla transakcji T nie ma wpisu <COMMIT T>, to nie zapisała ona żadnych zmian do bazy. Takie transakcje możemy traktować tak, jakby się nigdy nie rozpoczęły.
  1. zidetyfikuj transakcje zakończone COMMITem
  2. dla każdego wpisu <T,X,v>, czytając od poczatku logu:
     1. jeśli T nie jest zakończoną transakcją, nie rób nic
     2. wpp - zapisz wartość v dla elementu X
  3. dla każdej niezakończonej transakcji T wpisz <ABORT T>
  4. FLUSH LOG

  
  

• Checkpoint dla logu redo
  1. wpisz <START CKPT(T$_1$,...,T$_k$)>, gdzie T$_1$,...,T$_k$ sa wszystkimi aktywnymi transakcjami (przed COMMITem), FLUSH LOG
  2. zapisz na dysk te elementy, które zostały zmodyfikowane przez transakcje pomyślnie zakończone w momencie startu procedury, i takie, których wartości są w buforach, ale jeszcze nie na dysku
  3. wpisz <END CKPT>, FLUSH LOG

  
  

• Przywracanie spójności z logiem redo i checkpointami Możemy mieć 2 przypadki w zależności od tego, co pojawiło się jako ostanie:
  • <END CKPT> - każda transakcja, która zakończyła się przed ostatnim <START CKPT(T$_1$,...,T$_k$)> ma swoje modyfikacje zapisane na dysku. Jedyne transakcje, które nas interesują to T$_i$ oraz te, które zaczeły się po <START CKPT(T$_1$,...,T$_k$)> - postępujemy z nimi jak w przypadku braku punktów kontroli.
    Przez ile znaczników początku checkpoint trzeba się cofnąć, żeby mieć pewność, że dla każdej transakcji T, która nas interesuje, znajdziemy znacznik <START T>?
  • <START CKPT(T$_1$,...,T$_k$)> - nie wiemy, czy zadanie tego checkpointa zostało wykonane, musimy więc założyć, że nie. Cofamy się do poprzedniego <START CKPT(U$_1$,...,U$_m$)> i postępujemy jak w przypadku powyżej, gdyby nie było <START CKPT(T$_1$,...,T$_k$)>

  
  

  Przykad 5   Log:
  

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

  • jeśli awaria nastapiła po 12. wpisie, to transakcjami do ponownego wykonania są T$_2$ i T$_3$, cofamy się do wpisu nr 3
  • jeśli ostatnim wpisem w logu jest nr 11, jedyną transakcją ponawianą jest T$_2$; na końcu pliku pojawi się <ABORT T$_3$>
  • jeśli awaria nastąpiła zaraz po wpisie 9, czyli przed <END CKPT>, musimy cofnąć się do poprzedniego checkpointa - w tym przypadku po prostu na początek logu, wykonać modyfikacje wskazane przez T$_1$ (jedyna zakonczona pomyślnie transakcja), wpisać <ABORT T$_2$> i <ABORT T$_3$>.