T - Kolos

Transkrypt

T - Kolos

PODSTAWY
BAZ DANYCH
Wykład 9
7. Transakcje
Podstawy teoretyczne
2005/2006
Wykład "Podstawy baz danych"
1
Zbiór cech transakcji
Transakcja jest to zespół operacji na bazie danych
(INSERT, UPDATE, DELETE ) charakteryzujący
się następującymi własnościami:
• Niepodzielność (Atomicity)
• Spójność stanu (Consistency)
• Trwałość (Durability)
• Wyłączność (Isolation)
• Szeregowalność (Serializability)
2005/2006
2
Niepodzielność (Atomicity)
Transakcja musi być niepodzielną jednostką
przetwarzania i może zostać zrealizowana w
całości, albo nie zrealizowana w ogóle.
Realizacja transakcji nie może zakłócić poprawności danych.
Przez stan poprawny danych rozumiemy taki
stan, w którym wszystkie wartości atrybutów obiektów
występujących w bazie mają stan zgodny z
oczekiwaniami, tzn. wartość należącą do zbioru wartości
danego atrybutu i właściwie odzwierciedlającą stan
modelowanej rzeczywistości.
2005/2006
3
Spójność stanu (Consistency)
Poprawne wykonanie transakcji musi
przeprowadzić bazę z jednego stanu spójnego
w drugi.
Stan spójny, to taki, w którym wszelkie
istniejące powiązania pomiędzy obiektami tworzą
logiczną całość tzn. np. nie ma odwołań do
obiektów nie istniejących w bazie.
2005/2006
4
Trwałość (Durability)
Niedokończenie transakcji spowodowane
błędami środowiska systemowego nie może
doprowadzić do uszkodzenia żadnej z baz.
Wyłączność (Isolation)
Zmiany wprowadzane przez transakcję do
bazy danych nie mogą być widoczne dla
innych transakcji aż do momentu ich
ostatecznego zatwierdzenia (zrealizowania
transakcji w całości).
2005/2006
5
Następna własność dotyczy kilku transakcji
wykonywanych jednocześnie.
Szeregowalność (Serializability)
Efekt wykonania kilku transakcji jednocześnie
(z przełączaniem zadań) musi być równoważny
oddzielnemu wykonaniu każdej z nich w pewnej
ustalonej kolejności.
Wówczas transakcje takie nazywamy szeregowalnymi.
2005/2006
6
Przyczyny powodujące załamanie procesu wykonania transakcji
1.Błąd systemu komputerowego (system crash).
Awarie związane z oprogramowaniem lub sprzętem,
zaistniałe podczas wykonywania transakcji. Prawie
zawsze związane z utratą zawartości pamięci
operacyjnej komputera.
2. Błąd transakcji lub SZBD.
Załamanie wykonania może być spowodowane np.
próbą wykonania przez transakcję operacji dzielenia
przez zero, przekroczeniem zakresu typu danych,
niewłaściwą wartością parametru lub poleceniem
BREAK wydanym przez operatora.
2005/2006
7
3.Błędy lokalne i wyjątki wykryte przez transakcję.
Przykładem
okoliczności
zmuszających
do
przerwania transakcji jest np. w bankowej bazie
danych,
niewystarczający
stan
konta,
uniemożliwiający wykonanie operacji przelewu
pieniędzy. Transakcja sama powinna obsłużyć
sytuację, wykonując operację ABORT.
4. Awarie dysku.
Błędy zapisu lub odczytu danych z powierzchni
dyskowych podczas wykonywania transakcji.
2005/2006
8
5. Kontrola współbieżności.
Procesy bazy odpowiedzialne za kontrolę dostępu
równoległego mogą zadecydować o konieczności
przerwania transakcji i jej późniejszym restarcie.
Przyczyną może być niespełnienie warunku
szeregowalności czy też wykrycie stanu zakleszczenia.
6. Przyczyny zewnętrzne.
Wynikające z zaniku napięcia, przypadkowego lub
celowego zamazanie danych przez operatora, pożaru,
kradzieży, itp.
2005/2006
9
Strata zapisanej informacji, np. dla transakcji T1 i T2
Ogólnie mówiąc problemy, które mogą
wyniknąć przy jednoczesnym działaniu wielu
transakcji równocześnie, można podzielić na
dwie kategorie:
(1)
T1
W wyniku wykonania takiej
1.
sekwencji operacji, otrzymujemy
2.
niepoprawną końcową wartość
X, tracona jest informacja
zapisana przez transakcję T1
2005/2006
3.
T2
READ(X)
READ(X)
X=X-1
4. WRITE(X)
5.
X=X-2
6.
WRITE(X)
10
Odczytanie niepoprawnej informacji w funkcjach agregujących
(2)
T1
T3
sum=0
READ(A)
sum=sum+A
READ(X)
1.
2.
3.
4.
5. READ(X)
6. X=X-1
7. WRITE(X)
8.
sum=sum+X
9.
READ(Y)
10.
sum=sum+Y
Wartość X odczytana przez
transakcję T3 obliczającą
sumę A+X+Y nie jest
poprawna, gdyż w
„międzyczasie” obliczeń,
transakcja T1 zdążyła ją
zaktualizować.
Widać więc jak istotne jest wprowadzenie mechanizmów
synchronizujących dostęp do bazy danych i rozstrzygających
ewentualne konflikty.
2005/2006
11
Teoria szeregowalności
Ponieważ zawsze jest możliwe, aby transakcje
były wykonywane po kolei (sekwencyjnie), jest
sensownie zakładać, że normalny lub zamierzony
wynik jest taki sam jak wynik otrzymany wtedy,
kiedy nie jest wykonywana współbieżnie żadna
inna transakcja.
Załóżmy więc, że współbieżne wykonanie kilku
transakcji jest poprawne wtedy i tylko wtedy,
gdy jego wynik jest taki sam jak wynik
otrzymany przy sekwencyjnym wykonaniu tych
samych transakcji w pewnej kolejności.
2005/2006
12
Dla potrzeb teorii szeregowalności, wprowadźmy
potrzebne definicje.
Definicja. Kolejność, w której są wykonywane
elementarne operacje transakcji (blokowanie,
odczyt, zapis, itd.) nazywamy harmonogramem
zbioru transakcji.
T1
T2
1. READ(X)
2.
READ(X)
3.
X=X-1
4. WRITE(X)
5.
X=X-2
6.
WRITE(X)
2005/2006
13
Definicja. Harmonogram zbioru transakcji
nazywamy sekwencyjnym (serial) jeśli wszystkie
operacje każdej transakcji występują kolejno po
sobie.
1.
2.
3.
4.
5.
6.
2005/2006
T1
READ(X)
X=X-1
WRITE(X)
T2
READ(X)
X=X-2
WRITE(X)
14
Definicja. Harmonogram zbioru transakcji
nazywamy szeregowalnym (serializable), jeśli jego
wynik jest równoważny wynikowi otrzymanemu
za pomocą pewnego harmonogramu
sekwencyjnego.
Poniższy przykład uwidacznia różnice pomiędzy
harmonogramem sekwencyjnym, szeregowalnym
i nieszeregowalnym.
2005/2006
15
Przykład. Rozważmy dwie transakcje
przeksięgowania kwot pieniężnych z konta na
konto
T1: READ(A); A=A-10; WRITE(A);
READ(B); B=B+10; WRITE(B);
T2: READ(B); B=B-20; WRITE(B);
READ(C); C=C+20; WRITE(C);
2005/2006
16
• Każdy harmonogram sekwencyjny powyższych
transakcji ma własność zachowania sumy
A+B+C.
• Przestawienia kolejności wykonywania
pojedynczych operacji wewnątrz transakcji,
mogą doprowadzić do stworzenia
harmonogramów niesekwencyjnych ale
szeregowalnych (sytuacja pożądana) albo
nieszeregowalnych, (sytuacja niepożądaną).
2005/2006
17
Poniższe przykłady, to:
a) harmonogram sekwencyjny
b) harmonogram szeregowalny, niesekwencyjny
c) harmonogram nieszeregowalny,
dla którego nie istnieje żaden harmonogram
sekwencyjny tego samego zbioru transakcji
dający takie same wyniki.
2005/2006
18
a) harmonogram sekwencyjny
T1
1.
READ(A)
2.
A=A-10
3.
WRITE(A)
4.
READ(B)
5.
B=B+10
6.
WRITE(B)
T2
A=10, B=20, C=30
A=0
A=0, B=30
7.
READ(B)
8.
B=B-20
9.
WRITE(B)
10.
READ(C)
11.
C=C+20
12.
WRITE(C)
2005/2006
A=10, B=20, C=30
A=0, B=10, C=30
A=0, B=10, C=50
19
b) harmonogram szeregowalny, niesekwencyjny
T1
1.
A=A-10
B=B-20
WRITE(A)
6.
7.
A=0
WRITE(B)
B=0
READ(B)
8.
9.
A=10, B=20, C=30
READ(B)
4.
5.
A=10, B=20, C=30
READ(A)
2.
3.
T2
READ(C)
B=B+10
10.
C=C+20
11. WRITE(B)
12.
2005/2006
C=50
B=10
WRITE(C)
A=0, B=10, C=50
20
c) harmonogram nieszeregowalny
T1
1.
READ(A)
2.
A=A-10
3.
4.
B=B-20
B=20
READ(B)
B=0
WRITE(B)
B=B+10
9.
10.
A=10, B=20, C=30
A=0
WRITE(A)
7.
8.
A=10, B=20, C=30
READ(B)
5.
6.
T2
READ(C)
B=30
WRITE(B)
11.
C=C+20
12.
WRITE(C)
2005/2006
C=50
A=0, B=30, C=50
21
Istnieją dwie metody zapewnienia szeregowalności w
współbieżnych procesach realizacji transakcji w bazach
danych.
Pierwsza, to zastosowanie programów szeregujących,
będących częścią systemu zarządzania bazą danych,
odpowiedzialną za rozstrzyganie konfliktów pomiędzy
sprzecznymi żądaniami. Pogramy te mogą eliminować
sytuacje zakleszczenia i nieszeregowalność poprzez
przerwanie wykonania i restart w późniejszym terminie
jednej bądź większej ilości transakcji. Dotychczasowe
efekty działania przerwanych transakcji są wówczas
wymazywane z bazy danych.
2005/2006
22
Drugą metodą jest zastosowanie protokołów, czyli
zbiorów zasad jakie muszą być stosowane przez
wszystkie transakcje.
Zależnie od protokołu, zasady te mają różne cele:
• zapewnić szeregowalnośc transakcji,
• wyeliminować możliwość powstania
zakleszczenia, itp.
2005/2006
23
Odpowiednie narzędzia (menadżery transakcji) bazy
danych muszą zapewnić przestrzeganie protokołu i w
przypadku naruszenia określających go zasad przez
którąkolwiek z transakcji, przerwać jej wykonanie oraz
przywrócić stan bazy sprzed jej startu.
2005/2006
24
Klasyczne metody synchronizacji
podzielić na dwie grupy:
można
optymistyczna - oparta na niezależnym
wykonaniu transakcji i późniejszym
wykrywaniu ewentualnych konfliktów między
poszczególnymi transakcjami.
pesymistyczna - oparta na blokadzie dostępu
do danych,
2005/2006
25
Mechanizm blokad - Blokowanie binarne
Najprostszym rodzajem kontroli współbieżności jest
blokowanie binarne. Polega ono na skojarzeniu z każdym
obiektem bazy znacznika wskazującego na zezwolenie na
dostęp do obiektu lub jego brak. Znacznik taki jest
rekordem postaci
<id obiektu bazy, stan blokady>.
Każda transakcja, chcąca wykorzystać wartość danej X,
musi zawierać w swojej treści polecenia wykonania
operacji LOCK(X) i UNLOCK(X).
2005/2006
26
O tym czy transakcja otrzyma prawo dostępu do
obiektu, decyduje proces systemu zarządzania
bazą danych nazywany menadżerem blokad (lock
manager).
Postępuje on według następującego algorytmu:
2005/2006
27
gdy transakcja żąda dostępu do obiektu X
jeżeli LOCK(X)==0
to LOCK(X)=1
//tzn. obiekt nie jest zablokowany przez inną transakcję
//tzn. zablokuj obiekt w przeciwnym przypadku
czekaj aż LOCK(X)==0
//obiekt zostanie odblokowany oraz
menadżer blokad wznowi wykonywanie transakcji
//transakcja jest ustawiana w kolejce transakcji
//oczekujących na pożądany zasób (dane bazy)
gdy transakcja zwalnia blokadę obiektu X
LOCK(X)=0
//tzn. odblokuj obiekt
jeśli inne transakcje czekają na dostęp do X, wybierz jedną z nich i wznów jej
działanie.
2005/2006
28
Aby zapewnić poprawność procesu blokowania binarnego,
każda transakcja T musi stosować się do poniższych reguł:
1. T musi wykonać operację LOCK(X) przed którąkolwiek z
operacji READ(X) lub WRITE(X)
2. T musi wykonać operację UNLOCK(X) po zakończeniu
wszystkich operacji READ(X) i WRITE(X)
3. T nie może wykonać LOCK(X) jeżeli już posiada blokadę X
4. T nie może wykonać UNLOCK(X) o ile nie wykonała wcześniej
LOCK(X)
2005/2006
29
• Zadanie stosowania reguł 1, 3 i 4 przejmuje na siebie
właściwie funkcjonujący menadżer transakcji,
natomiast reguła 2 musi być przestrzegana przez
programistę aplikacji systemu bazodanowego.
• Efektem niezastosowania reguły 2 będzie niepotrzebne
blokowanie obiektu, uniemożliwiające realizację
wszystkich transakcji chcących z niego skorzystać.
2005/2006
30
Przestrzeganie reguł 1-4 uniemożliwia jednoczesne
użycie tego samego obiektu przez dwie transakcje i
stąd chroni bazę przed utratą spójności danych.
Transakcje wykorzystujące różne obiekty bazy mogą
funkcjonować równolegle i bezkolizyjnie.
Mechanizm blokowania binarnego, opisany powyżej
jest prosty w implementacji. Jednakże konieczność
całkowitego blokowania obiektu nawet gdy
transakcja wymaga jedynie odczytu, może
powodować długie kolejki transakcji oczekujących
na dostęp oraz sprzyja powstaniu zakleszczenia
(opisane w dalszej części).
2005/2006
31
Mechanizm blokad - Blokowanie zapisu i blokowanie aktualizacji
Ulepszeniem powyższej metody jest mechanizm
oddzielnego blokowania zapisu i odczytu.
W metodzie tej możemy wyróżnić dwa rodzaje blokad:
1. blokadę do czytania (READ_LOCK)
żadna transakcja nie może aktualizować obiektu,
który został zamknięty do czytania przez
jakąkolwiek transakcję. Natomiast możliwa jest
sytuacja, że wiele transakcji czyta dane z tego
samego obiektu (dlatego też ten rodzaj nazywany
jest trybem dzielonego dostępu do czytania - readsharable)
2005/2006
32
2. blokadę do aktualizacji (WRITE_LOCK blokada całkowita)
żadna inna transakcja, z wyjątkiem tej, która
nałożyła blokadę nie ma dostępu (zarówno do
czytania jak i aktualizacji) do danego obiektu (tryb
wyłącznego dostępu do pisania - write-exclusive).
2005/2006
33
Zależności pomiędzy poszczególnymi trybami blokowania
możemy przedstawić w tabeli:
T1 ↓
READ_LOCK(X)
WRITE_LOCK(X)
T2→
READ_LOCK(X)
WRITE_LOCK(X)
dozwolony
niedozwolony
niedozwolony
niedozwolony
Jak widać blokada do odczytu (READ_LOCK) przez
jedną transakcję nie wyklucza możliwości zastosowania
takiej samej blokady na tym samym obiekcie przez inną
transakcję.
2005/2006
34
Realizację programową opisanego sposobu blokowania,
możemy zapewnić poprzez wykorzystanie rekordów
postaci
<id obiektu bazy, stan blokady, ilość blokad odczytu>.
Pole stan blokady może przyjmować trzy różne wartości
(odpowiednio zakodowane):
zablokowane_do_odczytu, (WRITE_LOCK)
zablokowane_do_aktualizacji, (READ_LOCK)
niezablokowane.
Obie blokady: zapisu i całkowitą usuwa operacja UNLOCK.
2005/2006
35
Analogicznie jak dla blokowania binarnego, transakcja
musi przestrzegać pewnych reguł:
wykonuje operację WRITE_LOCK lub
READ_LOCK przed jakąkolwiek operacją READ;
wykonuje operację WRITE_LOCK przed
jakąkolwiek operacją WRITE;
nie próbuje odblokować jednostki, której w żaden
sposób nie blokuje;
2005/2006
36
nie próbuje całkowicie zablokować jednostki
(WRITE_LOCK), którą już w ten sposób blokuje;

