Log typu undo/redo

• Wady poprzednich rozwiązań:
  • log undo wymaga, by zmodyfikowane dane były zapisywane na dysk natychmiast po zakończeniu transakcji, zwiększając być może potrzebną ilość operacji wejścia/wyjścia
  • log redo wymaga trzymania w pamięci wszystkich zmodyfikowanych bloków w buforach zanim transakcja zakończy się, być może zwiększając średnią ilość buforów potrzebnych transakcji


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

  
  

• Warunki, jakie musi spełniać undo/redo log
  • wpis <T,X,v,w> ma się pojawić w logu przed zapisem na dysk nowej wartości elementu X, zmodyfikowanego przez transakcję T
  W tym przypadku <COMMIT T> może się pojawić w dowolnym momencie względem zmian zapisywanych na dysk (przed zmianą, po, po jednej zmianie i przed drugą,...)

  
  

  Przykad 6   Przykadowa zawartość logu dla transakcji mnożącej wartości elementów A i B przez 2:
  

  
  

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

  
  

• Przywracanie spójności bazy danych z logiem undo/redo
  • zapisz wszystkie zmiany dokonane przez transakcje, które zakończyły się COMMITem w kolejności od najwcześniejszych
  • cofnij wszystkie zmiany dokonane przez pozostałe transakcje, zaczynając od ostatnich

  
  

• Problem opóźnionego COMMITa
  Po wpisaniu <COMMIT T> do logu, bufor nie jest opróżniany, więc w przypadku późniejszej awarii T będzie raczej cofana niż ponawiana. Jeśli chcemy, żeby było odwrotnie, możemy dodać warunek, aby <COMMIT T> pojawiał się na dysku tak szybko, jak jest to możliwe.

  
  

• Checkpoint dla logu undo/redo
  1. wpisz <START CKPT(T$_1$,...,T$_k$)> do logu, gdzie T$_1$,...,T$_k$ są wszystkimi aktywnymi transakcjami, FLUSH LOG
  2. zapisz na dysk wszystkie zmodyfikowane bufory
  3. wpisz <END CKPT> do logu, FLUSH LOG

  
  Ale transakcje muszą speniać warunek:

  • Żadna zmodyfikowana wartość nie może pojawić się (nawet w buforach pamięci) dopóki transakcja nie jest pewna, że zakończy się COMMITem

  
  

• Przywracanie spójności z logiem undo/redo i checkpointami

  
  

  Przykad 7   Log:
  

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

  
  

  • 6: w tym miejscu jedyną aktywną transakcją jest T$_2$, zapisujemy zmiany dokonane na elementach A i B, jeśli jeszcze nie zostały zapisane
  • załóżmy, że awaria pojawia się po wpisie nr 12. T$_2$ i T$_3$ są zakończonymi transakcjami, których modyfikacje niekoniecznie znalazły sie na dysku - zapisujemy więc te zmiany. Transakcja T$_1$ zakończyła się przed ostanim checkpointem, więc jej zmiany na pewno są zapisane, możemy więc je zignorować
  • jeśli awaria nastąpiła zaraz po wpisie nr 11, to zapisalibyśmy zmiany dokonane przez T$_2$ i wystepujace po <START CKPT(T$_2$)> oraz wycofali zmiany dokonane przez T$_3$