Zarz
ą
dzanie transakcjami
Wykład
S. Kozielski
Zarz
ą
dzanie transakcjami
Wykład
S. Kozielski
Zarz
ą
dzanie transakcjami
Transakcja – jedna lub wi
ę
cej operacji na bazie danych
stanowi
ą
cych pewn
ą
logiczn
ą
cało
ść
.
Przykład transakcji: rezerwacja miejsc
R: begin
znajd
ź
wolne miejsce m;
rezerwuj znalezione miejsce dla
pasa
ż
era p
end;
Przykład transakcji: przeniesienie kwoty K z konta X na konto Y
T: begin
read X;
X:=X-K;
write X;
read Y;
Y:=Y+K;
write Y
end;
Po
żą
dane własno
ś
ci transakcji
1. Atomowo
ść
– transakcja musi zosta
ć
wykonana w
cało
ś
ci, albo wszystkie efekty jej cz
ęś
ciowego
wykonania musz
ą
zosta
ć
wycofane
2. Spójno
ść
– transakcja nie mo
ż
e narusza
ć
wi
ę
zów
spójno
ś
ci
3. Izolacja – transakcja musi działa
ć
w pełnej izolacji od
innych transakcji.
4. Trwało
ść
– wynik zako
ń
czonej transakcji nie mo
ż
e
zosta
ć
utracony.
Ś
rodowisko realizacji transakcji
Serwer
SZBD
Aplikacja 1
BD
Aplikacja 2
Aplikacja 3
stacja 1
stacja 2
stacja 3
Zagro
ż
enia dla poprawnej realizacji transakcji
• Współbie
ż
ne wykonywanie wielu transakcji na tych
samych danych
• Zdarzenia losowe: awaria zasilania, awaria systemu
komputerowego (komputer, sie
ć
), uszkodzenie dysku
z baz
ą
danych
• Bł
ę
dy w oprogramowaniu (aplikacje, SZBD) –
„zawieszanie si
ę
” programów
Harmonogram transakcji
Uszeregowanie (kolejno
ść
wykonania)
wszystkich operacji elementarnych
pewnego zbioru transakcji realizowanych
współbie
ż
nie
Problemy ze współbie
ż
nym wykonaniem transakcji
Współbie
ż
ny harmonogram dwóch transakcji rezerwacji miejsc
rezerwuj miejsce m
0
dla pasa
ż
era p2
rezerwuj miejsce m
0
dla pasa
ż
era p1
znajd
ź
wolne miejsce m
0
znajd
ź
wolne miejsce m
0
R2 - rezerwacja biletu 2
R1 - rezerwacja biletu 1
(H1) Harmonogram szeregowy
write C
Σ
0
=6000
Σ
=6000
C:=C+200
read C
C
0
=3000
C=3200
write B
B
0
=2000
B=1900
B:=B-200
A
0
=1000
A=900
read B
write B
B:=B+100
read B
write A
A:=A-100
read A
T2
T1
(H2) Harmonogram szeregowalny
write C
write B
C:=C+200
B:=B+100
read C
read B
write B
write A
B:=B-200
A:=A-100
read B
read A
T2
T1
(H3) Harmonogram nieszeregowalny
write C
C:=C+200
write B
read C
B:=B+100
write B
read B
B:=B-200
write A
read B
A:=A-100
read A
T2
T1
Mechanizm blokowania dost
ę
pu do danych
LOCK <jednostka danych>
UNLOCK <jednostka danych>
Efekty wykonania
LOCK X
1) sukces (uda
ł
o si
ę
nało
ż
y
ć
blokad
ę
) – transakcja uzyskuje
prawo dost
ę
pu do jednostki X,
2) niepowodzenie (nie uda
ł
o si
ę
nało
ż
y
ć
blokady) – brak prawa
dost
ę
pu:
- zawieszenie transakcji
żą
daj
ą
cej,
lub
- kontynuacja transakcji
żą
daj
ą
cej bez prawa dost
ę
pu do X.
Ziarnisto
ść
(granulacja) blokowania
<jednostka danych>:
- wiersz (rekord),
- ca
ł
a tablica,
- cała baza danych
unlock A
B:=B-200
read B
lock C
write B
C:=C+200
unlock B
lock B
lock A
unlock C
write C
read C
B:=B+100
unlock B
write B
Zawieszenie T1’
lock B
read B
write A
A:=A-100
read A
T2’
T1’
U: begin
V: begin
lock Y;
lock X;
read Y;
read X;
unlock Y;
unlock X;
lock X;
lock Y;
read X;
read Y;
X:=X+Y;
Y:=Y+X;
write X;
write Y;
unlock X
unlock Y
end;
end;
X
0
=20, Y
0
=30
H1: U;V: X=50, Y=80
H2: V;U: X=70, Y=50
lock Y
read Y
lock X
read X
unlock X
lock X
lock Y
H3: X=50, Y=50
write X
X:=X+Y
unlock Y
write Y
Y:=Y+X
unlock X
read X
unlock Y
read Y
V
U
Dwufazowy protokół blokowania
Transakcja wypełnia protokó
ł
dwufazowy, je
ś
li wszystkie
operacje blokowania wyst
ę
puj
ą
przed pierwsz
ą
operacj
ą
odblokowania.
Twierdzenie
Dowolny harmonogram transakcji dwufazowych jest
harmonogramem szeregowalnym.
read X
X:=X+Y
read X
lock Y
Y:=Y+X
write Y
unlock Y
unlock Y
lock Y
H4
≡
H1
read Y
unlock X
unlock X
write X
lock X
Zawieszenie transakcji V’
lock X
read Y
V’
U’
Rozwa
ż
my dwie transakcje
T1:
begin A:=A-100; B:=B+100 end;
T2:
begin A:=1.05*A; B:=1.05*B end;
Niech: A
0
=1000, B
0
=1000
Rozwa
ż
my harmonogramy szeregowe:
H1: T1;T2 wtedy warto
ś
ci ko
ń
cowe wynosz
ą
A=945, B=1155
H2: T2;T1 wtedy warto
ś
ci ko
ń
cowe wynosz
ą
A=950, B=1150
W obu przypadkach bank wpłaca klientom sum
ę
odsetek = 100
Rozwa
ż
my harmonogram H3:
T1: A:=A-100
B:=B+100
T2:
A=1.05*A
B=1.05*B
Wynik jest identyczny z H1
Rozwa
ż
my harmonogram H4:
T1: A:=A-100
B:=B+100
T2:
A:=1.05*A B:=1.05*B
wtedy warto
ś
ci ko
ń
cowe wynosz
ą
A = 945, B = 1150
Czyli bank wpłaca klientom sum
ę
odsetek = 95 – bł
ą
d !
Harmonogram H4 mo
ż
e by
ć
zrealizowany, je
ś
li transakcje
T1 i T2 nie wypełniaj
ą
protokołu dwufazowego.
Przy zachowaniu protokołu dwufazowego otrzymamy
harmonogram H5, który jest równowa
ż
ny H3:
unlock B
lock A
read A
Zawieszenie transakcji T2
read B
unlock B
unlock A
read B
write A
lock A
write B
B:= B * 1.05
write B
B:= B + 100
lock B
write A
A:=A * 1.05
unlock A
lock B
A:= A – 100
read A
T2
T1
Blokada wzajemna (zakleszczenie) transakcji
lock Y
Zawieszenie transakcji V’
lock X
lock Y
Blokada wzajemna (zakleszczenie) transakcji
read X
Zawieszenie transakcji U’
lock X
read Y
V’
U’
Unikanie blokady wzajemnej
• Metoda przydziału globalnego
lock X,Y,Z …
• Metoda blokady hierarchicznej
Ustalenie hierarchii zasobów i nakładanie blokad tylko
w kolejno
ś
ci wyznaczonej przez t
ę
hierarchi
ę
Metoda przydziału globalnego
read X
X:=X+Y
read X
Y:=Y+X
write Y
unlock Y
lock X,Y
read Y
unlock X
unlock X
write X
Zawieszenie transakcji V’
unlock Y
lock X,Y
read Y
V
U
Metoda blokady hierarchicznej
read X
X:=X+Y
read X
lock Y
Y:=Y+X
write Y
unlock Y
lock X
lock X
read Y
unlock X
unlock X
write X
Zawieszenie transakcji V’
unlock Y
read Y
lock Y
V
U
Graf oczekiwania
U’
V’
X
Y
Inny model blokowania
RLOCK (read-lock) – blokowanie do odczytu (blokada
współdzielona - shared),
WLOCK (write-lock) – blokowanie do zapisu (blokada
wył
ą
czna - exclusive).
UNLOCK
Wyró
ż
nianie transakcji w programach
1) Domy
ś
lne
⇒
ka
ż
da instrukcja SQL jest transakcj
ą
,
2) Jawne:
[BEGIN TRANSACTION] - pocz
ą
tek,
COMMIT [TRANSACTION]
- koniec –
zatwierdzenie transakcji,
ROLLBACK [TRANSACTION]
- koniec –
wycofanie transakcji.
Prowadzenie dziennika transakcji
Serwer
SZBD
Mened
ż
er Transakcji
Aplikacja 1
BD
Aplikacja 2
Aplikacja 3
stacja 1
stacja 2
stacja 3
Log
dziennik
transakcji
T:
begin
begin transaction;
find X;
if not found then rollback
else
begin
lock X;
get X;
X:=X-K;
write X;
find Y;
if not found then rollback
else
begin
lock Y;
get Y;
Y:=Y+K;
write Y;
commit
end
end
end;
Model dziennika z bezpo
ś
rednim zapisem do bazy danych
<
T
i
, start>
<T
i
, X
adres
, X
stara_warto
ść
, X
nowa_warto
ść
>
<T
i
, Y
adres
, Y
stara_warto
ść
, Y
nowa_warto
ść
>
<T
i
, commit>
Stan dziennika po wycofaniu transakcji
<
T
i
, start>
<T
i
, X
adres
, X
stara_warto
ść
, X
nowa_warto
ść
>
<T
i
, rollback>
Stan dziennika po awarii
<
T
i
, start>
<T
i
, X
adres
, X
stara_warto
ść
, X
nowa_warto
ść
>
Model dziennika z opó
ź
nionym zapisem do bazy danych
<
T
i
, start>
<T
i
, X
adres
, X
nowa_warto
ść
>
<T
i
, Y
adres
, Y
nowa_warto
ść
>
<T
i
, commit>
Rola bufora w procesie dost
ę
pu do bazy danych
Program
BD
Serwer
X
Y
Y
X
Y
X
Bufor
Punkty kontrolne (CHECKPOINT)
Wykonanie przerwania zwi
ą
zanego z punktem kontrolnym:
– doko
ń
czenie aktualnych operacji na bazie danych i/lub logu
– przej
ś
cie do obsługi przerwania
Obsługa przerwania (obsługa punktu kontrolnego):
– zapis zawarto
ś
ci buforów na dysk (do bazy danych)
– wpis do dziennika transakcji (logu) rekordu <CHECKPOINT>
Punkty kontrolne - przykład
Zawarto
ść
logu:
<T1, start>
<T2, start>
<T3, start>
<T2, commit>
<CHECKPOINT>
<T4, start>
<T1, commit>
<T5, start>
<T4, commit>
-----------awaria
Punkty kontrolne - przykład
Zawarto
ść
logu:
<T1, start>
<T2, start>
<T3, start>
<T2, commit>
<CHECKPOINT>
<T4, start>
<T1, commit>
<T5, start>
<T4, commit>
-----------awaria
Transakcje zako
ń
czone (bezpieczne): T2
Transakcje wymagaj
ą
ce wycofania: T3, T5 (UNDO T3, T5)
Transakcje wymagaj
ą
ce powtórzenia: T1, T4 (REDO T1, T4)
Algorytm odtwarzania spójnego stanu b. d. po awarii
1) Wszystkie transakcje wypełnione przed ostatnim punktem
kontrolnym uznawane s
ą
za zako
ń
czone
2) Wszystkie transakcje wypełnione (COMMIT) pomi
ę
dzy
ostatnim punktem kontrolnym a awari
ą
s
ą
powtarzane
(REDO)
3) Wszystkie transakcje wykonywane do momentu awarii
(brak COMMIT) s
ą
wycofywane (UNDO – ROLLBACK)
Wykorzystanie dziennika do ochrony bazy
danych - podsumowanie
1) Wycofanie transakcji z poziomu programu (aplikacji),
(niedost
ę
pno
ść
danych,...)
2) Wycofanie transakcji z poziomu SZBD,
(zakleszczenie transakcji, zawieszenie transakcji, ...)
3) Odtworzenie spójnego stanu b.d. po awarii i upadku
systemu
4) Odtworzenie b.d. i przywrócenie jej spójnego stanu po
zniszczeniu dysku z baz
ą
danych (dziennik ocalał)
BD
Log
BACKUP
BD
Log
BACKUP
RESTORE
BD
Odtworzenie spójnego stanu b.d. po awarii dysku
BD
Log
BACKUP
RESTORE
ROLLFORWARD
BD
Mechanizmy blokad w SQL-u – poziomy izolacji
Generalna zasada:
- zapis (modyfikacja) – wiersz (rekord) blokowany jest
na wył
ą
czno
ść
do ko
ń
ca transakcji,
- odczyt – wybór rodzaju blokady i zakres
utrzymywania zale
ż
y od poziomu izolacji. Poziom
izolacji mo
ż
e ustala
ć
programista:
SET TRANSACTION ISOLATION LEVEL <poziom
izolacji>
Poziomy izolacji
SERIALIZABLE
fantom
REPEATABLE READ
niepowtarzalny odczyt
READ COMMITTED
brudny odczyt
READ UNCOMMITTED
Efekt niepo
żą
dany
Poziom izolacji
Brudny odczyt:
T1:
R(A), W(A),
R(B), W(B), Abort
T2:
R(A), W(A), C
T1:
R(A),
R(A), W(A), C
T2:
R(A), W(A), C
Niepowtarzalny odczyt:
Kiedy s
ą
mo
ż
liwe takie sytuacje?
Blokada na A jest zdejmowana zaraz po W(A)
(lub R(A) dla niepowtarzalnego odczytu)
– nie jest utrzymywana do ko
ń
ca transakcji
Tryb dost
ę
pu
Jest ustawiany instrukcj
ą
SET TRANSACTION
Przyjmuje 2 warto
ś
ci:
READ ONLY
READ WRITE
(domy
ś
lna)
Zazwyczaj przyj
ę
cie poziomu izolacji
READ UNCOMMITTED
wymusza tryb dost
ę
pu
READ ONLY
