Problem odtwarzania bazy danych Odtwarzanie bazy danych (recovery) Tadeusz Pankowski www.put.poznan.pl/~tadeusz.pankowski System bazy danych musi być w stanie odtworzyć swój poprawny stan w sposób automatyczny, a więc bez interwencji człowieka. Operacja odtwarzania powinna być automatycznie inicjowana w chwili restartu systemu. Organizacja systemu bazy danych i organizacja procesów jej przetwarzania musi być tak pomyślana, aby odtwarzanie takie było możliwe. bazy danych 1 bazy danych 2 Problem odtwarzania bazy danych (c.d.) Architektura systemu bazy danych Odtwarzanie realizuje postulat trwałości ze zbioru postulatów ACID. Odtwarzanie dotyczy awarii bazy danych wywołanych nieoczekiwanym przerwaniem przetwarzania transakcji (np. w wyniku awarii zasilania), a nie awarii krytycznych wywołanych np. uszkodzeniem pamięci dyskowej. Omawianego w dalszym ciągu odtwarzania (recovery) nie należy mylić z odtwarzaniem z archiwum (restoring). bazy danych 3 Baza danych Dziennik transakcji Restart T 1 T 2... T n Menedżer transakcji (MT) Planista Menedżer odtwarzania (MO) Fetch, Flush Menedżer pamięci chwilowej (MPCh) Pamięć chwilowa (PCh) Menedżer danych (MD) 4
Postępowanie z transakcjami w przypadku awarii Zarządzanie danymi w procesie odtwarzania struktury danych Odtwarzanie bazy danych 1 Działanie Nic 2 Roll forward (Redo) 3 Roll back (Undo) 4 Roll forward (Redo) 5 Roll back (Undo) Baza danych strony stałej wielkości Pamięć chwilowa (PCh) (cache) bufory o wielkości stron Dziennik transakcji (log) Listy transakcji: aktywnych, zatwierdzonych, odrzuconych Checkpoint Awaria systemu 5 bazy danych 6 Struktury danych baza danych Baza danych znajduje się w pamięci stałej. Przyjmujemy, że jej zawartość podzielona jest (fizycznie) na jednostki zwane stronami (blokami). Pojemność strony jest równa pojemności bufora. Niekiedy zakłada się, że zarówno w bazie danych, jak i w systemie buforów znajdują się pule stron/buforów różnej wielkości (np. pula o wielkości 8kB i pula o wielkości 32 kb). Struktury danych - PCh Pamięć chwilowa (podręczna) jest to system buforów przechowywanych w pamięci operacyjnej. W jednym buforze może być umieszczona jedna strona (blok) bazy danych. Liczba buforów jest niewielka w porównaniu z całą bazą danych stąd często przy próbie sprowadzenia kolejnego fragmentu bazy danych do PCh należy podjąć decyzję, który z buforów należy wykorzystać (proces ten nazywany jest wymianą stron). Wówczas zawartość tego bufora należy zapamiętać (ang. flash, write) w bazie danych. bazy danych 7 bazy danych 8
Struktury danych PCh (c.d.) Istotne jest kto zarządza wymianą stron. Możliwe są dwa rozwiązania: menedżer odtwarzania wówczas przy wymianie stron może być brana pod uwagę wiedza o stanie procesu przetwarzania/odtwarzania; menedżer pamięci chwilowej proces wymiany stron sterowany jest jakimś przyjętym algorytmem biorącym pod uwagę na przykład czas ostatniego dostępu do bufora (np. przy stosowaniu algorytmu LRU, Last Recently Used używany najdawniej zwalniany jest ten bufor, do którego ostatnie odwołanie miało miejsce najdawniej). Struktury danych PCh (c.d.) Wszelkie operacje na bazie danych (odczytywanie, zapisywanie) odbywa się za pośrednictwem PCh. Oznacza to, że strona (blok) danych bazy danych, do którego się odwołujemy, musi przed wykonaniem operacji znajdować się w PCh albo już tam jest, albo musi być tam sprowadzony. Zauważmy, że w przypadku awarii (na przykład zaniku zasilania) zawartość PCh jest tracona. bazy danych 9 bazy danych 10 Struktury danych dziennik transakcji (log) Struktury danych listy transakcji Dziennik transakcji, DzT, (ang. log) znajduje się w pamięci stałej. Zakładamy, że w dzienniku transakcji zapamiętane są wszystkie ostatnio zatwierdzona wartości wszystkich danych bazy danych (w praktyce stosuje się różne zabiegi optymalizacyjne). Dzięki DzT możliwe jest określenie ostatnio zatwierdzonych danych (należy w tym celu przeglądać dziennik z dołu do góry). Zawartość dziennika transakcji może być traktowana jako 3-kolumnowa tabela o następującej strukturze: Listy transakcji: LTA - lista transakcji aktywnych, LTZ - lista transakcji zatwierdzonych, LTO - lista transakcji odrzuconych. gdzie (t, x, v) DzT oznacza, że transakcja t nadała danej x wartość v. bazy danych 11 bazy danych 12
Algorytm UNDO/REDO Algorytm UNDO/REDO opisuje proces przetwarzania transakcji z uwzględnieniem możliwości odtworzenia bazy danych w przypadku awarii. Odtwarzanie bazy danych następuje w chwili restartu systemu po jego awarii. Algorytm UNDO/REDO jest stosowany wówczas, gdy w procesie odtwarzania konieczne jest wykonanie operacji UNDO dotyczącej przerwanych transakcji oraz operacji REDO dotyczącej zatwierdzonych transakcji. Algorytm UNDO/REDO (c.d.) UNDO oznacza przywrócenie poprzednich (zatwierdzonych) wartości tym danym, które były zmieniane przez transakcje przerwane przed ich zatwierdzeniem. Operacja jest konieczna wtedy, gdy strategia wymiany stron w PCh prowadzona jest przez MPCh niezależnie od MO. Może więc się zdarzyć, że blok danych z PCh został zapamiętany w bazie danych w momencie, gdy transakcja zapisująca w nim dane nie została jeszcze zatwierdzona. W przypadku awarii należy więc te zmiany wycofać. bazy danych 13 bazy danych 14 Algorytm UNDO/REDO (c.d.) Architektura systemu bazy danych REDO oznacza ponowne wykonanie operacji aktualizacji danych wykonanych przez transakcje zatwierdzone. Operacja ta jest konieczna wtedy, gdy MPCh prowadzi własną strategię wymiany stron. Może więc się zdarzyć, że mimo iż transakcja została zatwierdzona, to wykonane przez nią zmiany nie zostały jeszcze zrzucone z PCh do bazy danych. W przypadku awarii nastąpi utrata efektów pracy transakcji. Restart T 1 T 2... T n Menedżer transakcji (MT) Planista Menedżer odtwarzania (MO) bazy danych 15 Baza danych Dziennik transakcji Fetch, Flush Menedżer pamięci chwilowej (MPCh) Pamięć chwilowa (PCh) Menedżer danych (MD) 16
Algorytm UNDO/REDO (T, x, v) Algorytm UNDO/REDO Commit(T) 1. Dołącz transakcję T do listy transakcji aktywnych (LTA), jeśli jeszcze na niej nie występuje. 2. Jeśli x nie znajduje się w PCh, to sprowadź do PCh stronę zawierającą x. 3. Dołącz (T, x, v) do dziennika transakcji (DzT). 4. Przypisz danej x w PCh wartość v. 5. Zawiadom planistę o zakończeniu operacji. 1. Dałącz T do listy transakcji zatwierdzonych (LTZ). 2. Powiadom planistę o zatwierdzeniu transakcji T. 3. Usuń T z listy transakcji aktywnych (LTA). bazy danych 17 bazy danych 18 Algorytm UNDO/REDO Abort(T) 1. Dla każdej danej x zapisywanej przez T: jeśli x nie znajduje się w PCh, to sprowadź tam stronę zawierającą x, przypisz w PCh danej x uprzednią wartość x względem T (before image). 2. Dołącz T do listy transakcji odrzuconych. 3. Powiadom planistę o odrzuceniu transakcji T. 4. Usuń T z listy transakcji aktywnych. bazy danych 19 Algorytm UNDO/REDO Restart Wyczyść wszystkie bufory w PCh, REDONE := i UNDONE :=. Rozpocznij od ostatniego zapisu w DzT i przesuwaj się do jego początku. Dopóki nie przeanalizowano wszystkich zapisów w DzT, wykonuj: 1. Dla każdego zapisu (T, x, v), takiego że x REDONE UNDONE: jeśli x nie znajduje się w PCh, to sprowadź tam stronę zawierającą x; jeśli T jest na liście transakcji zatwierdzonych, przypisz danej x w PCh wartość v i przyjmij REDONE := REDONE {x}; jeśli T nie jest na liście transakcji zatwierdzonych, przypisz w PCh danej x uprzednią wartość x względem T i przyjmij UNDONE := UNDONE {x}. 2. Dla każdej transakcji T z listy transakcji zatwierdzonych, usuń T z listy transakcji aktywnych. 3. Powiadom planistę o zakończeniu operacji Restart. 20