partition manager

Transkrypt

partition manager

PODSTAWY
BAZ DANYCH
11. Transakcje
2009/2010 - Notatki do wykładu "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)
2
Zbiór cech transakcji - Niepodzielność
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.
3
Zbiór cech transakcji – Spójność stanu - Trwałość
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.
Trwałość (Durability)
Niedokończenie transakcji spowodowane błędami środowiska
systemowego nie może doprowadzić do uszkodzenia żadnej z baz.
4
Zbiór cech transakcji – Wyłączność - Szeregowalność
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).
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.
5
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.
3. Awarie dysku.
Błędy zapisu lub odczytu danych z powierzchni dyskowych
podczas wykonywania transakcji.
4. Przyczyny zewnętrzne.
Wynikające z zaniku napięcia, przypadkowego lub celowego
zamazanie danych przez operatora, pożaru, kradzieży, itp.
6
Przyczyny powodujące załamanie procesu wykonania transakcji
5. 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.
6. 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
7
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)
W
wyniku
wykonania
T1
T2
takiej
1.
sekwencji operacji, otrzymujemy
2.
niepoprawną końcową wartość X,
3.
tracona jest informacja zapisana
4. WRITE(X)
przez transakcję T1
5.
X=X-2
6.
WRITE(X)
READ(X)
READ(X)
X=X-1
8
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” tych 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 w jakiś sposób
rozstrzygających ewentualne konflikty.
9
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.
10
Dla potrzeb teorii szeregowalności, wprowadźmy pewne 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)
11
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.
T1
READ(X)
X=X-1
WRITE(X)
T2
READ(X)
X=X-2
WRITE(X)
Definicja.
Harmonogram
zbioru
transakcji
nazywamy
szeregowalnym (serializable), jeśli jego wynik jest równoważny
wynikowi otrzymanemu za pomocą pewnego harmonogramu
sekwencyjnego.
12
Poniższy przykład uwidacznia różnice pomiędzy harmonogramem
sekwencyjnym, szeregowalnym i nieszeregowalnym.
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);
13
• 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ą).
14
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.
15
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=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)
A=0, B=10, C=30
A=0, B=10, C=50
16
b) harmonogram szeregowalny, niesekwencyjny
T1
1.
A=A-10
B=B-20
WRITE(A)
6.
7.
A=0
WRITE(B)
READ(C)
B=B+10
10.
C=C+20
11. WRITE(B)
12.
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
C=50
B=10
WRITE(C)
A=0, B=10, C=50
17
c) harmonogram nieszeregowalny
T1
1.
READ(A)
2.
A=A-10
3.
4.
WRITE(A)
A=0
READ(B)
B=20
WRITE(B)
B=0
B=B+10
9.
10.
A=10, B=20, C=30
B=B-20
7.
8.
A=10, B=20, C=30
READ(B)
5.
6.
T2
READ(C)
WRITE(B)
B=30
11.
C=C+20
12.
WRITE(C)
C=50
A=0, B=30, C=50
18
Istnieją
dwie
metody
zapewnienia
szeregowalności
we
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, odpowiedzialnych 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.
19
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.
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.
20
Klasyczne metody synchronizacji można podzielić na dwie grupy:
 optymistyczna - oparta na niezależnym wykonaniu
transakcji i późniejszym wykrywaniu ewentualnych
konfliktów między poszczególnymi transakcjami
(trudna w realizacji)
 pesymistyczna - oparta na blokadzie dostępu do
danych uniemożliwiając dokonywania zmian na
pewnych danych.
21
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 może być rekordem postaci
<id obiektu bazy, stan blokady>.
Rekordy te mogą być na przykład przechowywane w pewnych
tabelach np. gdy blokowanie jest na poziomie wiersza może to być
tabela:
ROWID
Stan_blokady
AAAQ2UAAEAAABYGAAA
LOCK
...
...
22
Każda transakcja, chcąca wykorzystać wartość danej X, musi
zawierać w swojej treści polecenia wykonania operacji LOCK(X) i
UNLOCK(X).
O tym czy transakcja otrzyma prawo dostępu do obiektu,
decyduje proces systemu zarządzania bazą danych nazywany
menadżerem blokad (lock manager).
Może on postępować według następującego algorytmu:
23

gdy transakcja żąda dostępu do obiektu X
jeżeli LOCK(X)= =0
//tzn. obiekt nie jest zablokowany przez inną transakcję
to LOCK(X)=1
//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.
24
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ć operacji LOCK(X) jeżeli już posiada
blokadę X
4. T nie może wykonać UNLOCK(X) o ile nie wykonała
wcześniej operacji LOCK(X)
25
Uwagi.
• 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ć.
26
Uwagi.
 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).
