Systemy zarządzania bazami danych

Systemy zarządzania bazami danych

8. Dzienniki i odtwarzanie

Integralność/poprawność danych

• Chcemy by dane zawsze były

„dokładne” lub inaczej „poprawne”

EMP Nazwisko Miller

Tusk Jaro

Wiek 52 3421

1

Więzy integralności

• Predykaty, które muszą być spełnione przez dane

• Przykłady

- x jest kluczem relacji R

- zależność funkcyjna x  y zachodzi w R - dom(x) = { Czerwony, Żółty, Zielony }

 jest poprawnym indeksem atrybutu x relacji R - żaden pracownik nie powinien zarabiać powyżej

dwóch średnich pensji (socjalizm?)

Integralność

• Stan integralny

= stan, w którym są spełnione wszystkie więzy integralności

• Integralna baza danych

= baza danych w stanie integralnym

Takie więzy nie załatwiają wszystkiego

• Przykład 1: więzy transakcyjne:

– Gdy zmienia się Zarobek,

nowy Zarobek > stary Zarobek – Gdy usuwane jest Konto,

saldo = 0

Możliwa emulacja

• Wiezy transakcyjne można emulować zwykłymi (przy pewnych zmianach

schematu):

Konto

Więzy: usunięte?  saldo = 0

Nr …. saldo usunięte?

• Przykład 2: Baza danych ma

odzwierciedlać stan świata rzeczywistego

Baza

danych Rzeczywistość

Wiezy integralności nie dają spójności

Tylko integralność jest jednak dostępna...

• Obserwacja: Baza danych musi mieć możliwość bycia nieintegralną

• Przykład więzów : a¹ + a² +…. aⁿ = S

Zaksięguj 100zł na a²: a²  a² + 100 S  S + 100

– Suma aktywów = Sum pasywów

a²

S

..

50 ..

1000

..

150 ..

1000

..

150 ..

1100

• Przykład więzów : a¹ + a² +…. aⁿ = S

Zaksięguj 100zł na a²: a²  a² + 100 S  S + 100

Transakcja

• Ciąg operacji zachowujących integralność

• Założenie: jeśli transakcja T zaczyna

działanie w stanie integralnym i działa w izolacji, to pozostawia bazę w stanie

Integralna

baza danych Integralna

baza danych’

Transakcja

Poprawność

• Jeśli zakonczą się wszystkie transakcje, to baza danych będzie integralna

• Każda transakcja widzi integralny stan bazy danych

Jak może dojść do złamania więzów?

• Błąd w transakcji

• Błąd w SZBD (oprogramowanie jak każde)

• Awaria sprzętu

n.p., awaria sprzetu powoduje zmianę sald kont

• Błędne nałożenie się transakcji n.p: T1: daje 10% podwyżki programistom

T2: zmienia programistów w analityków systemowych

Abstrahujemy od:

• Pisania poprawnych transakcji

• Pisania poprawnych SZBD

• Sprawdzania więzów spojności i czyszczenia danych

–Metody z tego wykładu nie są od nich zależne

Model awarii

Zdarzenia Pożądane

Niepożądane Spodziewane

Niespodziewane procesor

pamięć dysk

CPU

M D

Zdarzenie pożądane: czytaj podręcznik produktu….

Zdarzenia niepożądane spodziewane:

Awaria systemu:

- utrata zawartości pamięci - zawieszenie procesora

Zdarzenia niepożądane niespodziewane:

wszystko inne!

I to by było na tyle!!

• Utrata danych na dysku

• Utrata pamięci bez zawieszenia procesora

• Supernowa akurat gdzieś blisko procesora

Niepożądane niespodziewane

Czy ten model ma sens?

Rozwiązanie: Kontrole niskopoziomowe i nadmiarowość w celu zwiększenia

prawdopodobieństwa adekwatności modelu

Np., Powiel dyskowe składowisko danych Parzystość pamięci, sumy kontrolne Kontrole na procesorze

Hierarchia pamięci

Pamięć Dysk

x x

Podstawowe operacje

• Input (x): blok ze zmienną x  pamięć

• Output (x): blok ze zmienną x  dysk

• Read (x,t): zrób input(x) jeśli trzeba t  wartość x w bloku

• Write (x,t): zrób input(x) jeśli trzeba wartość x w bloku  t

t zmienna lokalna, x obiekt bazy danych

Niedokończona transakcja

Przykład Więzy: A=B

T¹: A  A  2 B  B  2

T¹: Read (A,t); t  t2 Write (A,t);

