1 Transakcyjne odtwarzanie bazy danych po awarii

2 Cel odtwarzania Podstawowym celem mechanizmów transakcyjnego odtwarzania bazy danych po awarii jest odtworzenie spójnego stanu bazy danych Definicja odtwarzania – wiąże się bezpośrednio z problemem efektywnej implementacji własności atomowości i trwałości transakcji (własności ACID)

3 Wprowadzenie Baza danych może okazać się w stanie niespójnym w przypadku: –Awarii transakcji (abort) –Awarii systemu bazy danych –Awarii sprzętu (dane w pamięci zewnętrznej uległy zniszczeniu) System odtwarzania bazy danych ma za zadanie zagwarantowanie, że baza danych zawiera aktualizacje (zapisy) tylko i wyłącznie zaakceptowanych transakcji –Gwarantuje to atomowość i trwałość transakcji, mimo awarii

4 Założenia Jeżeli system wykorzystuje algorytm blokowania 2PL to zakładamy, że blokady dla zapisu są zdejmowane po akceptacji transakcji (po operacji commit). To gwarantuje: –Odtwarzalność (RC) –Unikanie kaskadowych wycofań (efekt domina) (ACA) –Ścisłość (ST) Przetwarzanie na poziomie stron (page-level processing) –Baza danych jest zbiorem stron –Blokady na poziomie stron –Transakcja czyta i zapisuje całą stronę –Później osłabimy przyjęte założenia – przetwarzanie na poziomie rekordów

5 Modele awarii Miękki model awarii – awaria nie niszczy danych w pamięci zewnętrznej Twardy model awarii - awaria niszczy dane w pamięci zewnętrznej „Niedeterministyczny” charakter błędów prowadzących do wystąpienia awarii systemu – błędy w oprogramowaniu systemowym (tzw. „Heisenbugs”) Podejście „Fail-stop crash”: –Wyłącz serwer –Odtwórz spójny stan bazy danych –Restartuj system

6 Efektywność odtwarzania Konieczność minimalizacji czasu odtwarzania po awarii - w trakcie odtwarzania serwer i dane są niedostępne Miara efektywności odtwarzania – dostępność systemu, tj. prawdopodobieństwo, że próbkując losowo użytkownik znajduje system gotowy do realizacji żądań dostępu MTTF MTTF + MTTR MTTF – średni czas do awarii MTTR – średni czas odtworzenia po awarii

7 Dostępność Przykład: raz w miesiąca ma miejsce awaria serwera, odtworzenie stanu serwera zajmuje 2 godz., czas niedostępności serwera – 26 godz./rocznie dostępność = (720/722) = 99,7 % Przykład: awaria serwera ma miejsce raz na 48 godz., odtworzenie stanu serwera zajmuje 30 sek. dostępność = 99,98 % Wniosek: efektywność odtwarzania ma kluczowe znaczenie z punktu widzenia dostępności systemu Inna miara efektywności odtwarzania: ilość zasobów niezbędnych, podczas normalnego działania systemu, do tego, aby w razie awarii poprawnie odtworzyć stan systemu.

8 Architektura modułu odtwarzania (1) Elementy składowe modułu odtwarzania : –Baza danych –Bufor bazy danych –Plik logu –Bufor logu Zawartość wymienionych składowych modułu odtwarzania całkowicie określa stan systemu Plik logu jako plik sekwencyjny typu „append-only”, Alternatywa – plik logu o dostępie swobodnym przechowujący zbiór wersji stron bazy danych (ang. shadow database)

9 Architektura modułu odtwarzania (2) database page Database cache Log entry Log buffer read write begin commit rollback write database page fetch flush Stable database Log entry force Stable log Database server

10 Operacje (1) Operacje transakcji: –Begin(T) –Commit(T) –Rollback(T) –Save(T) –Restore (T,s) Operacje na stronach bazy danych: –read[pageno, T] –write[pageno, T] –full-write[pageno, T] (blind-write, real action) –exec[op, obj, T]