nie próbuje zablokować do odczytu jednostki
(READ_LOCK), którą blokuje w jakikolwiek
sposób.
2005/2006
37
Protokół dwufazowy i sprawdzanie szeregowalności
Algorytm sprawdzania szeregowalności harmonogramu
S z blokadami:
i

zapisu (READ_LOCK)

całkowitymi (WRITE_LOCK),
opiera się na konstrukcji grafu zorientowanego G, w
którym
wierzchołki
odpowiadają
transakcjom,
a
krawędzie wyznacza się korzystając z następujących
reguł:
2005/2006
38
1. Jeśli transakcja Ti z harmonogramu S blokuje zapis
elementu A {READ_LOCK(A)}, a Tj jest następną
transakcją (o ile taka istnieje), która chce całkowicie
zablokować A {WRITE_LOCK(A)}, to prowadzimy
krawędź Ti Æ Tj.
Ti
Tj
Ti
Tj
...
...
READ_LOCK(A)
...
...
WRITE_LOCK(A)
2005/2006
39
2. Jeśli transakcja Ti z harmonogramu S blokuje
całkowicie A {WRITE_LOCK(A)}, a Tj jest następną
transakcją (o ile taka istnieje), która chce całkowicie
zablokować A {WRITE_LOCK(A)}, to prowadzimy
krawędź Ti Æ Tj.
Ti
Tj
Ti
Tj
...
...
WRITE_LOCK(A)
...
...
WRITE_LOCK(A)
2005/2006
40
3. Jeśli Tm jest transakcją blokującą zapis A
{READ_LOCK(A)}, po tym, gdy Ti zdjęła swoją
całkowitą blokadę {UNLOCK(A)}, lecz zanim Tj
całkowicie zablokowała A {WRITE_LOCK(A)}, (jeśli
Tj nie istnieje, to Tm jest dowolną transakcją
blokującą zapis A po odblokowaniu jej przez Ti), to
prowadzimy krawędź Ti Æ Tm.
Ti
Tm
Ti
Tm
Tj
READ_LOCK(A)
...
WRITE_LOCK(A)
UNLOCK(A)
[ WRITE_LOCK(A) ]
2005/2006
41
Szeregowalność
harmonogramu
rozstrzygamy
sprawdzając istnienie cykli w tak skonstruowanym
grafie (nazywanym również grafem pierwszeństwa). Jeśli
G zawiera cykl, to harmonogram S nie jest
szeregowalny.
Twierdzenie. Przedstawiony algorytm sprawdzania
szeregowalności w poprawny sposób stwierdza
szeregowalność harmonogramu.
Dowód poprawności powyższego algorytmu znajduje się m.in. w książce J.D
Ullman „Systemy baz danych”.
2005/2006
42
W przypadku acyklicznosci (bez cykli) grafu G harmonogramu S,
możemy otrzymać sekwencyjne uporządkowane transakcje
według następującego algorytmu:
1. Wyznaczyć wierzchołek, który nie jest końcem żadnej krawędzi
(w przeciwnym razie graf zawiera cykle) i wyrzucić go z grafu.
2. Czy usuneliśmy wszystkie wierzchołki?
- jeśli nie to wracamy do punktu 1 algorytmu;
- jeśli tak to przechodzimy do punktu 3.
3. Tworzymy ciąg transakcji według kolejności usuwania z grafu.
4. Koniec algorytmu.
2005/2006
43
Przykład. Dany jest graf pewnego harmonogramu dla
transakcji T1, T2, T3, T4, T5:
Z powyższego grafu możemy otrzymać wiele
harmonogramów sekwencyjnych np.:
1.
T5, T3, T2, T4, T1;
2. T5, T4, T1, T3, T2.
2005/2006
44
Przykład. Przykład harmonogramu nieszeregowalnego.
T1
T2
1.
T3
WRITE_LOCK (A)
READ_LOCK (B)
2.
UNLOCK (A)
3.
4.
READ_LOCK (A)
UNLOCK (B)
5.
WRITE_LOCK (B)
6.
READ_LOCK (A)
7.
UNLOCK (B)
8.
9.
WRITE_LOCK (B)
UNLOCK (A)
10.
11.
UNLOCK (A)
WRITE_LOCK (A)
12.
13.
T4
UNLOCK (B)
14.
READ_LOCK (B)
UNLOCK (A)
15.
16.
2005/2006
UNLOCK (B)
45
Graf pierwszeństwa jest postaci:
Ponieważ graf pierwszeństwa zawiera cykle więc nasz
harmonogram jest nieszeregowalny.
2005/2006
46
W przypadku wykrycia cyklu, należy uruchomić
mechanizmy cofające efekt działania transakcji T
powodującej konflikt, zawiadomić o fakcie program
aplikacyjny lub zrestartować T w późniejszym terminie.
Sam mechanizm blokad nie zapewnia szeregowalności
dowolnego harmonogramu wykonania transakcji.
Stąd też nie gwarantuje utrzymania bazy danych w
stanie spójnym.
2005/2006
47
Gwarancję taką daje zastosowanie protokołu dwufazowego,
którego jedynym wymaganiem jest aby transakcje
wykonały blokowania wszystkich wymaganych przez
siebie obiektów przed odblokowaniem któregokolwiek z
nich.
Transakcje, które przestrzegają tego protokołu uważane
są za dwufazowe w takim sensie, że operacje
zablokowania i odblokowania wykonywane są w dwóch
różnych fazach w trakcie działania transakcji.
Jeśli wszystkie transakcje są dwufazowe, ich równoległe
wykonanie zawsze będzie szeregowalne.
2005/2006
48
Prawdziwe jest następujące twierdzenie.
Twierdzenie. Dowolny harmonogram S transakcji
dwufazowych jest harmonogramem szeregowalnym.
Zaletą protokołu dwufazowego jest fakt, iż przy
niewielkich wymaganiach i stosunkowo niewielkim
nakładzie pracy w implementacji, gwarantuje on
szeregowalność harmonogramów transakcji.
Wadą natomiast jest to, że blokowanie dwufazowe może
ograniczyć współbieżność w bazie danych.
2005/2006
49
Często zdarza się, że transakcja T nie może zwolnić blokady na
obiekcie X po jego wykorzystaniu, ponieważ w dalszym planie
swego działania przewiduje blokadę na innym obiekcie Y. Aby
zwolnić obiekt X, transakcja musi zablokować obiekt Y wcześniej
niż jest to wymagane do jej działania. Zablokowanie Y wówczas,
gdy staje się on niezbędny pociąga za sobą konieczność zbędnego
przetrzymania blokady X. W obu przypadkach, obiekt X musi
pozostać zablokowany aż do chwili gdy T uzyska wszystkie
wymagane blokowania. W tym czasie inne transakcje
wymagające dostępu do X są postawione w stan oczekiwania,
pomimo iż transakcja T nie korzysta już z X. Jeśli natomiast Y
zostaje zablokowane „przed czasem”, działanie transakcji
wymagających dostępu do Y jest wstrzymywane, pomimo, że T
nie korzysta jeszcze z obiektu Y.
2005/2006
50
Protokół blokowania dwufazowego zapewnia
szeregowalnośc transakcji, ale nie eliminuje możliwości
wystąpienia sytuacji:
• zakleszczenia (deadlock)
• impasu (livelock),
występujących we wszystkich systemach sterujących
współbieżnością w oparciu o mechanizmy blokowania.
Poniżej przedstawione zostaną przyczyny powstawania
problemu i techniki jego eliminacji
2005/2006
51
Impas
Mówimy, że transakcja jest w stanie impasu, jeśli nie
może kontynuować pracy przez nieokreślenie długi (w
stosunku do innych transakcji) czas, podczas gdy inne
transakcje są realizowane bez przeszkód.
Sytuacja taka może zaistnieć, gdy mechanizm przyznawania
blokad (lock manager) nie jest skonstruowany poprawnie i daje
pierwszeństwo pewnym typom transakcji.
Niestety, praktycznie niemożliwe jest wykrycie impasu w trakcie
wykonywania programu realizującego transakcje. Łatwo co
prawda zaobserwować, że pewna transakcja czeka bardzo długo
na zdarzenie (np. możliwość zablokowania zasobu), które
wystąpiło już wiele razy, ale nie wiadomo, jak system zachowa się
w przyszłości.
2005/2006
52
Impas
Aby uniknąć problemu, należy zastosować maksymalnie
optymalny menadżer blokad.
• Jednym z takich rozwiązań jest zastosowanie techniki
kolejek
FIFO:
pierwszy-wszedł-pierwszy-będzieobsłużony. Obsługuje ona transakcje w kolejności
zgłoszenia potrzeby zablokowania obiektu.
• Innym rozwiązaniem jest dopuszczenie różnych
priorytetów dla różnych transakcji ale równocześnie
wprowadzenie
procesu
podnoszenia
priorytetu
transakcjom
długo
oczekującym na blokadę.
Transakcje te mogą w końcowym stadium osiągnąć
najwyższy priorytet i dzięki temu mają zapewnioną
realizację.
2005/2006
53
Zakleszczenie
Możliwość powstania tego problemu najlepiej ilustruje
poniższa sekwencja działań:
1. Transakcja T1 blokuje całkowicie jednostkę A
2. Transakcja T2 blokuje całkowicie jednostkę B
3. T1 chce nałożyć blokadę do czytania na jednostkę B,
ale musi czekać, bo jest ona zablokowana przez T2
4. T2 chce nałożyć blokadę do czytania na jednostkę A,
ale musi czekać, bo jest ona zablokowana przez T1
2005/2006
54
Zakleszczenie
T1
1
WRITE_LOCK(A)
2
3
WRITE_LOCK(B)
WRITE_LOCK(B)
4
5
T2
WRITE_LOCK(A)
...
...
6
Jak widać z powyższej sytuacji ani transakcja T1 ani
T2 nie mogą być kontynuowane
- występuje zakleszczenie.
2005/2006
55
Zakleszczenie
Można
znaleźć
różne
strategie
zapobiegające
powstawaniu zakleszczeń. Przykładem jest strategia
wstępnego rezerwowania obiektów (pre-claim strategy).
Każda transakcja przed rozpoczęciem działania nakłada
blokady na wszystkie obiekty, z których będzie
korzystać w trakcie swej realizacji.
Taka strategia może jednak powodować, że przy
dużym
stopniu
jednoczesności
dostępu
(rozumianym jako duża liczba transakcji
rywalizujących o zasoby) wiele transakcji będzie
musiało długo czekać na rozpoczęcie swego
działania.
2005/2006
56
Zakleszczenie
Inną wadą tej strategii jest to, że przed
rozpoczęciem realizacji nie zawsze znany jest pełen
zbiór obiektów, do których będzie potrzebny
dostęp. Taki zbiór może być wyznaczany
dynamicznie podczas realizacji transakcji i
generalnie może zależeć od danych wejściowych,
stanu bazy i algorytmu transakcji.
Strategia taka jest więc mało praktyczna w systemach
bazodanowych.
Właściwszą metodą wydaje się dopuszczenie możliwości
powstawania zakleszczeń, ale równocześnie stworzenie
mechanizmów do ich wykrywania i eliminowania.
2005/2006
57
Zakleszczenie
W wykrywaniu zakleszczenia może być pomocne generowanie
grafu bieżących transakcji według następującej reguły:
jeśli T1 żąda blokady jednostki, która jest zablokowana przez T2,
wówczas węzły T1 i T2 łączymy krawędzią.
Sytuacja zakleszczenia odpowiada powstaniu cyklu w grafie.
Ilustruje to poniższy przykład:
T2
T1
1
READ_LOCK(A)
2
...
3
READ_LOCK(B)
4
...
5
WRITE_LOCK(B)
6
WRITE_LOCK(A)
2005/2006
Graf bieżących transakcji
dla T1 i T2
T1 i T2 w stanie zakleszczenia
58
Zakleszczenie
Waiting_tran
Waited_tran
A
B
B
C
B
F
F
G
lista transakcji
oczekujących
G
A
( ten rekord stworzy cykl i wykaże zakleszczenie )
Graf oczekiwań dla powyższych transakcji:
2005/2006
59
Przykład transakcji w Oracle
Przykłady transakcji:
SAVEPOINT t1;
...
UPDATE pensje
SET pensja=pensja*1.2
WHERE pensja<1000;
...
ROLLBACK;
SAVEPOINT t1;
...
UPDATE pensje
SET pensja=pensja*1.2
WHERE pensja<1000;
...
COMMIT;
lub
ROLLBACK t1;
2005/2006
60
Przykład transakcji w Oracle
Transakcje mogą być zagnieżdżone.
SAVEPOINT t1;
...
SAVEPOINT t2;
...
ROLLBACK t2;
...
ROLLBACK t1;
2005/2006
SAVEPOINT t1;
...
SAVEPOINT t2;
...
COMMIT t2;
...
ROLLBACK t1;
61

T - Kolos

Transkrypt

Podobne dokumenty

Magiczne Bloczki - nadwaga_anoreksja

Magiczne Bloczki - Jednostki_dlugosci

Wprowadzenie do programowania w języku Turbo Pascal

SanDisk SSD Extreme 120GB 2.5" Read/Write 550/510 MB/s max

Magiczne bloczki - informatyka

Magiczne Bloczki

Projektowanie stron WWW 1. definicje podstawowe, 2. przegląd

Słownictwo - rozdział 1