Read (B,t); t  t2 Write (B,t);

Output (A);

Output (B);

A: 8

B: 8 A: 8

B: 8

pamięć dysk

16

16 16

awaria!

Atomowość

• Wykonaj wszystkie akcje transakcji albo żadną

• Rozwiązanie: dziennik wycofań + zapis natychmiastowy

• Specjalne podziękowania dla Jasia i Małgosi

– Jeszcze zanim spotkali Babę Jagę

T¹: Read (A,t); t  t2 A=B Write (A,t);

Read (B,t); t  t2 Write (B,t);

Output (A);

Output (B);

A:8B:8 A:8

B:8

Dziennik wycofań, zapis natychmiastowy

1616

<T1, start>

<T1, A, 8>

<T1, commit>

16 <T1, B, 8>

16

Pewna komplikacja

• Dziennik najpierw powstaje w pamięci

• Nie idzie na dysk przy każdej akcji

pamięć

BD

Dziennik A: 8 16

B: 8 16 Log:

<T1,start>

<T1, A, 8>

<T1, B, 8>

A: 8 B: 8 16

Zły stan

# 1

Pewna komplikacja

• Dziennik najpierw powstaje w pamięci

• Nie idzie na dysk przy każdej akcji

pamięć

BD

Dziennik A: 8 16

B: 8 16 Log:

<T1,start>

<T1, A, 8>

<T1, B, 8>

<T1, commit>

A: 8 B: 8 16

Zły stan

# 2

<T1, B, 8>

<T1, commit>

...

Reguły dziennika wycofań

(1) Dla każdej akcji wygeneruj wpis dziennika (zawierający starą wartość)

(2) Zanim zmieniony x znajdzie się na dysku,

dotyczący go wpis dziennika musi trafić na dysk.

(zapis wyprzedzający – WAL write ahead logging)

(3) Zanim do dziennika na dysku trafi wpis commit, wszystkie zmiany w danych muszą być zapisane

Odtwarzanie z dziennika wycofań

Dla każdej Ti mającej <Ti, start> w dzienniku:

- Jeśli <Ti,commit> lub <Ti,abort> są w dzienniku, nic nie rób

- W p.p. dla każdego <Ti, X, v> w dzienniku:

write (X, v) output (X )

zapisz <Ti, abort> do dziennika

Czy to

Odtwarzanie w tył dziennika wycofań

(1) Niech S = zbiór transakcji mających w

dzienniku wpis <Ti, start> ale nie mających wpisu <Ti, commit> ani <Ti, abort>

(2) Dla każdego wpisu dziennika <Ti, X, v>,

w odwrotnym porzadku chronologicznym rób:

- jeśli Ti  S - write (X, v) - output (X)

(3) Dla każdej transakcji Ti  ^{S rób}

Awaria w czasie odtwarzania?

• Nie ma problemu

• Tu: wycofanie jest idempotentne f(f(x)) = f(x)

• Nie zawsze tak musi być

Dziennik powtorzeń, zapis opóźniony

T^1: Read(A,t); t t2; write (A,t);

Read(B,t); t t2; write (B,t);

Output(A); Output(B)

A: 8

B: 8 A: 8

B: 8

Baza danych

1616

<T1, start>

<T1, A, 16>

<T1, B, 16>

<T1, commit>

<T1, end>

output

1616

Reguły dziennika powtórzeń

(1) Dla każdej akcji wygeneruj wpis dziennika (zawierający nową wartość)

(2) Zanim zmieniony x znajdzie się na dysku, wszystkie wpisy dotyczące transakcji, która zmodyfikowała x muszą trafić na dysk.

(3) Przy commit, zrzuć dziennik na dysk (flush) (4) Po wykonaniu wszystkich zmian w bazie

danych, dodaj do dzienika wpis END

• Dla każdej Ti mającej w dzienniku <Ti, commit>

– Dla każdego wpisu dziennika <Ti, X, v>

Write(X, v) Output(X)

Odtwarzanie z dziennika powtórzeń

Czy to jest poprawne??

(1) Niech S = zbiór transakcji mający w

dzienniku <Ti, commit> ale nie <Ti, end>

(2) Dla każdego wpisu <Ti, X, v> W porzadku chronologiczny, rób:

- jeśli Ti  S, Write(X, v) Output(X)

(3) Dla każdej Ti  S, wpisz do dziennika

<Ti, end>

Odtwarzanie w przód z d. powtórzeń

Łączenie wpisów <Ti, end>

• Chcemy opóźnić zapisy gorących obiektów