11 Operacje (2) Operacje na buforze danych: –Fetch [pageno] : pobierz stronę o identyfikatorze pageno z bazy danych do bufora danych, –Flush [pageno] : zapisz stronę o identyfikatorze pageno z bufora danych do bazy danych (strona jest brudna i niezablokowana (unpinned)) –Pin [pageno]: zablokuj stronę pageno (nie można jest zapisać na dysk i nie można jej nadpisać (non-flushable i non-replaceable) –Unpin [pageno] : odblokuj stronę pageno (flushable i replaceable) –Deallocate [pageno]: można wykorzystać slot strony pageno (nawet jeżeli strona pageno jest brudna) Operacje na pliku logu: –Force () : zapisz rekordy logu z bufora logu do pliku logu

12 Bufor danych (1) Bufor: zmniejszenie liczby operacji I/O Tablica bufora (lookaside table) Strategia LRU (ang. least recently used) – usuwamy z bufora stronę najmniej używaną w ostatnim czasie Idea: Nie chcemy zapisywać strony na dysk za każdym razem, gdy strona jest aktualizowana przez transakcję. Wniosek: Często aktualizowane strony pozostają w buforze aż: –zostaną usunięte w wyniku zastosowania strategii LRU –zostaną zapisane na dysku po zadanym czasie

13 Bufor danych (2) Mówimy, że strona w buforze jest „brudna”, jeżeli zastała uaktualniona przez transakcję od czasu jest ostatniego zapisu na dysk. „Brudne” strony mogą pozostawać w buforze jeszcze długo po tym, jak uaktualniające je transakcje zostały zaakceptowane. Problem: Wystąpiła awaria. Jeżeli aktualizowane strony nie były zapisywane na dysk, to tracimy informacje o dokonanych aktualizacjach. W momencie aktualizacji, system zapisuje ten fakt w postaci tzw. rekordu logu (ang. log entry) w buforze logu. Okresowo, bufor logu jest zapisywany na dysk do pliku logu (ang. log file).

14 Bufor danych (3) Bufor: podzielony na tzw. sloty o rozmiarze strony Bit „dirty” określa czy strona była aktualizowana od czasu ostatniego zapisu na dysk Licznik „pin” określa aktualną liczbę operacji Pin wykonywanych na stronie (bez Unpin) StronaDirty bitCache addressPin countLSN P21889881 P550553432 P231121210

15 Log (1) Plik sekwencyjny opisujący aktualizacje w bazie danych: –Adres aktualizowanej strony –Id transakcji –Before image i after image aktualizowanej strony Modyfikacja bufora danych generuje rekord logu Rekordy logu dla operacji commit i abort W starszych systemach before-images i after-images przechowywane w rozłącznych plikach logu Jeżeli operacja op1 będąca w konflikcie z operacja op2 jest wykonywana przed op2, to rekord logu operacji op1 musi poprzedzać rekord logu operacji op1

16 Log (2) Aktualizacja rekordu na stronie P jest wykonywana następująco: –Fetch (P) –Pin(P) –Write lock(P) –Write latch(P) –Update (P) –Generacja rekord logu operacji update P –Unlatch (P) –Unpin(P)

17 Format logu (1) Rozważmy następującą realizację transakcji: r 1 = T1:r(a, 50) T1:w(a, 20) T2:r(c, 100) T2:w(c,50) T2:c T1:r(b, 50) T1:w(b, 80) T1:c......... Załóżmy, że w bazie danych zdefiniowano ograniczenie integralnościowe postaci: a + b = 100 i załóżmy, że zapis na dysk jest realizowany zgodnie ze strategią LRU Wystąpiła awaria – załóżmy, że aktualne wartości danych na dysku są następujące: a = 50, b = 80, c = 100 Dane niespójne

18 Format logu (2) Załóżmy, że strategia zapisu jest następująca: strona jest zapisywana na dysk natychmiast po jej aktualizacji w buforze Realizacja jak wyżej - awaria wystąpiła po wykonaniu T2:c Wartości danych na dysku są następujące: a = 20, b = 80, c = 50 – dane niespójne Wniosek: strategia LRU jak i strategia zapisu natychmiastowego aktualizacji na dysk może prowadzić do niespójności bazy danych

19 Stan spójny bazy danych Celem odtwarzania jest zapewnienie własności atomowości i trwałości transakcji Procedura odtwarzania bazy danych (ang. database recovery) po awarii, korzystając z informacji zawartej w rekordach logu i stanu bazy danych przechowywanego na dysku, przeprowadza bazę danych do stanu, który odzwierciedla wszystkie lub żadną operacje aktualizacji transakcji aktywnych w momencie wystąpienia awarii System transakcyjny, inicjowany ponownie po awarii, nie pamięta intencji logiki transakcji, które były aktywne w momencie awarii - stąd, system musi wycofać wszystkie zmiany w bazie danych wprowadzone przez aktywne transakcje

20 Stan spójny bazy danych (2) Dla realizacji (awaria w momencie realizacji operacji T1:c): r 1 = T1:r(a, 50) T1:w(a, 20) T2:r(c, 100) T2:w(c,50) T2:c T1:r(b, 50) T1:w(b, 80) T1:c......... transakcja T2 zaakceptowana; T1 wycofana. Stąd, stan spójny po awarii: a = 50, b = 50, c = 50 Rekordy logu – rekordy logu są generowane i zapisywane do bufora logu dla każdej operacji aktualizacji obiektu bazy danych, operacji inicjacji zakończenia transakcji

21 Rekordy logu (1) Format rekordu pliku logu: –(S, i): rekord inicjacji transakcji Ti; –(W, i, a, x, y): rekord zapisu danej a przez transakcje Ti, poprzednia wartość danej x (before image), nowa wartość danej y (after image); –(C, i): rekord akceptacji transakcji Ti; Realizacja r 1 = T1:r(a, 50) T1:w(a, 20) T2:r(c, 100) T2:w(c,50) T2:c T1:r(b, 50) T1:w(b, 80) T1:c.........

22 Rekordy logu (2) Rekordy logu wygenerowane przez moduł odtwarzania dla przedstawionej realizacji: OperacjaRekord logu T1:r(a, 50)(S, 1) - rekord logu początku transakcji T1, nie wpisuje się rekordów logu dla operacji odczytu, w tym przypadku jest to operacja początku transakcji T1:w(a, 20)(W, 1, a, 50, 20) – rekord logu dla operacji aktualizacji atrybutu a. Wartość a=50 before image, a=20 – after image

23 Rekordy logu (3) 3.T2:r(c, 100)(S, 2) - rekord logu początku transakcji T2 4.T2:w(c, 50)(W, 2, c, 100, 50) –rekord logu dla operacji aktualizacji atrybutu c. Wartość c=100 (before image), c=50 – after image 5.T2:c(C, 2) – rekord akceptacji transakcji T2 – (zapis bufora logu na dysk) 6.T1:r(b, 50)

24 Rekordy logu (4) 7.T1:w(b, 80)(W, 1, b, 50, 80) – rekord logu dla operacji aktualizacji atrybutu b. Wartość b=50 (before image), b=80 – after image 8.T1:c(C, 2) – rekord akceptacji transakcji T1 – (zapis bufora logu na dysk) Bufor logu jest zapisywany do pliku logu w dwóch sytuacjach: –w momencie akceptacji transakcji –w momencie przepełnienia bufora (double-buffered disk write)

25 Logging Logging – najpopularniejszy mechanizm odtwarzania bazy danych po awarii wykorzystujący plik logu Recovery manager (zarządca odtwarzania) wykorzystuje mechanizm loggingu w trzech podstawowych przypadkach: –Przy akceptacji transakcji (commit operation) –Przy wycofaniu transakcji (abort operation) –Przy odtwarzaniu serwera bazy danych po awarii (restart systemu)

26 Commit Operacja akceptacji transakcji Ti generuje rekord logu akceptacji (C, Ti) i zapis (flush) bufora logu do pliku logu – reguła force-at-commit Operacja zapisu bufora logu do pliku logu i operacja akceptacji transakcji tworzą akcję atomową Group commit optimization – mechanizm optymalizacji zapisu bufora logu do pliku logu polegający na opóźnieniu zapisu bufora logu tak aby zapisywać większe jednostki danych

27 Abort (1) Implementacja procedury Abort(T) polega na przeglądaniu pliku logu i wykonywaniu operacji zapisu do bazy danych wartości before-images (sekwencja operacji UNDO) W celu przyśpieszenia wykonywania procedury Abort(T) oraz odtwarzania bazy danych po awarii wszystkie rekordy pliku logu posiadają wskaźniki na poprzednie rekordy pliku logu i poprzednie rekordy logu tej samej transakcji Dla każdej transakcji system przechowuje kotwicę (anchor) rekordów logu transakcji

28 trid, max_lsn, min_lsn... lsn prev_lsn resource_mgr trid tran_prev_lsn body A Files B Files Log Table Archive Log Anchor Abort (2)

29 Odtwarzanie (1) Procedura odtwarzania po awarii jest wykonywana w dwóch fazach: ROLLBACK i ROLL FORWARD W fazie ROLLBACK, rekordy pliku logu są odczytywane w odwrotnej kolejności (od końca). W fazie tej procedura odtwarzania wykonuje operacje UNDO wszystkich operacji aktualizacji transakcji, które nie zostały zaakceptowane. W fazie ROLL FORWARD, rekordy pliku logu są odczytywane w oryginalnej kolejności (od początku). W fazie tej procedura odtwarzania wykonuje operacje REDO wszystkich operacji aktualizacji transakcji, które zostały zaakceptowane

30 Faza Rollback Rekord loguRollback 5.(C, 2)wstaw T2 do listy transakcji zaakceptowanych 4.(W,2,c,100,50) T2 na liście transakcji zaakceptowanych – nie rób nic 3.(S, 2) T2 na liście transakcji zaakceptowanych – nie rób nic 2.(W,1,a,50,20) T1 – aktywna, wykonaj UNDO operacji aktualizacji – dana a przyjmuje wartość 50 1.(S, 1)Transakcja T1 pasywna. Zakończ fazę ROLLBACK

31 Faza Roll Forward Rekord loguRollback 1.(S, 1)brak akcji (T1 aktywna) 2.(w,1,a,50,20)brak akcji (T1 aktywna) 3.(S, 2)brak akcji 4.(w,2,c,100,50)Transakcja T2 na liście transakcji zaakceptowanych. Wykonaj REDO operacji aktualizacji – dana c przyjmuje wartość 50 5.(C,2)brak akcji Zakończono przeglądanie pliku logu – zakończ procedurę odtwarzania

32 Poprawność odtwarzania (1) Czy informacje zapisane w buforze logu są wystarczające do odtworzenia spójnego stanu bazy danych? Mogą wystąpić dwa problemy: –może się okazać, że zapisaliśmy na dysk strony uaktualnione przez nie zaakceptowane transakcje (UNDO) –może się okazać, że nie zapisaliśmy na dysk stron uaktualnionych przez zaakceptowane transakcje (REDO)

33 Poprawność odtwarzania (2) Realizacja (scenariusz nr 1) r 1 = T1:r(a, 50) T1:w(a, 20) T2:r(c, 100) T2:w(c,50) T2:c T1:r(b, 50) T1:w(b, 80) T1:c......... Załóżmy, że wystąpiła awaria systemu po wykonaniu operacji T1:w(b, 80) ((W, 1, b, 50, 80) ostatni zapis do bufora logu). Bufor logu został zapisany na dysk w momencie akceptacji transakcji T2 Transakcja T2 została zaakceptowana; transakcja T1 nie. Po ponownej inicjacji systemu po awarii, operacje aktualizacji wykonane przez transakcję T1 muszą zostać wycofane! (brak danych umożliwiających wycofanie)

34 Poprawność odtwarzania (3) W jaki sposób możemy zapewnić, że wszystkie rekordy logu konieczne do zapewnienia poprawności procedury odtwarzania zostaną zapisane na dysku? Założenia dodatkowe: –zapis na dysk jest realizowany w sposób atomowy - „read after write” – podstawowe założenie –akceptacja transakcji + zapis bufora logu - akcja atomowa (force-at-commit rule) Poprawność procedur ROLLBACK i ROLL FORWARD

35 Poprawność odtwarzania (4) ROLL FORWARD - operacje REDO Transakcja nie jest zaakceptowana jeżeli nie zostanie zapisany bufor logu. Jeżeli bufor logu zostanie zapisany, to wszystkie rekordy logu, zapisywane do bufora logu, znajdą się na dysku co gwarantuje poprawność realizacji procedury ROLL FORWARD ROLLBACK - operacje UNDO Musimy zagwarantować, że wszystkie aktualizacje wprowadzone przez nie zaakceptowane transakcje zostaną cofnięte - ale strony zmodyfikowane przez nie zaakceptowane transakcje mogą być zapisane na dysk (np. przez LRU).

36 Poprawność odtwarzania (5) Czy może to stwarzać problemy przy odtwarzaniu? TAK. Rozwiązania problemu: Rozwiązanie A: zawiesić działanie procedury LRU –Wszystkie brudne strony pozostają w buforze do momentu akceptacji transakcji - procedura UNDO nie jest wówczas potrzebna. Rozwiązanie B: zmodyfikować LRU –Rozwiązaniem jest technika „write ahead log” rule (WAL), i –Sekwencyjne numery logu LSN (ang. Log sequence numbers)

37 WAL (1) System bazy danych utrzymuje licznik, który generuje rosnącą sekwencję LSN LSN jet liczbą całkowitą, przypisywaną do każdego rekordu logu zapisywanego do bufora logu LSN_BUFFMIN - SBD przechowuje również najmniejszą wartość LSN strony, od czasu ostatniego zapisu bufora na dysk. LSN_PGMAX - dla każdej strony w buforze danych, system pamięta wartość ostatniej LSN operacji, która aktualizowała daną na tej stronie.

38 WAL (2) Reguła modyfikacji LRU: dana strona w buforze może zostać zapisana na dysk (zgodnie z LRU), wtedy i tylko wtedy gdy jej LSN_PGMAX < LSN_BUFFMIN Reguła ta gwarantuje, że dana strona nie zostanie zapisana na dysku, jeżeli wcześniej nie zostanie zapisany na dysku odpowiedni rekord logu

39 Punkty kontrolne (1) Do jakiego stanu należy się cofnąć wykonując procedurę ROLLBACK? –do momentu inicjacji (startup) systemu –do stanu określonego przez użytkownika (administratora) Problem: –procedura ROLLBACK - większość transakcji to krótkie transakcje aktualizacji - stosunkowo efektywna –procedura ROLL FORWARD - konieczność przetworzenia całego pliku logu - niska efektywność

40 Punkty kontrolne (2) Trzy podejścia do tworzenia punktów kontrolnych w systemie bazy danych: –punkt kontrolny akceptacyjnie spójny (ang. commit- consistent checkpointing) –punkt kontrolny spójny z pamięcią podręczną (ang. cache-consistent checkpointing) –punkt kontrolny rozmyty (ang. fuzzy checkpointing)

41 Punkt kontrolny akceptacyjnie spójny (1) Procedura zakładania punktu kontrolnego akceptacyjnie spójnego przebiega następująco: 1.No new transactions can start until the checkpoint is complete. 2.Database operation processing continues until all existing transactions commit, and all their log entries are written out to disk. 3.The current log buffer is written out to the log file, and after this the system ensures that all dirty pages in buffer have been written out to disk. 4.When steps 1-3 have been performed, the system writes a special log entry, (CKPT), to disk, and the checkpoint is complete.

42 Punkt kontrolny akceptacyjnie spójny (2) Procedura zakładania punktu kontrolnego jest podobna do procedury zamykania systemu (shutdown of the system), natomiast stan końcowy systemu po założeniu punktu kontrolnego jest równoważny stanowi, który byłby stanem bazy danych w momencie startu systemu Przykład: Rozmiar bufora danych - 200 MB, rozmiar strony - 4KB 50 000 stron – zakładamy, że połowa z nich jest brudna, mamy więc 25 000 brudnych stron, które muszą być zapisane na dysk Zakładając, że zapis każdej strony wymaga 25 ms, łączny czas konieczny do zapisania brudnych stron na dysk to 625 sekund Łączny czas potrzebny na założenie punktu kontrolnego jest znacznie dłuższy!!!

43 Punkt kontrolny spójny z pamięcią podręczną (1) W celu uniknięcia problemów związanych z oczekiwaniem na zakończenie wykonywania aktywnych transakcji i zablokowaniem procedury zakładania punktu kontrolnego, definiuje się inny typ punktu kontrolnego – punkt kontrolny spójny z pamięcią podręczną W trakcie zakładania punktu kontrolnego transakcje pozostają aktywne (ich wykonanie zostaje zawieszone) – wymaga się jedynie, aby wszystkie brudne strony w buforze danych i bufor logu zostały zapisane na dysk

44 Punkt kontrolny spójny z pamięcią podręczną (2) Bufor danych w pamięci jest często nazywany pamięcią podręczna dysku  stąd nazwa punktu kontrolnego W trakcie zakładania punktu kontrolnego wykonywanie aktywnych transakcji zostaje zawieszone - nie mogą wykonywać żadnych operacji I/O

45 Punkt kontrolny spójny z pamięcią podręczną (3) Procedura zakładania punktu kontrolnego spójnego z pamięcią podręczną przebiega następująco: 1.No new transactions can start until the checkpoint is complete. 2.Active transactions are not permitted to start any new operations. 3.The current log buffer is written out to the log file, and after this the system ensures that all dirty pages in buffer have been written out to disk. 4.When steps 1-3 have been performed, the system writes a special log entry, (CKPT, List), to disk, and the checkpoint is complete. The List contains a list of active transactions at the time the checkpoint is created.

46 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (1) Dana jest następująca realizacja transakcji: r: T1:r(A, 10) T1:w(A, 1) T1:c T2:r(A, 1) T3:r(B, 2) T2:w(A, 3) T4:r(C, 5) CKPT T3:w(B, 4) T3:cT4:r(B, 4) T4:w(C, 6) T4:c crash

47 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (2) Sekwencja rekordów logu wygenerowana przez realizację r ma następującą postać: (S, 1) (W, 1, A, 10, 1) (C, 1) (S, 2) (S, 3) (W, 2, A, 1, 3) (S, 4) (CKPT, (List = T2, T3, T4)) (W, 3, B, 2, 4) (C, 3) (W, 4, C, 5, 6) (C, 4) crash W chwili tworzenia punktu kontrolnego następujące wartości danych zostały zapisane na dysku: A = 3, B = 2, C = 5

48 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (3) Załóżmy, że żadna dana zaktualizowana przez operację zapisu nie została zapisana na dysku przed wystąpieniem awarii – wartości wszystkich danych w bazie danych pozostały niezmienione same Punkt kontrolny Crash T1 T2 T3 T4

49 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (4) ROLLBACK procedure 1. (C, 3)wstaw T3 na listę transakcji zaakceptowanych (T3 na liście transakcji aktywnych punktu kontrolnego (pk)) 2. (W, 3, B, 2, 4)transakcja zaakceptowana, czekaj na ROLL FORWARD 3. (CKPT, (List = T2, T3, T4)) aktywne transakcje T2, T4 niezaakceptowane 4. (S, 4)usuń T4 z listy transakcji aktywnych

50 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (5) 5. (W, 2, A, 1, 3)T2 niezaakceptowana, wykonaj UNDO; A = 1 6. (S, 3)transakcja zaakceptowana, usuń T3 z listy transakcji aktywnych 7. (S, 2)usuń T2 z listy transakcji aktywnych. Lista transakcji aktywnych pusta - Zakończ ROLLBACK

51 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (6) Kiedy procedura ROLLBACK napotyka na rekord logu CKPT w pliku logu, system zaznacza transakcje które były aktywne w momencie tworzenia punktu kontrolnego Usuwamy z listy te transakcje z listy transakcji aktywnych, które zostały zaakceptowane przed wystąpieniem awarii i otrzymujemy listę transakcji, których aktualizacje muszą zostać wycofane UNDO w procedurze ROLLBACK Kontynuujemy procedurę ROLLBACK do chwili zakończenia wszystkich operacji UNDO wszystkich transakcji aktywnych z listy

52 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (7) ROLL FORWARD procedure 8. (CKPT, (List = T2, T3, T4)) pomiń rekordy pliku logu i przejdź do rekordu logu punktu kontrolnego. Jedyna zaakceptowana transakcja to transakcja T3 9. (W, 3, B, 2, 4)ROLL FORWARD; B = 4 10. (C, 3)Brak akcji. Ostatni rekord pliku logu, procedura ROLL FORWARD zakończona

53 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (8) Celem procedury ROLL FORWARD jest wykonanie sekwencji operacji REDO dla wszystkich aktualizacji, wykonanych przez transakcje zaakceptowane, które mogły pozostać w buforze danych i nie zostały zapisane na dysku. Możemy pominąć rekordy pliku logu i przejść bezpośrednio do rekordu logu punktu kontrolnego w procedurze ROLL FORWARD ponieważ wiemy, na podstawie konstrukcji punktu kontrolnego, że wszystkie wcześniejsze aktualizacje na pewno zostały zapisane na dysku

54 Procedura odtwarzania z wykorzystaniem punktu kontrolnego spójnego z pamięcią podręczną (9) Przypomnijmy, że dane na dysku w momencie wystąpienia awarii posiadały następujące wartości: A = 3, B = 2, C = 5 Po zakończeniu odtwarzania, otrzymujemy: A = 1(krok 5) B = 4(krok 9) C = 5 Wynika to z faktu, że transakcje T2 i T4 nie zostały zaakceptowane przed wystąpieniem awarii, natomiast T1 i T3 zostały zaakceptowane

55 Rozmyty punkt kontrolny (1) Celem procedury zakładania punktu kontrolnego rozmytego jest redukcja do minimum czasu niezbędnego do założenia punktu kontrolnego. Ponieważ czas niezbędny do założenia punktu kontrolnego jest zasadniczo określony przez czas zapisu brudnych stron z bufora danych na dysk, podejście oparte o rozmyty punkt kontrolny minimalizuje koszt zapisu brudnych stron na dysku Procedura odtwarzania bazy danych po awarii wykorzystuje dwa kolejne ostatnie zdarzenia założenia punktu kontrolnego (rekordy CKPT) zapisane w pliku logu

56 Rozmyty punkt kontrolny (2) Idea jest następująca. W momencie zakładania punktu kontrolnego CKPT N, system zaznacza wszystkie brudne strony w buforze, które zostały „zabrudzone” od momentu utworzenia punktu kontrolnego CKPT N-1. Zakłada się, że strony te zostaną zapisane na dysk do momentu utworzenia kolejnego punktu kontrolnego - CKPT N+1. Innymi słowy, zakłada się, że zarządca bufora zapisze większość brudnych stron na dysk przed utworzeniem kolejnego punktu kontrolnego CKPT N+1 wskutek normalnego działania algorytmu LRU

57 Rozmyty punkt kontrolny (3) Pozostałe brudne strony, które nie zostały zapisane na dysku przed utworzeniem punktu kontrolnego CKPT N+1 zostaną zapisane w momencie tworzenia tego punktu Podsumowując, wszystkie brudne strony zaznaczone w momencie tworzenia punktu kontrolnego CKPT N-1 zostaną zapisane na dysku przed lub w momencie tworzenia punktu kontrolnego CKPT N.

58 Rozmyty punkt kontrolny (4) Procedura zakładania rozmytego punktu kontrolnego przebiega następująco: 1.Prior to checkpoint start, the remaining pages dirty as of the previous checkpoint are forced out to disk. 2.No new transactions can start until the checkpoint is complete. 3.Active transactions are not permitted to start any new operations. 4.The current log buffer is written out to the log file with an appended log entry, (CKPT N, List), as in the cache-consistent checkpoint procedure. 5.The set of pages in buffer that are dirty since the last checkpoint log, CKPT N-1, is noted. Special flags on the buffer directory may accomplish this. The checkpoint is now completed.

59 Rozmyty punkt kontrolny (5) Procedura odtwarzania bazy danych z wykorzystaniem rozmytych punktów kontrolnych różni się od procedury odtwarzania bazy danych z wykorzystaniem punktów spójnych z pamięcią podręczną tylko tym, że procedura ROLL FORWARD rozpoczyna się od przedostatniego rekordu punktu kontrolnego w pliku logu (tj. rozpoczyna się od rekordu logu CKPT N-1, jeżeli ostatnim punktem kontrolnym założonym w pliku logu był punkt kontrolny CKPT N ).

60 Unikanie sekwencji UNDO Nie zapisuj stron zawierających aktualizacje niezaakceptowanych transakcji do bazy danych Nie potrzebujemy sekwencji UNDO do odtworzenia poprawnego stanu bazy danych Zarządca bufora wykorzystuje strategię steal policy, jeżeli strony mogą być zapisywane na dysk nawet jeżeli transakcje modyfikujące te strony nie zostały jeszcze zaakceptowane Zarządca bufora wykorzystuje strategię no-steal policy, jeżeli wszystkie brudne strony pozostają w buforze danych aż do momentu akceptacji lub wycofania transakcji

61 Unikanie sekwencji REDO (1) Zapisuj stron zawierające aktualizacje zaakceptowanych transakcji do bazy danych w momencie akceptacji transakcji (w fazie prepare_to_commit) Nie potrzebujemy sekwencji REDO do odtworzenia poprawnego stanu bazy danych Kto i kiedy decyduje o zapisie stron zmodyfikowanych przez zaakceptowane transakcje do bazy danych? Decyzje zawsze podejmuje zarządca bufora

62 Unikanie sekwencji REDO (2) Dwa podejścia do problemu zapisu stron zmodyfikowanych przez zaakceptowane transakcje do bazy danych : Force policy. W pierwszej fazie akceptacji transakcji (prepare_to_commi) zarządca bufora lokalizuje strony zmodyfikowane przez zaakceptowana transakcję i zapisuje je na dysk No-force policy.Strona, niezależnie od tego czy jest zmodyfikowana przez zatwierdzoną czy też aktywną transakcję pozostaje w buforze tak długo, aż jej slot nie jest potrzebny dla nowej strony – w momencie wymiany stron jest zapisywana na dysk

63 Unikanie sekwencji UNDO i REDO Przyjmując strategie No-steal/Force teoretycznie można uniknąć wykonywania sekwencji UNDO i REDO Jest to nieefektywne i może prowadzić do samozakleszczenia transakcji aktywnych (brak miejsca w buforze dla nowych stron niezbędnych do zakończenia transakcji aktywnych) Kombinacja strategii No-steal/Force nie działa dla blokowania i przetwarzania na poziomie rekordów (rekord logging i rekord blocking) Dlaczego? Podstawową kombinacją strategii zarządzania buforem danych jest kombinacja Steal/No-force