27
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 zapisu (READ_LOCK)
 żadna transakcja nie może aktualizować obiektu, który
został zamknięty tą blokadą przez jakąkolwiek inną
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
- read-sharable)
28
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).
Zależności pomiędzy poszczególnymi trybami blokowania przez
transakcje T1 i T2 możemy przedstawić w tabeli:
T1 
T2
READ_LOCK(X)
WRITE_LOCK(X)
READ_LOCK(X)
WRITE_LOCK(X)
dozwolony
niedozwolony
niedozwolony
niedozwolony
Jak widać blokada zapisu (READ_LOCK) przez jedną transakcję
nie wyklucza możliwości zastosowania takiej samej blokady na
tym samym obiekcie przez inną transakcję.
29
Realizację programową opisanego sposobu blokowania, możemy
zapewnić poprzez wykorzystanie rekordów postaci
<id obiektu, stan blokady, ilość blokad READ_LOCK >.
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.
30
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;
• nie próbuje całkowicie zablokować jednostki (WRITE_LOCK),
którą już w ten sposób blokuje;
• nie próbuje zablokować do zapisu jednostki (READ_LOCK),
którą blokuje w jakikolwiek sposób.
31
Protokół dwufazowy i sprawdzanie szeregowalności
Algorytm sprawdzania szeregowalności harmonogramu S z
blokadami:

zapisu (READ_LOCK)

