(Microsoft PowerPoint - BD_W13_D_student [tryb zgodno\234ci])

Plan wykładu
• Budowa fizycznego projektu bazy danych
Bazy danych
• Strojenie bazy danych
Wykład 13: Praktyczne projektowanie i
strojenie baz danych.
Wstęp do transakcji.
• Transakcje
Małgorzata Krętowska
e-mail: [email protected]
2
Czynniki wpływające na fizyczny projekt
bazy danych
Czynniki wpływające na fizyczny projekt
bazy danych
Projektowanie fizyczne to działanie, którego celem jest nie tylko otrzymanie
odpowiedniej struktury przechowywania danych, ale również dokonanie tego w
sposób gwarantujący wysoką wydajność działania:
• Analiza zapytań i transakcji w bazie danych
• Analiza spodziewanej częstotliwości wywoływania zapytań i
transakcji – informacje o spodziewanej częstości użycia każdego
atrybutu jako atrybutu wyboru lub złączenia („reguła 80-20” - około 80%
czasu przetwarzania jest związane z tylko 20% zapytań i transakcji)
• Analiza więzów czasowych na zapytaniach i transakcjach –
niektóre zapytania i transakcje mogą posiadać ograniczenia co do
wydajności ich działania np. transakcja ma w 95 % przypadków
kończyć swoje działanie przed upływem 5 sekund i nie powinna być
wykonywana dłużej niż 20 sekund. Powoduje to ustalenie priorytetów
ustalania struktur dostępu do odpowiednich atrybutów
• Analiza spodziewanej częstotliwości operacji aktualizacji – dla
pliku, który podlega częstym aktualizacjom należy określić minimalną
liczbę ścieżek dostępu
• Analiza więzów unikatowości na atrybutach – ścieżki dostępu
powinny zostać określone na wszystkich atrybutach klucza
kandydującego (klucz główny albo więzy unikatowości). Wówczas
wszystkie wartości atrybutu występują w wierzchołkach liści indeksu.
– Zapytania – należy określić:
• Pliki, do których zapytanie będzie uzyskiwało dostęp.
• Atrybuty, na których są określone warunki wyboru zapytania
• Atrybuty, na których są określone warunki złączeń
• Atrybuty, których wartości będą zwracane przez zapytanie
Atrybuty z pkt. 2 i 3 są kandydatami do określenia struktur dostępu
– Transakcje – należy określić:
• Pliki, które będą aktualizowane
• Rodzaj operacji wykonywanej na każdym pliku (wstawianie, aktualizowanie...)
• Atrybuty, na których są określone warunki wyboru dla operacji usuwania lub
aktualizowania
• Atrybuty, których wartości będą zmieniane przez operację aktualizacji
Atrybuty z pkt. 3 to kandydaci do struktur dostępowych. Atrybuty z pkt. 4 nie powinny być
wykorzystywane do definiowania struktur dostępowych.
3
4
Decyzje projektowe dotyczące indeksów
Decyzje projektowe dotyczące indeksów
– Określenie, czy należy utworzyć indeks klastrowania – w przypadku każdej
tabeli może istnieć tylko jeden indeks główny (atrybut jest kluczem) lub
klastrowania (atrybut nie jest kluczem). Jeżeli tabela wymaga kilku
indeksów decyzja o tym, który powinien być indeksem klastrowania zależy
od tego, czy istnieje konieczność uporządkowania tabeli według danego
atrybutu. Jeżeli odpowiedź dla zapytania ma być uzyskiwana tylko przez
przegląd indeksu, nie powinien być on indeksem klastrowania -> największe
korzyści przynosi indeks klastrowania, gdy pobierane są rekordy danych.
– Określenie, czy należy użyć indeksu mieszającego (haszowanego) zamiast
drzewa – SZRBD wykorzystują przeważnie B+-drzewa w celu
indeksowania. Obsługują one zarówno zapytania równościowe jak też
zakresowe. W przypadku indeksu mieszającego – jest on wykorzystywany
w warunkach równościowych, szczególnie w trakcie złączeń.
Atrybuty, których wartości występują w warunkach wyboru oraz te, które są
kluczami lub występują w warunkach złączeń wymagają określenia
ścieżek dostępu. Z drugiej strony operacje wstawiania, usuwania,
aktualizacji przy obecności indeksów trwają dłużej.
– Określenie, czy należy indeksować dany atrybut – atrybut musi być kluczem
lub musi występować zapytanie wykorzystujące ten atrybut w warunku
wyboru lub złączeniu. Tworzenie wielu indeksów -> niektóre zapytania
mogą być przetwarzane poprzez przegląd samego indeksu, bez pobierania
danych z bazy.
– Określenie, jaki atrybut (atrybuty) powinien być indeksowany – tworzenie
indeksu zbudowanego z kilku atrybutów pochodzących z jednej relacji ma
sens wówczas, gdy są one uwzględniane razem w kilku zapytaniach.
Kolejność atrybutów w indeksie powinna być taka sama jak w zapytaniu
5
6
Denormalizacja
Strojenie baz danych
• Poprawa działania bazy danych po jej wdrożeniu i uruchomieniu,
mająca na celu uwzględnienie problemów i czynników, których nie
uwzględniono w czasie początkowego projektowania bazy. Konieczne
stałe monitorowanie działania bazy.
• Cele procesu strojenia:
• Normalizacja – celem jest rozdzielenie logiczne powiązanych
atrybutów między tabele w celu zminimalizowania
nadmiarowości, a przez to uniknięcia anomalii aktualizacji
– Przyspieszenie działania aplikacji
– Skrócenie czasu odpowiedzi na zapytania i transakcje
– Zwiększenie ogólnej przepustowości transakcji
• Denormalizacja – zmiana logicznego projektu bazy danych na
słabszą postać np. 2NF w celu uzyskania możliwości szybszego
wykonywania często występujących zapytań i transakcji.
Zazwyczaj projektant dodaje do tabeli atrybuty, które są
wymagane w celu uzyskania odpowiedzi na zapytanie, tak aby
można było uniknąć złączenia z inną tabelą. Powoduje to
powstanie odpowiednich problemów z redundancją danych.
• Decyzje związane z etapem strojenia są takie same jak decyzje
podejmowane na etapie budowy projektu fizycznego, przy czym danymi
wejściowymi procesu strojenia są dane zebrane w trakcie działania
systemu:
–
–
–
–
7
Rozmiary poszczególnych tabel
Liczba odrębnych wartości w kolumnie
Liczba powtórzeń danego zapytania lub transakcji w danym okresie czasu
Czas wymagany dla różnych etapów przetwarzania zapytań i transakcji
8
Strojenie baz danych
•
Strojenie indeksów i zapytań
Inne informacje otrzymywane na podstawie monitorowania działania systemu
bazy danych:
• Początkowy wybór indeksów można zmienić z następujących
powodów:
– Statystyki dotyczące składowania danych – podział obszaru składowania na
przestrzenie tabel i indeksów
– Statystyki dotyczące operacji wejścia-wyjścia i wydajności urządzeń – dane związane
z operacjami odczytu i zapisu na dysku, obszary dysku o największej aktywności
– Statystyki dotyczące przetwarzania zapytań i transakcji - czas wykonania tych
operacji, czas optymalizacji zapytań
– Statystyki dotyczące blokad i rejestrowania zdarzeń
– Statystyki dotyczące indeksów – np. liczba poziomów indeksu
•
– Określone zapytania mogą działać zbyt długo ze względu na brak
indeksu
– Niektóre indeksy mogą w ogóle nie być używane
– Niektóre indeksy mogą nakładać spory narzut związany z tym, że są
zdefiniowane na atrybutach często podlegających zmianom
Strojenie bazy danych wiąże się z pokonywaniem następujących problemów:
• Strojenie zapytań
– Unikanie zbyt częstych rywalizacji o zasoby dzielone
– Minimalizowanie narzutu związanego z rejestrowaniem i niepotrzebnym awaryjnym
kopiowaniem danych
– Optymalizowanie rozmiaru bufora i szeregowanie procesów
– Przydzielanie zasobów takich jak dyski, pamięć RAM i procesy w sposób
zapewniający jak najwydajniejsze ich wykorzystanie.
– Zapytanie generuje zbyt wiele operacji dostępu do dysku
– Plan zapytania ujawnia, że odpowiednie indeksy nie są używane
9
10
Strojenie projektu bazy danych
Systemy jedno- i wieloużytkownikowe
• Istniejące tabele mogą być łączone (denormalizacja), ponieważ
niektóre atrybuty pochodzące z dwóch lub większej liczby tabel
są często wymagane wspólnie.
• W przypadku danego zbioru tabel mogą istnieć alternatywne
rozwiązania projektowe, dające w efekcie schemat w postaci
3NF lub BCNF.
• Partycjonowanie pionowe tabeli – jeżeli tabela zawiera bardzo
dużą liczbę wierszy można ją rozbić na większą liczbę tabel z
podzbiorami atrybutów i replikacjami klucza tabeli. Zapytania do
każdej z tabel są niezależne.
• Atrybuty jednej tabeli mogą być powtórzone w innej
• Partycjonowanie poziome – podział tabeli w poziomie na kilka
oddzielnych tabel np. tabela sprzedaży produktów jest
podzielona na na kilka tabel w oparciu na różne linie produkcyjne
System jednoużytkownikowy – jeżeli w danym momencie z systemu może
korzystać tylko jeden użytkownik
System wieloużytkownikowy – w danym momencie z systemu może
korzystać wielu użytkowników współbieżnie.
Przetwarzanie z przeplotem
A
Przetwarzanie równoległe
A
B
C
B
CPU1
D
t1
11
t2
t3
CPU2
t4
czas
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.
– 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
• 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.
13
Problem utraconej aktualizacji
T1
14
Problem aktualizacji tymczasowej
T2
T1
Odczytaj_element (X);
X:=X-N;
T2
Odczytaj_element (X);
X:=X-N;
Zapisz_element (X);
Odczytaj_element (X);
X:=X+M;
Odczytaj_element (X);
X:=X+M;
Zapisz_element(X);
Zapisz_element (X);
Odczytaj_element (Y);
Zapisz_element (Y);
Zapisz_element(X);
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ść
Y:=Y+N;
Zapisz_element (Y);
15
16
Problem błędnego podsumowania
T1
Odczytaj_element (X);
X:=X-N;
Zapisz_element (X);
Odczyt niepowtarzalny
T2
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
Suma:=0;
Odczytaj_element(A);
suma:=suma+A;
...
Przykład:
T1: R(X),
T2:
R(X), W(X)
Odczytaj_element (X);
suma:=suma+X;
Odczytaj_element (Y);
suma:=suma+Y;
R(X), W(X)
Czas ------->
Odczytaj_element (Y);
Y:=Y+N;
Zapisz_element (Y);
Gdzie: R(X) – odczytaj_ element X, W(X) – zapisz_element X
17
Potrzeba obsługi mechanizmów
odtwarzania
18
Potrzeba obsługi mechanizmów
odtwarzania
• Po przekazaniu transakcji do wykonania, SZBD jest
odpowiedzialny za zapewnienie, aby:
• Błędy lokalne lub wyjątki wykryte przez transakcję – np
wymagane przez transakcję dane są niedostępne
• Wymuszenie sterowania współbieżnego – metoda sterowania
współbieżnego może zdecydować o anulowaniu transakcji i
późniejszym jej wznowieniu np. stan zakleszczenia kilku
transakcji
• Awaria dysku
• Problemy i katastrofy fizyczne – zanik napięcia, pożar,
zamontowanie nieodpowiedniej taśmy
– Wszystkie operacje wykonywane w ramach transakcji zostały
zakończone z powodzeniem i wyniki zapisane w bazie danych, albo
– Transakcja nie miała wpływu na bazę danych i inne transakcje
• Nie może być sytuacji, gdy pewne operacje są uwzględnione w
bazie a inne nie. Taka możliwość może zachodzić w przypadku,
gdy transakcja ulegnie uszkodzeniu po wykonaniu tylko części
swoich operacji.
• Rodzaje awarii (transakcyjne, systemowe i nośników):
– Awaria komputera – błąd sprzętowy
– Błąd transakcyjny lub systemowy – uszkodzenie transakcji w trakcie
jej wykonania np. dzielenie przez 0; błąd programisty; przerwanie
transakcji przez użytkownika
19
20
Diagram przejść stanów związanych w
wykonaniem transakcji
Operacje związane z transakcjami
Odczytaj
zapisz
• 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ę
– 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Ę – oznaczenie udanego zakończenia
transakcji
– WYCOFAJ – nieudane zakończenie transakcji
Zakończ
transakcję
Aktywna
Anuluj
zatwierdź
Zatwierdzona
częściowo
Zatwierdzona
Anuluj
awaria
Zakończona
21
Dziennik systemowy (ang. log)
Punkt zatwierdzenia transakcji
• 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):
–
–
–
–
–
22
• 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]
23
24
Harmonogramy (plany) transakcji
Przykład
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
25
Konflikt w harmonogramie
Harmonogram pełny
• Dwie operacje w transakcji są w stanie konfliktu, jeżeli spełniają
wszystkie trzy z następujących warunków:
• Harmonogram składający się z n transakcji jest pełny, gdy:
– Operacje harmonogramu S są dokładnie tymi samymi operacjami,
które występowały w transakcjach T1,..., Tn wliczając w to operacje
zatwierdzania lub anulowania dla każdej transakcji
– Dla dowolnej pary operacji należących do tej samej transakcji Ti
kolejność ich występowania w harmonogramie S jest taka sama jak
kolejność w transakcji Ti
– Dla dowolnych dwóch transakcji konfliktowych jedna z nich musi
występować w harmonogramie przed drugą.
– Należą do różnych transakcji
– Uzyskują dostęp do tego samego elementu X
– Przynajmniej jedna z operacji jest operacją zapisz_element();
– Przykład: Które operacje są w konflikcie?
S: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y)
•
•
•
26
r1(X), w2(X)
r2(X), w1(X)
w1(X), w2(X)
27
28
Możliwości odtwarzania harmonogramów
Szeregowalność harmonogramów
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)
–
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 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 (-)
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)
•
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
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
29
Plan szeregowalny
Przykład
•
Zakładamy wartości początkowe x=90, y=90, n=3, m=2
•
Sa (szeregowy), wynik: x=89, y=93):
• 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.
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),
• Sprawdzenie szeregowalności: konstrukcja grafu pierwszeństwa
(inaczej grafu szeregowania)
y=y+n, w(y),c
r(x), x=x+m,
w(x),c
Sd (nieszeregowy, wynik: x=89, y=93)
T1:r(x), x:=x-n,w(x),
T2:
30
r(y), y=y+n, w(y),c
r(x), x=x+m,w(x),c
31
Weryfikacja szeregowalności
(algorytm tworzenia grafu pierwszeństwa)
Przykład
1. Dla każdej transakcji Ti należącej do harmonogramu S utwórz w
grafie pierwszeństwa wierzchołek Ti
2. Dla każdego przypadku w S, gdy Tj wykonuje operację r(x) po
wykonaniu przez transakcję Ti operacji w(x), utwórz w grafie
pierwszeństwa krawędź (Ti->Tj)
3. Dla każdego przypadku w S, gdy Tj wykonuje operację w(x) po
wykonaniu przez transakcję Ti operacji r(x), utwórz w grafie
pierwszeństwa krawędź (Ti->Tj)
4. Dla każdego przypadku w S, gdy Tj wykonuje operację w(x) po
wykonaniu przez transakcję Ti operacji w(x), utwórz w grafie
pierwszeństwa krawędź (Ti->Tj)
5. Harmonogram S jest szeregowalny wtedy i tylko wtedy, gdy graf
pierwszeństwa nie zawiera cykli.
Przykład planu nieszeregowalnego:
T1: r(a), w(a),
T2:
•
Protokół ścisłego blokowania
dwufazowego (Strict 2PL)
Blokady (zamki) – podstawowy mechanizm zapobiegający
konfliktom przy współbieżnie wykonywanych transakcjach
Rodzaje blokad:
–
–
•
r(a), w(a), r(b), w(b),
Cykl w grafie pierwszeństwa:
Blokady
•
r(b), w(b)
•
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.
•
•
•
•
35
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ę
36
Protokół ścisłego blokowania
dwufazowego (Strict 2PL)
•
Zamiast punktu w protokole Strict 2PL:
Można w nim wyróżnić dwie fazy:
–
–
•
Protokół blokowania dwufazowego 2PL
Wszystkie blokady trzymane przez transakcję są zwalniane jednocześnie, w chwili,
gdy transakcja kończy się
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
Występuje sformułowanie:
Transakcja nie może założyć żadnej nowej blokady po zwolnieniu jakiejkolwiek
blokady.
Protokół Strict 2PL nie dopuszcza do anomalii utraconej
aktualizacji, aktualizacji tymczasowej, błędnego
podsumowania oraz niepowtarzalnego odczytu:
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
37
38
Zakleszczenia
Zakleszczenia (deadlocks)
•
Zjawisko zakleszczenia występuje wówczas, kiedy dwie lub więcej transakcji
wzajemnie blokują sobie – potrzebne do kontynuowania swojego działania –
obiekty
Wykrywanie zakleszczeń – polega na analizie, która transakcja oczekuje na
zwolnienie blokady przez która transakcję i sprawdzaniu, czy występuje
cykl
•
Zakleszczenie- jest to cykl transakcji oczekujących wzajemnie na
zwolnienie blokady przez inną transakcję w cyklu.
•
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)
•
Sposoby radzenia sobie z zakleszczeniami:
–
Zapobieganie
–
Wykrywania
–
Ustalanie limitu oczekiwania na blokadę (metoda timeout)
•
Co jakiś czas sprawdzaj, czy w grafie jest cykl. Jeśli jest wycofaj jedną z
transakcji w cyklu
Przykład:
T1:S(A), R(A)
T2:
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
39
T3:
S(B)
X(B), W(B)
X(C)
S(C), R(C)
T4:
X(A)
X(B)
Graf oczekiwań na zwolnienie blokady: