Wstęp

• Rodzaje awarii, jakimi będziemy się zajmować:
  • utrata danych z pamięci głównej np. wskutek braku zasilania
  • uszkodzenie medium przechowującego dane z bazy

  
  

• Cel:
  • doprowadzenie bazy danych po awarii do stanu spójnego (i możliwie aktualnego), m.in. zapewnienie atomowości transakcji w przypadki awarii, kiedy część zmian dokonanych przez transakcję może być zapisana na dysk, a część nie.

  
  

• Elementem będziemy nazywać dowolny "obiekt" z bazy danych, do którego transakcja może mieć dostęp. Elementem może być np. relacja, obiekt, blok dyskowy, krotka itp. O elemencie będziemy zakładać tylko tyle, że mieści się w jednym bloku dyskowym i nie będziemy rozważać sytuacji, gdy część zmodyfikowanego elementu została zapisana na dysk, a część nie.

  
  

• Operacje związane z przenoszeniem danych:
  • INPUT(X):: skopiuj blok dyskowy zawierający element X do bufora pamięci głównej
  • READ(X,t):: skopiuj element X do zmiennej t, znajdującej się w lokalnej przestrzeni transakcji T; jeśli X nie ma w pamięci, najpierw wykona się INPUT(X)
  • WRITE(X,t):: skopiuj wartość zmiennej t z lokalnej przestrzeni transakcji T do bufora pamięci; jeśli w pamięci nie ma bloku zawierającego X, najpierw wykona się INPUT(X), następnie nowa wartość zostanie skopiowana do bufora
  • OUTPUT(X):: skopiuj blok zawiarający X z bufora na dysk

  
  

• Log - plik z wpisami, mówiącymi, co która transakcja zmodyfikowała. W związku z tym, że wpisy do logu nie muszą być od razu kopiowane na dysk, a czasem chcemy, by w jakimś momencie tak sie stało, mamy operację FLUSH LOG, wymuszającą zapis na dysk.

  
  

• Wpisy do logu:
  • <START T> - początek wykonywania się transakcji T
  • <COMMIT T> - zakończenie wykonywania się transakcji T i zatwierdzenie zmian przez nią dokonanych (ale widząc taki napis nie mamy pewności, że na dysku znajdują się uaktualnione dane)
  • <ABORT T> - transakcja T nie mogła pomyślnie zakończyć się, żadne zmiany nie mogą być skopiowane na dysk
  • wpisy zależne od rodzaju logu