całkowitymi (WRITE_LOCK),
i
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ł:
32
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)
33
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)
34
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
Ti
Tm
Tm
Tj
READ_LOCK(A)
...
WRITE_LOCK(A)
UNLOCK(A)
[ WRITE_LOCK(A) ]
35
Szeregowalność
danego
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”.
36
Przykład. Przykład harmonogramu nieszeregowalnego.
T1
T2
1.
T3
READ_LOCK (B)
3.
UNLOCK (A)
UNLOCK (B)
6.
WRITE_LOCK (B)
7.
UNLOCK (B)
WRITE_LOCK (B)
10.
UNLOCK (A)
UNLOCK (A)
12.
13.
14.
WRITE_LOCK (A)
UNLOCK (B)
READ_LOCK (B)
15.
16.
(W_L)
U -> R
(W_L)
READ_LOCK (A)
8.
11.
W -> W
READ_LOCK (A)
5.
9.
R -> W
WRITE_LOCK (A)
2.
4.
T4
UNLOCK (A)
UNLOCK (B)
37
Graf pierwszeństwa jest postaci:
T1
T2
T4
T3
Ponieważ graf pierwszeństwa dla naszego harmonogramu zawiera
cykle więc nasz harmonogram nie jest szeregowalny.
38
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.
T1
T2
T1
T2
T4
T3
T4
T3
Po wycofaniu T4 będzie szeregowalny.
Po wycofaniu T2 nie będzie szeregowalny.
39
Uwaga. Jak widać z poprzedniego przykładu sam mechanizm
blokad nie zapewnia szeregowalności dowolnego harmonogramu
wykonania transakcji.
Stąd też nie gwarantuje utrzymania bazy danych w stanie spójnym.
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.
40
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.
41
Pewne przypadki ograniczające współbieżność:
• 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.
42
• 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.
43
Protokół blokowania dwufazowego zapewnia szeregowalność
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.
44
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 danego 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.
45
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ędzie obsłużony.
Obsługuje ona transakcje w kolejności zgłoszenia potrzeby
zablokowania .
•
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ę.
46
Zakleszczenie
Możliwość powstania tego problemu tzn. zakleszczenia 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ć całkowitą blokadę na jednostkę B, ale
musi czekać, bo jest ona zablokowana przez T2
4. T2 chce nałożyć całkowitą blokadę na jednostkę A, ale
musi czekać, bo jest ona zablokowana przez T1
47
Zakleszczenie
T2
T1
1
WRITE_LOCK(A)
2
3
WRITE_LOCK(B)
WRITE_LOCK(B)
4
5
WRITE_LOCK(A)
...
...
6
Jak widać z powyższej sytuacji ani transakcja T1 ani T2 nie
mogą być kontynuowane
- występuje zakleszczenie.
48
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.
49
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
dopuszczenie
możliwości
równocześnie
stworzenie
bazodanowych.
Właściwszą
powstawania
metodą
wydaje
zakleszczeń,
się
ale
mechanizmów do ich wykrywania i eliminowania.
50
Zakleszczenie
W wykrywaniu zakleszczenia może być pomocne generowanie
grafu bieżących transakcji według następującej reguły:
jeśli transakcja T1 żąda blokady jednostki, która jest
zablokowana przez transakcję T2, wówczas węzły T1 i T2
łączymy krawędzią.
Przykład.
T1
1
WRITE_LOCK(A)
2
...
T2
3
WRITE_LOCK(B)
4
...
5
6
WRITE_LOCK(B)
WRITE_LOCK(A)
Graf bieżących transakcji
dla T1 i T2
T1 i T2 w stanie
zakleszczenia
51
Zakleszczenie
Waiting_tran
(czekająca)
A
Waited_tran
B
B
C
B
F
F
G
lista transakcji
oczekujących
G
A
( ten rekord stworzy cykl i wykaże zakleszczenie )
Graf bieżących transakcji dla powyższych transakcji:
52
Przykład transakcji w Oracle
Przykłady transakcji w Oracle:
SET TRANSACTION NAME ’t1’;
. . .
UPDATE zatrudnienia
SET pensja=pensja*1.2
WHERE pensja<1000;
. . .
ROLLBACK;
lub
COMMIT;
53
Przykład transakcji w Oracle
Przykłady transakcji w Oracle:
SAVEPOINT t1;
. . .
UPDATE zatrudnienia
SETpensja=pensja*2
WHERE pensja<1000;
. . .
ROLLBACK;
SAVEPOINT t1;
. . .
UPDATE zatrudnienia
SET pensja=pensja*2
WHERE pensja<1000;
. . .
COMMIT;
lub
ROLLBACK TO SAVEPOINT t1;
54
PODSTAWY
BAZ DANYCH
12. Współbieżność w systemie Oracle
55
Współbieżność w systemie Oracle - Wstęp
Wszystkie operacje wykonywane w Oracle odbywają się w trybie
transakcyjnym.
Z transakcjami wiąże się ściśle zjawisko blokowania danych.
Blokowanie danych ma na celu zapewnienie synchronizacji
zapisów.
Polecenia z grupy DDL (np. Create, Alter, Drop Table) oraz
polecenia z grupy DCL (Grant, Revoke) kończą się niejawnym
zatwierdzeniem transakcji.
56
Współbieżność w Oracle – Tryby w jakich może pracować transakcja
Transakcja może być realizowana w jednym z trzech trybów:
•
Tryb READ COMMITTED. (domyślny)
•
Tryb READ ONLY.
•
Tryb SERIALIZABLE.
Do ustawiania trybu pracy transakcji służy polecenie:
SET TRANSACTION
{ READ ONLY
| ISOLATION LEVEL
{ SERIALIZABLE | READ COMMITTED }
nazwa_transakcji;
57
Współbieżność w Oracle – Tryb READ COMMITED
Tryb READ COMMITTED
• Wszystkie transakcje w Systemie Oracle wykonywane są
domyślnie w tym trybie.
• Transakcja T1 widzi dane zmodyfikowane przez transakcję T2
dopiero po jej zatwierdzeniu poleceniem COMMIT.
Polecenie umożliwiające przestawienie pojedynczej transakcji w
tryb Read Commited:
SET TRANSACTION ISOLATION LEVEL Read Committed;
58
Współbieżność w Oracle – Tryb READ COMMITED
Uwaga. Polecenie należy wykonać jako pierwsze w ramach
transakcji:
SET TRANSACTION ISOLATION LEVEL Read Committed;
. . .
COMMIT;
Polecenie umożliwiające ustawienie trybu Read Committed dla
wszystkich transakcji realizowanych w ramach danej sesji:
ALTER SESSION
SET ISOLATION_LEVEL = Read Committed;
59
Współbieżność w Oracle – Tryb READ ONLY
Tryb READ ONLY
• Transakcja T1 operuje na wersji danych z momentu jej
rozpoczęcia.
• Transakcja w tym trybie nie może modyfikować danych.
• Nie widzi zmian wprowadzonych w między czasie przez
inne, zatwierdzone transakcje.
Tryb Read Only stosowany jest w przypadku obliczeń
analitycznych.
60
Współbieżność w Oracle – Tryb READ ONLY
tryb Read Only:
SET TRANSACTION Read Only;
transakcji:
SET TRANSACTION Read Only;
. . .
COMMIT;
61
Współbieżność w Oracle – Tryb Serializable
Tryb SERIALIZABLE
• Transakcja w trybie Serializable, podobnie jak transakcja w
trybie Read Only, operuje na wersji danych z momentu jej
rozpoczęcia.
•
Różnica polega na tym, że można modyfikować dane, które nie
zostały zmienione przez inne transakcje w trakcie jej trwania.
tryb Serializable:
SET TRANSACTION ISOLATION LEVEL Serializable;
transakcji.
62
Współbieżność w Oracle – Mechanizm blokowania danych
Mechanizm blokowania danych.
Blokady zakładane są na czas trwania transakcji.
Dwie blokady są ze sobą zgodne jeżeli mogą być założone
na tę samą daną przez wiele transakcji.
Blokowanie może dotyczyć:
• tabeli (table lock),
• rekordu (row lock).
Blokowanie całej tabeli zmniejsza stopień współbieżności.
Blokowanie całej tabeli powoduje, że blokada dotyczy wszystkich
jej rekordów a co za tym idzie system nie musi blokować każdego
z nich oddzielnie.
63
Operacja SELECT nie wymaga nakładania blokady na tabeli i
rekordzie.
Blokowanie rekordów odbywa się zawsze w trybie EXCLUSIVE.
Blokowanie tabeli odbywa się w trybie RS, RX, S, SRX oraz X
gdzie:
RS
ROW SHARE
RX
S
SRX
X
ROW EXCLUSIVE
SHARE
SHARE ROW EXCLUSIVE
EXCLUSIVE
64
Zgodność blokad tabeli:
Brak
RS
RX
S
SRX
X
Brak
TAK
TAK
TAK
TAK
TAK
TAK
RS
TAK
TAK
TAK
TAK
TAK
Nie
RX
TAK
TAK
TAK
Nie
Nie
Nie
S
TAK
TAK
Nie
TAK
Nie
Nie
SRX
TAK
TAK
Nie
Nie
Nie
Nie
X
TAK
Nie
Nie
Nie
Nie
Nie
Blokady mogą być nałożone w następujący sposób:
• niejawny - w momencie wykonywania operacji
modyfikujących dane,
• jawny – nałożenie blokady następuje po wydaniu polecenia
LOCK TABLE.
65
Do jawnego założenia blokady na tabeli służy polecenie:
LOCK TABLE
{ table | view } [ PARTITION ( partition ) ]
[, { table | view } [ { PARTITION ( partition ) ]
...
IN tryb_blokady MODE [ NOWAIT ];
gdzie tryb_blokady jest identyfikatorem jednego z dostępnych
trybów blokowania podany pełną nazwą.
66
Współbieżność w Oracle – Właściwości blokad – ROW SHARE
WŁAŚCIWOŚCI BLOKADY RS (ROW SHARE)
Pozwala na współbieżny dostęp ( SELECT, UPDATE, DELETE,
INSERT) do zablokowanej tabeli, ale nie pozwala jej zablokować
innym użytkownikom w trybie EXCLUSIVE (wyłącznym)
LOCK TABLE osoby IN ROW SHARE MODE;
Jej założenie następuje automatycznie przy realizacji polecenia:
SELECT lista_atrybutów FROM nazwa_tabeli
WHERE warunek_selekcji FOR UPDATE [NOWAIT];
Użycie NOWAIT powoduje, że polecenie zostanie automatycznie
przerwane, jeżeli nie można założyć blokady RS ze względu na
istnienie innej blokady z nią niezgodnej.
67
Współbieżność w Oracle – Właściwości blokad – ROW EXCLUSIVE
WŁAŚCIWOŚCI BLOKADY RX (ROW EXCLUSIVE)
Tak jak, powyżej, ale dodatkowo nie pozwala zablokować innym
w trybie SHARE.
LOCK TABLE osoby IN ROW EXCLUSIVE MODE;
Blokada ROW EXCLUSIVE pojawia się automatycznie przy
UPDATE, INSERT i DELETE.
Modyfikowane rekordy są zawsze blokowane w trybie
EXCLUSIVE (X).
Pojawienie się blokady tego typu oznacza, że niektóre lub
wszystkie rekordy tabeli zostały zmodyfikowane.
68
Współbieżność w Oracle – Właściwości blokad – ROW SHARE
WŁAŚCIWOŚCI BLOKADY S (SHARE)
Zakładana jest gdy transakcja T1 chce uniemożliwić zmianę danych
w tabeli przez inne równolegle działające transakcje i jednocześnie
sama nie będzie ich modyfikowała.
Pozwala na współbieżne zapytania, ale zabrania operacji UPDATE
na zablokowanej tabeli.
LOCK TABLE osoby IN SHARE MODE;
Transakcje nie zmieniające zawartości tabeli mogą współpracować
z transakcją T1.
69
Współbieżność w Oracle – Właściwości blokad – SHARE ROW EXCLUSIVE
WŁAŚCIWOŚCI BLOKADY SRX (SHARE ROW EXCLUSIVE)
Pozwala wszystkim widzieć całą tabelę, ale zabrania zarówno
operacji UPDATE jak i zablokowania jej w trybie SHARE.
LOCK TABLE osoby IN SHARE ROW EXCLUSIVE MODE;
70
Współbieżność w Oracle – Właściwości blokad – EXCLUSIVE
WŁAŚCIWOŚCI BLOKADY X (EXCLUSIVE)
Uniemożliwia innym transakcjom modyfikowanie danych
dopuszczając tylko ich przeglądanie.
Założenie innej blokady nie jest możliwe.
LOCK TABLE osoby IN EXCLUSIVE MODE;
Gdy zastosowano opcje NOWAIT Oracle zwraca sterowanie
natychmiast, jeśli podana do zablokowania tabela jest już
zablokowana przez innego użytkownika (podaje odpowiedni
komunikat).
Bez tego słowa Oracle będzie czekał, aż będzie można założyć
pożądaną blokadę.
71
Współbieżność w Oracle – Właściwości blokad – EXCLUSIVE
Przykład. Transakcja z blokowaniem.
LOCK TABLE zatrudnienia IN EXCLUSIVE MODE;
UPDATE zatrudnienia
SET pensja=pensja*1.2
WHERE pensja<1000;
ROLLBACK;
/*tabela zatrudnienia zostaje zwolniona */
Punkt zachowania został utworzony.
Tabela(e) zablokowana(e).
2 wierszy zostało zmodyfikowanych.
Wycofywanie zostało zakończone.
72
Współbieżność w Oracle – Właściwości blokad – Uwagi
Uwagi.
1. W przypadku blokowania perspektywy (view) Oracle
zablokuje bazowe tabele widoku.
2. W przypadku partycji Oracle najpierw niejawnie uzyska
blokadę na całej tabeli. Będzie ona tego samego trybu co
wyszczególniona blokada dla partycji.
LOCK TABLE faktury PARTITION(m_10_2003)
IN SHARE MODE;
73
Współbieżność w Oracle - Zakleszczenie
Zakleszczenia (deadlocks)
Zaletą metody blokowania danych jest zapewnienie synchronizacji
zapisu w przypadku wielu transakcji próbujących modyfikować te
same dane.
Metoda ta posiada jednak dwie wady:
• zmniejsza stopień współbieżności (transakcja, która próbuje
założyć blokady niezgodne z blokadami już założonymi przez
inną transakcję, musi czekać na zdjęcie blokad);
• wprowadza możliwość wystąpienia zakleszczenia (deadlock),
kiedy dwie transakcje blokują sobie wzajemnie zasoby.
Wówczas żadna z transakcji nie może kontynuować pracy.
74
System Oracle wykrywa zakleszczenie i rozwiązuje je
wykorzystując pewien algorytm wyboru tej transakcji, która
zostanie przerwana, tj. jej ostatnie polecenie zostanie przerwane,
wycofane.
Przykład. Przykład wystąpienia zakleszczenia.
Pierwsza sesja:
1. SET TRANSACTION NAME 't1';
3. SELECT * FROM osoby FOR UPDATE;
5. SELECT * FROM zatrudnienia FOR UPDATE;
Druga sesja:
2. SET TRANSACTION NAME 't2';
4. SELECT * FROM zatrudnienia FOR UPDATE;
6. SELECT * FROM osoby FOR UPDATE;
75
Właściciel transakcji, dla której nastąpiło zakleszczenie otrzymuje
wówczas komunikat:
ORA-…….: deadlock detected while waiting for resource
Algorytm wyboru transakcji do przerwania nie został
wyspecyfikowany w dokumentacji Oracle.
76

partition manager

Transkrypt

Podobne dokumenty

Magiczne Bloczki

Praktyki w firmie Trilogik

Karta zgłoszeniowa na wykład/ warsztaty organizowane przez

Wykaz zbiorów danych osobowych / baz danych, w których

Magiczne Bloczki

Magiczne Bloczki - nadwaga_anoreksja

Magiczne Bloczki - Jednostki_dlugosci

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

Wprowadzenie do programowania w języku Turbo Pascal