Microsoft PowerPoint - W5_bd_pd [tryb zgodno\234ci]

Transkrypt

Microsoft PowerPoint - W5_bd_pd [tryb zgodno\234ci]
Plan wykładu
2
BAZY DANYCH
Wykład 5: Transakcje. Hurtownie danych.
Transakcje
Hurtownie danych
Małgorzata Krętowska
Wydział Informatyki
Politechnika Białostocka
Wprowadzenie
Zmiany zachodzące w świecie rzeczywistym są
zakodowane w aplikacji obsługującej bazę danych
w postaci ciągu instrukcji, które powinny
przekształcać bazę danych z jednego stanu
spójnego w inny
Problemy, na które może natknąć się aplikacja:
Awarie systemu
Współbieżny dostęp do danych
Rozproszenie danych
Przykład
Aplikacja implementująca przelew kwoty N z konta A
na konto B
Problem 1 – awaria systemu
Po pobraniu kwoty N z konta A, i zapisaniu tej aktualizacji do
bazy danych, wystąpiła awaria systemu. W wyniku awarii
systemu wykonana została jedynie część operacji
składających się na daną aplikację
Problem 2 – współbieżny dostęp do danych
Operacje współbieżnie wykonywanych transakcji mogą
naruszać spójność bazy lub generować niepoprawne wyniki
Źródło: http://wazniak.mimuw.edu.pl/index.php?title=Bazy_danych
Transakcje
Przykład cd
6
Problem 3 - utrata danych w wyniku awarii
Wyniki zakończonych aplikacji, buforowane w pamięci
operacyjnej, mogą zostać utracone w wyniku awarii
systemu
Rozwiązanie tych problemów: transakcje
Pożądane właściwości transakcji
(ACID)
Transakcja – jest wykonywanym programem, który
tworzy logiczną jednostkę przetwarzania w bazie
danych. Transakcja składa się z jednej lub wielu
operacji dostępu do bazy danych. Jednym ze
sposobów określania zakresu transakcji jest
wyróżnienie jawnych instrukcji begin i end transaction.
Jeżeli operacje bazodanowe należące do transakcji
nie aktualizują bazy danych, a tylko pobierają dane, o
transakcji mówimy, że jest tylko do odczytu.
Przykład
7
atomowość (atomicity) - cała transakcja powinna
zostać przeprowadzona, albo żaden z jej elementów
nie zostanie uwzględniony
spójność (consistency) - np. miejsce w danym rejsie
lotniczym nie może być przydzielone dwóm różnym
pasażerom
izolacja (isolation) - brak wpływu transakcji na siebie
przy jednoczesnym ich przetwarzaniu
trwałość (durability) - po zakończeniu transakcji jej
wynik nie może zostać utracony
Transakcja przelewu kwoty N z konta A na konto B
Transakcja logiczna a transakcja
fizyczna
Przykład cd.
Problem utraconej aktualizacji
11
Problem aktualizacji tymczasowej
12
T1
T2
T1
Odczytaj_element (X);
X:=X-N;
Zapisz_element (X);
Odczytaj_element (X);
X:=X-N;
Odczytaj_element (X);
X:=X+M;
Zapisz_element(X);
Odczytaj_element (X);
X:=X+M;
Zapisz_element (X);
Odczytaj_element (Y);
Zapisz_element (Y);
Zapisz_element(X);
Y:=Y+N;
Zapisz_element (Y);
T2
Transakcja T1 kończy się niepowodzeniem i musi zmienić wartość X
z powrotem do jej oryginalnego stanu; w tym czasie T2 odczytuje jej
tymczasową niepoprawną wartość
Problem błędnego podsumowania
13
Odczyt niepowtarzalny
14
T1
Odczytaj_element (X);
X:=X-N;
Zapisz_element (X);
Występuje wówczas, gdy transakcja T1 odczytuje
element dwukrotnie, czy czym element ten zostaje
zmieniony przez inną transakcję T2 między tymi dwoma
odczytami
Przykład:
T1: R(X),
R(X), W(X)
T2:
R(X), W(X)
T2
Suma:=0;
Odczytaj_element(A);
suma:=suma+A;
...
Odczytaj_element (X);
suma:=suma+X;
Odczytaj_element (Y);
suma:=suma+Y;
Czas ------->
Odczytaj_element (Y);
Y:=Y+N;
Zapisz_element (Y);
Gdzie: R(X) – odczytaj_ element X, W(X) – zapisz_element X
Diagram przejść stanów związanych
w wykonaniem transakcji
Operacje związane z transakcjami
15
16
Transakcja jest niepodzielną jednostką działań, które muszą być
wykonane w całości lub w ogóle. Do celów odtwarzania system
musi śledzić następujące operacje:
ROZPOCZNIJ_TRANSAKCJĘ
ODCZYTAJ lub ZAPISZ – operacje odczytu i zapisu przeprowadzane na
elementach bazy danych
ZAKOŃCZ_TRANSAKCJĘ – należy zweryfikować czy zmiany wprowadzone
przez transakcję mogą zostać zatwierdzone, czy transakcja ma być
anulowana
ZATWIERDŹ_TRANSAKCJĘ (COMMIT)– oznaczenie udanego zakończenia
transakcji
WYCOFAJ (ROLLBACK)– nieudane zakończenie transakcji
Odczytaj
zapisz
Rozpocznij
transakcję
Zakończ
transakcję
Aktywna
Anuluj
zatwierdź
Zatwierdzona
częściowo
Zatwierdzona
Anuluj
awaria
Zakończona
Dziennik systemowy (ang. log)
17
Punkt zatwierdzenia transakcji
18
W celu umożliwienia odtwarzania po awariach wpływających na
transakcje system przechowuje dziennik, w którym śledzi wszystkie
operacje związane z transakcjami, mające wpływ na wartości
elementów bazy danych.
Dziennik jest przechowywany na dysku i jest okresowo
archiwizowany na taśmie, w celu zabezpieczenia go przed
awariami.
Rodzaje wpisów do dziennika (rekordy dziennika):
Transakcja osiąga swój punkt zatwierdzenia, gdy wszystkie jej
operacje zostaną z powodzeniem wykonane oraz ich wyniki
zostaną zarejestrowane w dzienniku.
Za punktem zatwierdzenia mówi się, ze transakcja została
zatwierdzona, a jej działania za trwale zapisane w bazie
Kolejną czynnością jest zapisanie do dziennika rekordu
zatwierdzenia.
Jeżeli nastąpi awaria wszystkie transakcje które rozpoczęły
swoje działanie, a dla których nie ma wpisu w dzienniku należy
wycofać.
[rozpocznij_transakcję,T]
[zapisz_element, T,X, stara wartość, nowa wartość]
[odczytaj_element, T,X]
[zatwierdź, T]
[anuluj,T]
Harmonogramy (plany) transakcji
19
Przykład
20
T1
Gdy transakcje są wykonywane współbieżnie w
technice przeplotu, kolejność wykonywania operacji
związanych z różnymi transakcjami określa się mianem
harmonogramu (historii, planu).
Harmonogram S zbioru n transakcji T1, T2,.., Tn jest
uporządkowaniem operacji transakcji podlegającym
ograniczeniu, które określa, że dla każdej transakcji Ti
należącej do harmonogramu S, operacje tej transakcji
w S muszą występować w tej samej kolejności, w jakiej
występują w Ti.
T2
Odczytaj_element (X);
X:=X-N;
Odczytaj_element (X);
X:=X+M;
Zapisz_element (X);
Odczytaj_element (Y);
Y:=Y+N;
Zapisz_element (Y);
Zapisz_element(X);
Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y)
a: anulowanie; c – zatwierdzanie transakcji
Możliwości odtwarzania
harmonogramów
21
Szeregowalność harmonogramów
22
Harmonogramy odtwarzalne – dla których w momencie zatwierdzenia
transakcji T już nigdy nie było konieczne jej wycofanie (lub inaczej:
harmonogram, który umożliwia wycofanie każdej transakcji)
–
Harmonogram S jest odtwarzalny, jeżeli żadna transakcja T w harmonogramie S nie
jest zatwierdzona do momentu, aż wszystkie transakcje T’, które zapisały element
odczytywany przez transakcję T, zostaną zatwierdzone.
S: r1(x), w1(x), r2(x), w2(x), c1, c2 (+)
S: r1(x), w1(x), r2(x), w2(x), c2, c1 (-)
Pojęcie szeregowalności harmonogramów jest używane w celu identyfikowania,
które harmonogramy są poprawne w przypadku, gdy wykonanie transakcji
dopuszcza przeplot ich operacji.
Harmonogram szeregowy – harmonogram ustawiający wykonywanie
transakcji w ciąg: najpierw akcje jednej transakcji, następnie akcje drugiej
transakcji itd. Zakładając, że transakcje są niezależne, można założyć, że
każdy harmonogram szeregowy jest poprawny
Harmonogramy nieodtwarzalne – nie spełniają powyższego wymogu, stąd nie
powinno się pozwalać na ich występowanie (Przykłady: problem aktualizacji
tymczasowej i problem utraconej aktualizacji)
Dwa harmonogramy są równoważne, jeżeli efekt realizacji obu
harmonogramów jest taki sam dla każdego stanu bazy danych, tzn
W1: Każda transakcja w obu planach odczytuje i zapisuje te same
wartości
W2: Po realizacji każdego z planów otrzymujemy ten sam stan bazy
danych
Przykład
Plan szeregowalny
23
Zakładamy wartości początkowe x=90, y=90, n=3, m=2
Sa (szeregowy), wynik: x=89, y=93):
T1:r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c
T2:
r(x), x=x+m, w(x),c
Sb (szeregowy, wynik: x=89, y=93):
T1:
T2:
r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c
r(x), x=x+m, w(x),c
Sc (nieszeregowy, wynik: x=92, y=93)
T1:r(x), x:=x-n;
T2:
w(x), r(y),
r(x), x=x+m,
y=y+n, w(y),c
w(x),c
Sd (nieszeregowy, wynik: x=89, y=93)
T1:r(x), x:=x-n,w(x),
T2:
r(y), y=y+n, w(y),c
r(x), x=x+m,w(x),c
Plan (harmonogram) szeregowalny jest to plan, który jest równoważny
pewnemu planowi szeregowemu (a przez to jest poprawny).
Dzięki własnościom W1 i W2 plan szeregowalny zapewnia uzyskanie
własności izolacji (W1) i spójności (W2).
Plan szeregowalny nie daje gwarancji, że po wycofaniu transakcji nie
trzeba będzie wycofywać akcji innych transakcji, co może być
niewykonalne, gdy jedna z transakcji zostanie już zatwierdzona. Brak
gwarancji spełnienia własności atomowości i trwałości.
Protokół ścisłego blokowania
dwufazowego (Strict 2PL)
Blokady
25
26
Blokady (zamki) – podstawowy mechanizm zapobiegający konfliktom przy
współbieżnie wykonywanych transakcjach
Każda transakcja musi uzyskać blokadę S na obiekcie zanim
odczyta ten obiekt oraz blokadę X na obiekcie przed zapisaniem
go.
Jeśli transakcja trzyma blokadę X na obiekcie, żadna inna
transakcja nie ma prawa założyć żadnej blokady na tym obiekcie
Jeśli transakcja trzyma blokadę S na obiekcie, żadna inna
transakcja nie ma prawa założyć blokady X na tym obiekcie
Gdy transakcja nie może założyć blokady na obiekcie, może
ustawić się w kolejce oczekujących transakcji stowarzyszonej z tym
obiektem.
Wszystkie blokady trzymane przez transakcję są zwalniane
jednocześnie, w chwili, gdy transakcja kończy się
Rodzaje blokad:
Współdzielona , typu S (ang. shared lock) – daje transakcji współdzielony
dostęp do zasobu (kilka transakcji może jednocześnie odczytywać wiersze z tej
samej tabeli). Jeśli transakcja zakłada współdzieloną blokadę, inne transakcje
też mogą założyć współdzieloną blokadę, ale nie mogą założyć blokady
drugiego rodzaju, tzn. wyłącznej
Wyłączna, typu X (ang. exclusive lock) – daje transakcji wyłączne prawo do
zmian obiektu. Tylko jedna transakcja może mieć założoną wyłączną blokadę
na obiekcie i w tym czasie nie może być na obiekcie założonej żadnej innej
blokady, nawet współdzielonej.
Istnieje metoda zakładania blokad gwarantująca powstanie i realizację planów
wyłącznie szeregowalnych i odtwarzalnych – protokół ścisłego blokowania
dwufazowego.
Protokół ścisłego blokowania
dwufazowego (Strict 2PL)
Protokół blokowania dwufazowego
2PL
28
27
Można w nim wyróżnić dwie fazy:
Transakcja zakłada blokady i dokonuje wymaganych
odczytów i zapisów na obiektach, na których
założyła blokadę
Transakcja wykonuje COMMIT/ROLLBACK
jednocześnie zwalniając wszystkie blokady
Protokół Strict 2PL nie dopuszcza do anomalii
utraconej aktualizacji, aktualizacji tymczasowej,
błędnego podsumowania oraz niepowtarzalnego
odczytu:
Zamiast punktu w protokole Strict 2PL:
Wszystkie blokady trzymane przez transakcję są zwalniane jednocześnie, w chwili,
gdy transakcja kończy się
Występuje sformułowanie:
Transakcja nie może założyć żadnej nowej blokady po zwolnieniu jakiejkolwiek
blokady.
Protokół 2PL prowadzi do planów szeregowalnych, ale nie
gwarantuje planów odtwarzalnych.
Przykład:
T1: R(X) W(X)
T2:
a
R(X) W(X) c
Zakleszczenia (deadlocks)
Zakleszczenia
29
Zjawisko zakleszczenia występuje wówczas, kiedy dwie lub więcej transakcji wzajemnie
blokują sobie – potrzebne do kontynuowania swojego działania – obiekty
Zakleszczenie- jest to cykl transakcji oczekujących wzajemnie na zwolnienie blokady
przez inną transakcję w cyklu.
Sposoby radzenia sobie z zakleszczeniami:
Wykrywanie zakleszczeń – polega na analizie, która transakcja oczekuje na
zwolnienie blokady przez która transakcję i sprawdzaniu, czy występuje cykl
•
Utwórz graf oczekiwań na zwolnienie blokady (węzły – transakcje, krawędź Ti do
Tj jeśli transakcja Ti oczekuje na zwolnienie blokady przez Tj)
Zapobieganie
Co jakiś czas sprawdzaj, czy w grafie jest cykl. Jeśli jest wycofaj jedną z transakcji
w cyklu
Wykrywania
Przykład:
Ustalanie limitu oczekiwania na blokadę (metoda timeout)
T1:S(A), R(A)
•
S(B)
T2:
X(B), W(B)
Zapobieganie
ustalenie priorytetu między transakcjami.
Nie dopuszcza się aby transakcja z wyższym priorytetem czekała na
transakcje z niższym priorytetem
W przypadku zakleszczenia transakcja z niższym priorytetem zostaje
wycofana przez system
X(C)
T3:
S(C), R(C)
X(A)
T4:
X(B)
Graf oczekiwań na zwolnienie blokady:

Podobne dokumenty