Np. X to stan kasy:

T1: ... update X...

T2: ... update X...

T3: ... update X...

T4: ... update X...

Akcje:

write X output X write X output X write X output X write X output X

Punkt kontrolny

Co pewien czas:

(1) Przestań wpuszczać nowe transakcje (2) Czekaj na koniec wszystkich transakcji (3) Zrzuć (flush) dziennik na dysk

(4) Zrzuć (flush) strony danych na dysk

• Ale nie usuwaj ich z pamięci

(5) Wpisz do dziennika „punkt kontrolny”

(6) Wznów przetwarzanie transakcji

• bez akcji <ti, end>

• prosty punkt kontrolny

Co przy odtwarzaniu?

Dziennik powtórzeń (dysk)

<T1,A,16> <T1,commit> Checkpoint <T2,B,17> <T2,commit> <T3,C,21>

... ... ... ... ... ... Bum!

Poważne wady

• Dziennik wycofań

– Nie umożliwia odtwarzania z kopii zapasowej

• Dziennik powtórzeń

– Zmodyfikowane bloki muszą być trzymane w pamięci aż do zatwierdzenia

Dziennik wycofań i powtórzeń

Gdy zmiana X, to wpisz do dziennika

<Ti, Xid, nowa wartość X, stara wartość X>

Reguły dziennika wycofań i powtórzeń

• Stronę X można zapisać przed lub po zatwierdzeniu Ti

• Wpisy dziennika muszą być zrzucane (flush) przed zapisem odpowiedniej zmodyfikowanej strony (WAL)

• Zrzuć (flush) ale tylko dziennik przy zatwierdzeniu

Niespoczynkowy punkt kontrolny

Dziennik

żeby brudne wycofać strony

zrzucone

Start-ckpt aktywne:

Ti,Tj,...

end

ckpt ...

...

...

...

Co się dzieje przy odtwarzaniu?

Dziennik brak commit dla T1

T1,-

a ... Ckpt

T1 ... Ckptend ... T1- ... b

 Wycofaj T1 (wycofaj a,b)

Powtórzenie

Dziennik

... Ta ...¹ ... Tb ...¹ ... Tc ...¹

T1

cmt ...

ckpt- end

ckpt-s

T1

 Powtórz T1: (powtórz b,c)

Proces odtwarzania

• Przebieg wstecz (koniec dz.  ostatni początek pktu kontr.)

– Wyznacz S = zbiór transakcji zatwierdzonych – Wycofaj akcje transakcje spoza S

• Wycofaj niezakończone transakcje

– Przemierz łańcuchy wycofań transakcji

(lista transakcji aktywnych punktu kontr.) - S

• Przebieg wprzód (ostatni początek pktu kontr.  koniec dz.)

– Powtórz akcje transakcji z S przebieg wstecz przebieg wprzód

start check-

Akcje „materialne” („realne”)

• Np. wypłata z bankomatu Ti = a¹ a² …... a^j …... Aⁿ

• Wykonuj je po zatwierdzeniu

• Zaplanuj ręczne procedury odtwarzania

PLN

Awaria nośnika

A: 16

Rozwiązanie: Rób kopie zapasowe!

1: potrójna nadmiarowość

• Utrzymuj 3 kopie na niezależnych dyskach

• Output(X) --> trzy zapisy

• Input(X) --> trzy odczyty + głosowanie

X1 X2 X3

2: nadmiarowe zapisy, jeden odczyt

• Utrzymuj N kopii na niezależnych dyskach

• Output(X) --> trzy zapisy

• Input(X) --> Odczyt z jednej kopii - jeśli OK, gotowe - wpp. użyj innej

 Przy zalożeniu że można wykryć błędy w danych

3: Kopia zapasowa + dziennik

kopia

zapasowa baza

danych dziennik

• Jeśli stracono bazę danych

– odtwórz bazę z kopii zapasowej

– przywróć jej aktualny stan używając dziennika

• Kopia zapasowa może być tworzona na gorąco – analogicznie jak punkt kontrolny

Kiedy można obciąć dziennik?

check- point kopia

zapas.

ostatnie potrz.

wycofan.

Nie jest potrzebne po awarii nośnika

Nie jest potrzebne do wycofań po awarii systemu

Nie jest potrzebne do powtórzeń po awarii systemu

dziennik

czas

Podsumowanie

• Integralność danych

• Jedno ze źródeł problemów: awarie

- Dziennik

- Nadmiarowość

• Drugie ze źródeł problemów:

współdzielenie danych... później