Transakcje

Transkrypt

Transakcje

Transakcje i ich właściwości
¾ W SZBD stosuje się pojęcie transakcji jako jednostki
operowania na bazie danych podlegającej sterowaniu i
kontroli.
Transakcje
¾ Celem systemu zarządzania transakcjami jest takie
sterowanie operacjami w bazie danych, aby były one
wykonywane z możliwie wysokim współczynnikiem
współbieżności i aby przeciwdziałać naruszeniu spójności
bazy danych.
¾ Cele zarządzania transakcjami zostały osiągnięte za
pomocą odpowiednich protokołów zarządzania
transakcjami.
Tadeusz Pankowski
www.put.poznan.pl/~tadeusz.pankowski
(c) T. Pankowski, Transakcje
1
create procedure UMNIEJSZ_PKO
@nrrach char(5),
@kwota money
as
begin
declare @stan int
if not exists(select * from PKO
where NrRach = @nrrach)
return -1
else
update PKO set Saldo = Saldo - @kwota
where NrRach = @nrrach
return @@error
end
Transakcje i ich właściwości
¾ Transakcją T nazywamy ciąg następujących operacji na wspólnej
bazie danych:
• rT[x] – czytanie (read) danej x przez transakcję T,
• wT[x] – zapisanie (write) (aktualizacja) danej x przez
transakcję T,
– odrzucenie (abort, rollback) (wycofanie) transakcji
• aT
T,
• cT
– zatwierdzenie (commit) transakcji T.
¾ Mówiąc o danej x mamy na myśli jednostki danych na różnych
poziomach granulacji – może to być dana elementarna, krotka
(rekord), zbiór krotek wyznaczony przez warunek ϕ, tabela bazy
danych, itp.
create trigger IC_PKO
on PKO
for UPDATE
as
begin
declare @saldo money
select @saldo = PKO.Saldo
from PKO, deleted d
where PKO.NrRach = d.NrRach
if @saldo < 0
rollback
end
3
Definiowanie transakcji - przykł
przykład
create procedure POWIEKSZ_WBK
@nrrach char(5),
@kwota money
as
begin
declare @stan int
if not exists(select * from WBK
where NrRach = @nrrach)
return -1
else
update WBK set Saldo = Saldo + @kwota
where NrRach = @nrrach
return @@error
end
2
Transakcja – przykład (c.d.)
Definiowanie transakcji – przykład (c.d.)
create procedure PRZELEW_PKO_WBK
@zrach char(5),
@narach char(5),
@kwota money
as
begin
declare @stan int
begin transaction
exec @stan = UMNIEJSZ_PKO @zrach, @kwota
if @stan = 0
exec @stan = POWIEKSZ_WBK @narach, @kwota
if @stan = 0
begin
commit
return
end
rollback
end
@zrach char(5),
@narach char(5),
@kwota money
as
begin
declare @stan int
begin transaction
if @stan = 0
if @stan = 0
begin
commit
return
end
rollback
end
5
@zrach char(5),
@narach char(5),
T: exec PRZELEW_PKO_WBK '11-12', '22-22',100
@kwota money
as
rT[’11-12’], aT
begin
declare @stan int
begin transaction
if @stan = 0
if @stan = 0
begin
commit
return
end
rollback
end
7
T: exec PRZELEW_PKO_WBK '11-11', '22-22', 100
rT[’11-11’], wT[11-11’], rT[’22-22’], wT[’22-22’], cT
6
@zrach char(5),
@narach char(5),
@kwota money
as
rT[’11-11’], wT[’11-11’], aT
begin
declare @stan int
begin transaction
if @stan = 0
if @stan = 0
begin
commit
return
end
rollback
end
8
Przykład - podsumowanie
¾ Każde wykonywanie programu
PRZELEW_PKO_WBK
powoduje utworzenie nowej transakcji. Przykłady takich transakcji:
@zrach char(5),
@narach char(5),
@kwota money
as
rT[’11-11’], wT[’11-11’], rT[’22-23’], aT
begin
declare @stan int
begin transaction
if @stan = 0
if @stan = 0
begin
commit
return
end
rollback
end
9
Właściwości ACID
rT[’11-11’],
rT[’11-12’],
rT[’11-11’],
rT[’11-11’],
wT[’11-11’], rT[’22-22’], wT[’22-22’], cT
aT
wT[’11-11’], aT
wT[’11-11’], rT[’22-23’], aT
¾ W ogólności w systemie, w którym istnieje wiele stanowisk
komputerowych może być tworzonym bardzo wiele transakcji, z
których duża liczba może być współbieżnych.
¾ Współbieżność transakcji oznacza, że przed zakończeniem jednej
transakcji rozpoczynana jest następna (inicjowana na przykład z
innego stanowiska komputerowego).
¾ W stosowanym zapisie transakcji abstrahujemy zarówno od
konkretnych wartości, jak i od operacji wykonywanych poza bazą
danych (operacje w pamięci operacyjnej, obszarze roboczym,
interakcja z użytkownikiem lub z innymi systemami).
10
Właściwości ACID (c.d.)
¾ Przyjmuje się, że transakcje i protokoły zarządzania transakcjami
muszą posiadać właściwość ACID wyrażoną przez następujące
cztery postulaty:
Atomowość (atomicity) – każda transakcja stanowi pojedynczą i
niepodzielną jednostkę przetwarzania (a także odtwarzania) – w transakcji
nie ma więc podtransakcji. Każda transakcja jest bądź wykonana w całości,
bądź też żaden jej efekt nie jest widoczny w bazie danych.
Spójność (consistency) – transakcja rozpoczynając się w spójnym stanie
bazy danych pozostawia bazę danych w stanie spójnym (tym samym lub
innym). Jeśli transakcja narusza warunki spójności bazy danych, to zostaje
odrzucona.
Odizolowanie (isolation) – zmiany wykonywane przez transakcję nie
zatwierdzoną nie są widziane przez inne transakcje (chyba, że przyjęty
¾ W w niektórych koncepcjach systemów zarządzania bazami danych
(systemy obiektowe, systemy wspomagające pracę grupową,
systemy kooperacyjne), postulaty ACID są modyfikowane. Na
przykład w przypadku tzw. transakcji długotrwałych wprowadza się
pojęcie podtransakcji i transakcji zagnieżdżonych.
¾ Uwaga: pojęcie podtransakcji istnieje również w Transact-SQL,
jednak ich rozumienie jest inne niż w przypadku transakcji
wspomnianych powyżej transakcji zagnieżdżonych.
¾ Postulat odizolowania transakcji jest najczęściej osłabiany przez
jawne określanie poziomu izolacji. Celem obniżenia poziomu izolacji
jest zwiększenie współbieżności transakcji, wiąże się to jednak z
ryzykiem powstawania pewnych anomalii (patrz dalej).
poziom izolacji na to zezwala).
Trwałość (duration) – zmiany w bazie danych dokonane przez transakcję
zatwierdzoną są trwałe w bazie danych, tzn. nawet w przypadku awarii
systemu musi istnieć możliwość ich odtworzenia.
11
12
Właściwości ACID - przykład
¾ Atomowość oznacza, że transakcję
Ti = (ri[Konto1], wi[Konto1], ri[Konto2], wi[Konto2], ci),
musimy traktować jako niepodzielną całość. Nie można więc
przyjąć, że na przykład system utrwala wykonanie w bazie danych
dwóch pierwszych operacji zakładając, że po jakimś czasie
zrealizuje dwie następne operacje. Byłaby to koncepcja wyróżniania
podtransakcji, co w tradycyjnych systemach baz danych jest
niedopuszczalne. Jeśli więc z jakiegoś powodu wykonanie transakcji
ulegnie przerwaniu (na przykład w wyniku awarii) po dwóch
pierwszych operacjach, to system musi zapewnić wycofanie
dokonanych zmian.
13
14
¾ Odizolowanie oznacza, że zmiany wykonane przez jedną
transakcję nie są widoczne dla innych transakcji dopóty, dopóki
transakcja ta nie zostanie zatwierdzona.
¾ Rozważmy jednak następujący ciąg operacji:
r1[Konto1], w1[Konto1], r1[Konto2], r2[Konto2], c2, w1[Konto2], c1,
gdzie T1 jest transakcją przelewu, a T2 odczytuje stan konta
Konto2, zanim jeszcze transakcja zmieniająca ten stan została
zatwierdzona. Naruszony jest więc rygorystyczny warunek
odizolowania.
¾ Często jednak sytuacja taka jest dopuszczalna (zwłaszcza wtedy
gdy odczytana wartość nie będzie wykorzystana do aktualizacji
bazy danych).
¾ Spójność oznacza, że system nie dopuści do zatwierdzenia
transakcji, która naruszy jakikolwiek warunek spójności bazy
danych.
¾ W rozważanym przypadku warunkiem spójności może być
wymaganie, aby stan rachunku bankowego był zawsze większy
od zera (statyczny warunek spójności) lub aby suma stanów kont
po wykonaniu transakcji była taka sama jak przed jej wykonaniem
(dynamiczny warunek spójności, tzn. odwołujący się do kilku
różnych stanów bazy danych).
¾ Trwałość oznacza, że zmiany wprowadzone do bazy danych przez
transakcję, która została zatwierdzona są w tej bazie danych
trwałe.
¾ Oznacza to, że również w przypadku różnorodnych awarii (z
wyłączeniem fizycznego zniszczenia nośnika danych) musi istnieć
mechanizm ich odtwarzania. Automatycznie jest wówczas
odtwarzany ostatni poprawny (spójny) stan bazy danych.
¾ Tak rozumianego odtwarzania nie należy mylić z odtwarzaniem
bazy danych z archiwum.
15
16
Historie przetwarzania transakcji
Historie przetwarzania transakcji
¾ Z punktu widzenia analizy poprawności protokołów (algorytmów)
zarządzania transakcjami istotne jest analizowanie historii
przetwarzania transakcji. Historia taka znana jest oczywiście dopiero
po wykonaniu danego zbioru transakcji.
¾ W analizie poprawności historii przetwarzania chodzi o sformułowanie
wymagań dotyczących cech, jakie powinny posiadać historie
dopuszczalne generowane przez protokoły.
¾ Jeśli jesteśmy w stanie stwierdzić, że stosując określony protokół
zawsze otrzymamy przetwarzanie, którego historia posiada pożądane
cechy, to możemy orzec, że protokół ten jest właściwy.
17
Nieodtwarzalne historie przetwarzania –
scenariusz
18
przykład
• Przypuśćmy, że transakcja T zmieniła wartość danej x.
• Następnie transakcja T’ wczytała x i na postawie jej wartości
zmieniła wartość danej y w bazie danych (T’ czyta z T).
• Przypuśćmy dalej, że transakcja T’ została zatwierdzona, a po
tym zdarzeniu powstała konieczność odrzucenia transakcji T.
• Należy więc wycofać wszystkie zmiany, jakie wprowadziła w
bazie danych transakcja T, a także wszystkie konsekwencje
tych zmian – w szczególności więc zmianę wartości danej y.
• Ta ostatnia operacja jest jednak niemożliwa, gdyż transakcja T’,
która zmianę tę wykonała, jest już zatwierdzona.
• Zaistniała sytuacja, w której baza danych jest nieodtwarzalna(!)
Definicja
Niech Σ = {T1, T2, ..., Tn} będzie zbiorem transakcji. Ciąg
H = (o1, o2, ..., om)
operacji pochodzących z transakcji należących do zbioru Σ
nazywamy historią przetwarzania transakcji ze zbioru Σ. Jeśli
operacja o poprzedza operację o’ w historii H, to stosować
będziemy zapis o < o’.
Definicja
Mówimy, że transakcja T’ czyta z transakcji T daną x, jeśli T jest
transakcją aktywną, która zapisała x.
Definicja
Mówimy, że transakcja T’ zapisuje w transakcji T daną x, jeśli T
jest transakcją aktywną, która odczytała x.
¾ Rozważmy historię przetwarzania
H1 : w1[x] r2[x] w2[y] c2 w1[z] a1.
• H1 opisuje przetwarzanie nieodtwarzalne.
• Transakcja T2 czyta z transakcji T1, w1[x] < r2[x], i T2 jest
zatwierdzana przed odrzuceniem T2, c2 < a1.
• Operacja w2[y] może oznaczać zapis wartości danej y
wyznaczonej na podstawie wartości danej x.
• Zmiany dokonanej przez operację w2[y] nie można jednak
wycofać (podczas wycofywania konsekwencji transakcji T1),
gdyż transakcja T2 została wcześniej zatwierdzona.
19
20
Historie przetwarzania z kaskadą odrzuceń –
scenariusz
przyczyna i unikanie anomalii
¾ Rozważmy nieodtwarzalną historię przetwarzania
H1 : w1[x] r2[x] w2[y] c2 w1[z] a1.
Powodem anomalii braku odtwarzalności jest to, że transakcja
czytająca dane z innej transakcji, T2, została zatwierdzona w
czasie aktywności transakcji, T1, z której czytała.
Aby sytuacji takiej uniknąć, należałoby czekać z zatwierdzeniem
transakcji T2 do czasu, aż zostanie zatwierdzona transakcja T1.
Definicja (zasada odtwarzalności)
Historia H przetwarzania transakcji opisuje przetwarzanie
odtwarzalne, jeśli każda transakcja jest zatwierdzana po
zatwierdzeniu wszystkich transakcji, z których czyta.
21
przykład
¾ Rozważmy następującą historię H2 powstałą z historii H1:
H2 : w1[x] r2[x] w2[u] a1.
• H2 opisuje przetwarzanie odtwarzalne.
• Jednak wykonanie operacji a1 powoduje odrzucenie (wycofanie)
transakcji T1 i w konsekwencji kaskadowe odrzucenie transakcji T2.
Przestrzeganie zasady odtwarzalności nie jest wystarczające. Mimo jej
przestrzegania może dojść do sytuacji, gdy odrzucenie jednej
transakcji pociągnie za sobą konieczność odrzucenia zależnej od niej
(w jakimś sensie) innej transakcji, odrzucenie tej drugiej może
spowodować konieczność odrzucenia trzeciej itd., co może prowadzić
do kaskady odrzuceń.
Niech na przykład transakcja T’ wczyta dane zmienione przez nie
zatwierdzoną jeszcze transakcję T. Przypuśćmy, że transakcja T
zostaje po tym zdarzeniu odrzucona. Konsekwencją tego jest także
konieczność odrzucenia transakcji T’. Może to spowodować
konieczność kaskadowego odrzucanie wielu transakcji.
22
¾ Rozważmy historię przetwarzania z kaskadą odrzuceń:
H2 : w1[x] r2[x] w2[u] a1.
Powodem występowania kaskady odrzuceń jest to, że
dopuszczalne jest czytanie z nie zatwierdzonych transakcji.
Anomalię tę można wyeliminować zakładając, że czytanie
danych zmienionych przez transakcję jest dopuszczalne
dopiero wtedy, gdy transakcja ta została już zatwierdzone
(eliminacja tzw. brudnego czytania)
Definicja (zasada zapobiegania kaskadzie odrzuceń)
Historia H opisuje przetwarzanie bez kaskady odrzuceń, jeśli
żadna z transakcji wchodząca w skład H nie czyta z transakcji
nie zatwierdzonych.
23
24
Historie przetwarzania z anomalią
powtórnego czytania – scenariusz
Historie przetwarzania z anomalią
powtórnego czytania – przykład
• Przypuśćmy, że transakcja T czyta daną x, a następnie transakcja T’
zapisuje nową wartość danej x i jest zatwierdzana.
• Jeśli teraz transakcja T ponownie przeczyta daną x, to może się
okazać, że dana ta ma inną wartość.
• Transakcja T dysponuje więc dwiema różnymi wartościami tej samej
danej.
• Może zdarzyć się też sytuacja, że transakcja T’ usunie daną x.
• Wówczas przy próbie ponownego czytania, transakcja T ma
informację, że danej x nie ma w bazie danych.
• Opisaną anomalię nazywamy anomalią powtórnego czytania.
25
26
Historie przetwarzania z fantomami –
scenariusz
Historie przetwarzania z anomalią powtórnego
czytania – przyczyna i unikanie anomalii
¾ Rozważmy historię przetwarzania z anomalią powtórnego czytania:
H3 : r1[y] w2[y] c2 r1[y] c1.
Powodem występowania anomalii powtórnego czytania jest to, że
dopuszczalne jest zapisywanie w nie zatwierdzonych
transakcjach.
Anomalię tę można wyeliminować zakładając, że zapisywanie
danych wczytanych przez transakcję jest dopuszczalne dopiero
wtedy, gdy transakcja ta została już zatwierdzona.
Definicja (zasada zapobiegania anomalii powtórnego czytania)
Historia H opisuje przetwarzanie bez anomalii powtórnego czytania
(tj. z powtarzalnym czytaniem) , jeśli żadna z transakcji wchodząca w
skład H nie zapisuje w transakcjach nie zatwierdzonych.
¾ Rozważmy następującą historię przetwarzania transakcji:
H3 : r1[y] w2[y] c2 r1[y] c1.
• W H3 występuje anomalia powtórnego czytania, gdyż między dwoma
wystąpieniami operacji czytania, r1[y], wystąpiła operacja zapisu w2[y],
czyli r1[y] < w2[y] < r1[y].
• Wartość danej y przy pierwszym wystąpieniu operacji r1[y] może być
różna niż przy drugim wykonaniu tej operacji.
• Uwaga: zauważmy, że drugie wystąpienie operacji r1[y] poprzedzone
jest operacją zatwierdzenia transakcji T2. Zakładamy bowiem, że
zabronione jest czytanie z nie zatwierdzonych transakcji. Możliwe jest
natomiast zapisywanie w nie zatwierdzonych transakcjach (operacja
w2[y]).
27
• Przypuśćmy, że transakcja T wczytała z tabeli R zbiór rekordów
spełniających warunek ϕ.
• Następnie inna transakcja, T’, dołączyła do R nowy rekord r
spełniający warunek ϕ i została zatwierdzona.
• Jeśli T ponownie odwoła się do rekordów tabeli R spełniających
warunek ϕ, to okaże się, że tym razem zbiór ten jest inny.
• Podobna sytuacja wystąpi, jeśli transakcja T’ dokona takiej modyfikacji
rekordu r’ nie spełniającego warunku ϕ, że po jej wykonaniu rekord r’
warunek ten będzie spełniał.
• Ten nowy rekord pojawiający się w obszarze zainteresowań transakcji
T nazywany jest fantomem lub zjawą.
28
przykład
¾ Rozważmy następującą historię przetwarzania transakcji:
H4 : r1[u] w2[z] c1 r1[u] c2.
• W historii H4 może wystąpić zjawisko fantomów.
• Jeśli bowiem operacja r1[u] wczytuje zbiór rekordów spełniających
warunek ϕ, a operacja w2[z] spowoduje, że zbiór takich rekordów
ulegnie zmianie (na przykład tak zostaną zmienione pola rekordu z, że
po zmianie rekord z będzie spełniał warunek ϕ), to powtórne
wykonanie operacji r1[u] zwróci inny zbiór rekordów.
• Anomalia ta jest podobna do anomalii powtórnego czytania. Tym
razem jednak transakcja T’ nie zmienia danych wczytanych przez nie
zatwierdzoną transakcję T, ale dołącza nowe dane do zbioru, na
którym T operuje (lub usuwa dane z tego zbioru).
29
Historie przetwarzania – podsumowanie
• Rozważając historie przetwarzania transakcji zidentyfikowaliśmy cztery
ich klasy, związane z nimi anomalie i sposoby ich unikania.
• W dalszym ciągu pokażemy, w jaki sposób można sterować poziomami
izolacji transakcji.
• Pokażemy, jaki jest związek między wybranym poziomem izolacji, a
właściwą mu klasą historii przetwarzania i tym samym, z jakimi
anomaliami należy się wówczas liczyć.
• Do określenia poziomów izolacji konieczne jest sprecyzowanie pojęcia
konfliktowości między operacjami tworzącymi historię przetwarzania i
tym samym między transakcjami, z których te operacje pochodzą.
31
¾ Rozważmy historię przetwarzania z fantomami:
H4 : r1[u] w2[z] c1 r1[u] c2.
Powodem pojawienia się fantomów jest to, że dopuszczalna jest zmiana
zbioru danych, na którym operuje transakcja T1. Konflikt między T1 i T2 nie
jest więc bezpośredni, jak miało to miejsce przy anomalii powtórnego
czytania.
Pojawianiu się fantomów można zapobiec zakładając, że zmiany
wykonywane przez transakcję T2 (dołączanie, usuwanie, aktualizacja) są
takie, że nie powodują zmiany zbioru danych, na których operuje T1.
Należy więc uwzględniać formuły definiujące zbiory danych, na których
działają transakcje.
Definicja (zasada zapobiegania pojawianiu się fantomów)
Historia H opisuje przetwarzanie bez fantomów , jeśli żadna z transakcji
wchodząca w skład H nie zmienia zbioru danych, na których działa
jakakolwiek transakcja nie zatwierdzona.
30
Konfliktowość operacji
¾ Z punktu widzenia stosowanego protokołów (algorytmów) zarządzania
transakcjami istotne jest przyjęcia pojęcia konfliktowości operacji, tzn.
przyjęcia, jakie operacje są konfliktowe, a jakie nie. Z góry można
określić, jakie operacje nigdy nie będą konfliktowe.
¾ Operacje oi[x] i pj[y] nie są konfliktowe, jeśli zachodzi co najmniej
jeden z poniższych warunków:
• i = j, tj. pochodzą z tej samej transakcji,
• x ≠ y, tj. dotyczą różnych danych (lub rozłącznych zbiorów
danych),
• żadna z operacji nie jest operacją zapisu,
• co najmniej jedna z operacji pochodzi od transakcji, która w chwili
wydania drugiej została już zakończona (zatwierdzona lub
odrzucona).
32
Konfliktowość operacji (c.d.)
Konfliktowość operacji (c.d.)
¾ Operacji oi[x] i pj[y] mogą być konfliktowe (warunek konieczny, ale nie
dostateczny) wtedy, gdy:
• i ≠ j – operacje pochodzą z dwóch różnych transakcji,
• co najmniej jedna z tych operacji jest operacją zapisu,
• x = y – operacje dotyczą tej samej danej (lub przecinających się
zbiorów danych);
• obydwie transakcji, z których pochodzą rozważane operacje są
aktywne;
• druga z operacji (pj[y]) powoduje zmianę zbioru danych x
(wyznaczonego przez pewną formułę ϕ), na których działa
pierwsza operacja (oi[x]).
¾ Definiowanie konfliktowości zależy ponadto od intencji użytkownika co do
poziomu wzajemnego odizolowania transakcji od siebie. Użytkownik ma więc
w istocie wpływ na interpretację cechy odizolowania wchodzącej w skład
właściwości ACID. Wyróżnia się cztery poziomy izolacji, a tym samym cztery
poziomy konfliktowości operacji: poziom 0, poziom 1, poziom 2, poziom 3.
¾ Im wyższy poziom izolacji transakcji (konfliktowości) tym niższa
współbieżność, a więc dłuższy czas wykonywania transakcji, ale jednocześnie
tym większa niezawodność przetwarzania oraz jego bezpieczeństwo z punktu
widzenia zachowania spójności bazy danych.
¾ Dalej rozważymy problemy, jakie wiążą się z przetwarzaniem na różnych
poziomach izolacji. Mówiąc o współbieżnym wykonywaniu operacji mamy na
myśli wykonywanie operacji pochodzących z różnych transakcji i to w czasie,
gdy obydwie te transakcje są aktywne. Transakcje, których operacje
wykonywane są współbieżnie, nazywamy transakcjami współbieżnymi.
33
Przetwarzanie transakcji na różnych
poziomach izolacji
34
Poziom izolacji 0
(READ UNCOMMITTED)
¾ Wyróżniamy cztery poziomy izolacji transakcji: najniższy (0) –
zapewnia największą współbieżność, ale wiąże się z największym
ryzykiem (mogą wystąpić anomalie omawiane poprzednio); najwyższy
(3) – pozwala uniknąć wszelkich anomalii, ale jest najbardziej
kosztowny (często ponoszenie tych kosztów jest niepotrzebne).
¾ Przyjęcie konkretnego poziomu izolacji wiąże się z określonymi
problemami – zbyt niski poziom zapewni nam zwiększenie
współczynnika współbieżności, ale może doprowadzić do
niekorzystnych cech związanych z zachowaniem spójności bazy
danych. Poziom zbyt wysoki może powodować nieuzasadnione
opóźnianie transakcji.
¾ W dalszym ciągu omówimy problemy związane z przyjęciem
poszczególnych poziomów izolacji.
35
• Poziom izolacji 0 dopuszcza czytanie przez transakcję danych nie
zatwierdzonych (uncommitted), tj. danych które zostały zmienione
przez transakcję jeszcze nie zatwierdzoną.
• Za operacje konfliktowe uważa się tylko parę operacji zapisu, a dwie
operacje, z których jedna jest operacją odczytu nie są operacjami
konfliktowymi.
• W standardzie SQL2 (a także w MS SQL Server) ten poziom izolacji
nazywany jest także READ UNCOMMITED, a popularnie określany
jest jako dirty read („brudne czytanie”).
36
Poziom izolacji 1
(READ COMMITTED)
Poziom izolacji 0
(READ UNCOMMITTED) (c.d.)
• Reguły współbieżności dla tego poziomu izolacji przedstawiono
poniższej w tablicy (T oznacza, że operacje mogą być
wykonywane współbieżnie, czyli nie są konfliktowe, N – oznacza
brak współbieżności, a więc konfliktowość).
•
•
•
• Przyjęcie tego rodzaju współbieżności operacji może doprowadzić
do braku odtwarzalności, kaskady odrzuceń, anomalii powtórnego
czytania oraz do pojawiania się fantomów.
• Zaletą tego poziomu izolacji jest jednak to, że uzyskujemy wysoki
współczynnik współbieżność transakcji.
• Ten poziom izolacji należy wybierać dla tych transakcji, które nie
wykorzystają wczytanych danych do modyfikacji bazy danych.
37
38
Poziom izolacji 2
(REPEATABLE READ)
Poziom izolacji 1
(READ UNCOMMITTED) (c.d.)
• Reguły współbieżności dla poziomu izolacji READ COMMITTED
przedstawiono poniższej w tablicy (T oznacza, że operacje mogą
być wykonywane współbieżnie, czyli nie są konfliktowe, N –
oznacza brak współbieżności, a więc konfliktowość).
• Przyjęcie tego rodzaju współbieżności operacji eliminuje brak
odtwarzalności oraz kaskadę odrzuceń.
• Na tym poziomie izolacji mogą jednak wystąpić zarówno anomalia
powtórnego czytania, jak i zjawisko fantomów.
•
•
Poziom izolacji 1 wprowadza zakaz czytania danych z transakcji
niezatwierdzonych, a więc czytać można tylko dane zatwierdzone
(committed)
Poziom ten w standardzie SQL2 określany jest także jako READ
COMMITED.
Przy tym poziomie izolacji dopuszczalne jest jednak zapisywanie
danych w transakcjach nie zatwierdzonych.
Jest to domyślny poziom izolacji w MS SQL server 2000.
Za konfliktowe uważa się wówczas takie pary operacji, gdzie pierwsza
jest operacją zapisu, a druga czytania, lub obydwie są operacjami
zapisu. Dwie operacje, z których pierwsza jest operacją czytania, a
druga operacją zapisu nie są więc konfliktowe.
39
• Poziom izolacji 2 wprowadza zakaz zapisywania w transakcjach
nie zatwierdzonych. Jeśli więc transakcja nie zatwierdzona
przeczytała jakąś daną, to dana ta może być tylko czytana przez
inną transakcję. Jeśli natomiast transakcja nie zatwierdzona
zapisała jakąś daną, to nie można jej ani odczytać ani tym
bardziej zapisać dopóty, dopóki transakcja ta nie zostanie
zatwierdzona.
• Za konfliktowe uważa się takie pary operacji, gdzie co najmniej
jedna jest operacją zapisu. Za niekonfliktowe uważa się tylko
operacje czytania.
• W standardzie SQL2 ten poziom izolacji określa się jako
REPEATABLE READ, gdyż eliminuje anomalię powtórnego
czytania.
40
Poziom izolacji 3
(SERIALIZABLE)
Poziom izolacji 2
(REPEATABLE READ) (c.d.)
•
Reguły współbieżności dla poziomu izolacji REPEATABLE READ
przedstawiono poniższej w tablicy (T oznacza, że operacje mogą być
wykonywane współbieżnie, czyli nie są konfliktowe, N – oznacza brak
współbieżności, a więc konfliktowość).
• Przyjęcie tego rodzaju współbieżności operacji eliminuje brak
odtwarzalności, kaskadę odrzuceń oraz anomalię powtórnego czytania.
• Na tym poziomie izolacji mogą pojawiać się fantomy.
• Przy tym poziomie izolacji współbieżność transakcji jest mniejsza niż
przy READ COMMITTED. Należy więc stosować go tylko wtedy, gdy
jest to naprawdę konieczne.
41
42
Poziom izolacji 3
(SERIALIZABLE) (c.d.)
Poziom izolacji 3
Pojęcie współbieżności operacji rozszerzamy obecnie następująco:
1. Dwie operacje Read[ϕ] i Read[ψ] są zawsze współbieżne.
2. Operacje, o[ϕ] i Write[ψ] są współbieżne, jeśli zbiór na którym
działa druga z tych operacji jest rozłączny ze zbiorem
związanym z wykonaniem pierwszej z nich oraz wykonanie
drugiej operacji nie zmieni zbioru związanego z wykonywaniem
pierwszej. Formalnie:
X ∩ Y = ∅ oraz
X = X’.
3. Operacje, Write[ϕ] i Read[ψ] są współbieżne, jeśli zbiór na
którym działa druga z tych operacji jest rozłączny ze zbiorem
związanym z wykonaniem pierwszej z nich. Formalnie:
X ∩ Y = ∅.
¾ Niech dane będą operacje o[ϕ] i p[ψ] pochodzące z dwóch
różnych i aktywnych transakcji (ϕ i ψ są formułami określającymi
zbiory danych, na których działa operacja) oraz niech operacja o
poprzedza operację p, tzn. o[ϕ] < p[ψ].
¾ Przyjmijmy oznaczenia:
• X = {x | ϕ(x)} – zbiór danych spełniających warunek ϕ
bezpośrednio przed wykonaniem operacji p[ψ],
• Y = {y | ψ(x)} – zbiór danych spełniających warunek ψ
bezpośrednio przed wykonaniem operacji p[ψ],
• X’ = {x | ϕ(x)} – zbiór danych spełniających warunek ϕ
bezpośrednio po wykonaniu operacji p[ψ].
• Poziom izolacji 3 rozwiązuje problem fantomów.
• Wymaga to poszerzenia rozważanych dotychczas pojęć
współbieżności i konfliktowości o formuły (predykaty) definiujące
zbiory danych, na których działają transakcje.
• Za niekonfliktowe uważa się takie operację, gdy działanie jednej
z nich nie powoduje zmiany zbiory danych, na których działa
druga.
• SERIALIZABLE oznacza, że historia przetwarzania transakcji
jest szeregowalna, a więc jest równoważna pewnej historii
szeregowej (tj. takiej, gdzie wszystkie operacje jednej transakcji
poprzedzają wszystkie operacje innej transakcji).
43
44
Poziomy izolacji przetwarzania transakcji
– podsumowanie
Poziom izolacji 3
• Reguły współbieżności dla poziomu izolacji SERIALIZABLE
przedstawiono poniższej w tablicy (T oznacza, że operacje mogą
być wykonywane współbieżnie, czyli nie są konfliktowe, N –
oznacza brak współbieżności, a więc konfliktowość).
• Przyjęcie określonego poziomu izolacji może być źródłem
problemów (anomalii) omówionych przy okazji historii
przetwarzania transakcji. Może też eliminować te problemy.
• W poniższej tablicy symbol T oznacza, że dany problem występuje
przy rozważanym poziomie izolacji, N – że nie występuje.
• Przyjęcie tego rodzaju współbieżności operacji eliminuje wszystkie
anomalię, w tym problem fantomów.
• Przy tym poziomie izolacji współbieżność transakcji jest najmniejsza, a
efektywność przetwarzania bardzo niska. Należy więc stosować go
tylko wtedy, gdy jest to naprawdę konieczne.
45
Przetwarzanie transakcji na różnych poziomach
izolacji – przykład
46
Poziom izolacji READ UNCOMMITTED – przykład
• Problemy związane z przetwarzaniem bazy danych przy
różnych poziomach izolacji zilustrujemy teraz przykładami z MS
SQL Server 2000.
• Przypuśćmy, że w bazie danych istnieje tabela Procesor o
następującej postaci:
• Przy poziomie izolacji 0 możliwe jest czytanie danych zmienionych
przez transakcje jeszcze nie zatwierdzone. Mówi się wówczas o
„brudnym czytaniu”. Dopuszczenie takiego czytania bardzo zwiększa
współbieżność przetwarzania, ale jednocześnie może doprowadzić do
udostępniania nieprawdziwych danych z bazy danych, co ilustruje
poniższy przykład.
• Na tabeli tej będą współbieżnie operowały dwie transakcje.
• Pierwsza z tych transakcji ma stały poziom izolacji, tj. domyślny
READ COMMITTED, a poziom izolacji drugiej z nich ustalany jest
za pomocą komendy SET TRANSACTION ISOLATION LEVEL
47
48
Poziom izolacji READ UNCOMMITTED – przykł
przykład
Poziom izolacji READ COMMITTED – przykł
przykład
Historia przetwarzania transakcji na poziomie izolacji READ UNCOMMITTED:
zapis–odczyt
Historia przetwarzania transakcji na poziomie izolacji READ COMMITTED:
odczyt – zapis:
Transakcja T1:
Transakcja T2:
set transaction isolation level read commited
go
set transaction isolation level read uncommitted
go
Transakcja T1:
Transakcja T2:
set transaction isolation level read commited
go
set transaction isolation level read committed
go
begin transaction
begin transaction
begin transaction
begin transaction
update Procesor set Cena = 300
where Nazwa = '200MMX'
T1 zmienia cenę
select Cena, Stan from Procesor
where Nazwa = '200MMX‘
T1 czyta cenę i stan towaru (320, 20)
select Cena from Procesor
where Nazwa = '200MMX'
T2 czyta zmienioną cenę (300)
update Procesor
set Cena = 310 where Nazwa = '200MMX'
T2 zmienia cenę wczytaną przez T1
rollback
T1 wycofuje zmianę
select sum(Cena*Stan)
from Procesor where Nazwa = '200MMX‘
T1 czeka na zakończenie T2
T2 ma niepoprawną informację o cenie (300
zamiast 320)
49
Poziom izolacji REPEATABLE READ –
przykład
commit
Wykonanie oczekującej operacji select dla
T1. Wynik sprzeczny z poprzednią operacją
select (zwracana wartość: 310*20 = 6200)
50
Poziom izolacji REPEATABLE READ – przykł
przykład
Historia przetwarzania transakcji na poziomie izolacji REPEATABLE READ:
odczyt – zapis – odczyt:
•
•
•
Przy poziomie izolacji REPEATABLE READ mamy zagwarantowane, że przy
ponownym odwołaniu się do tych samych danych, dostajemy identyczne
informacje.
Uzyskuje się to przez uniemożliwienie aktualizowania danych wczytanych przez
transakcję, która nie została jeszcze zakończona.
Przetwarzanie transakcji dyskutowane w poprzednim przykładzie będzie
obecnie miało historię przedstawioną na następnym slajdzie.
Transakcja T1:
Transakcja T2:
set transaction isolation level repeatable read
go
go
begin transaction
begin transaction
update Procesor
set Cena = 310 where Nazwa = '200MMX'
commit
T1 oblicza wartość towaru (320*20 = 6400)
Wykonanie oczekującej operacji update dla T2.
51
52
Poziom izolacji REPEATABLE READ – przykł
przykład
Poziom izolacji SERIALIZABLE – przykład
Historia przetwarzania transakcji na poziomie izolacji REPEATABLE READ:
odczyt – dołączanie – odczyt:
Transakcja T1:
Transakcja T2:
go
go
begin transaction
begin transaction
Historia przetwarzania transakcji na poziomie izolacji SERIALIZABLE:
odczyt – dołączanie – odczyt:
Transakcja T1:
Transakcja T2:
set transaction isolation level serializable
go
go
begin transaction
begin transaction
insert into Procesor
values('200MMX', 250, 10)
T2 dołącza nową krotkę, „fantom”
commit
T1 oblicza wartość towaru (6400)
commit
T1 oblicza wartość towaru (6400 + 2500)
insert into Procesor
values('200MMX', 250, 10)
Wykonanie insert przez T2
53
54

Transakcje

Transkrypt

Podobne dokumenty

Transakcje forward w PKO Banku Polskim SA Podstawa prawna

Forex - Rodzaje transakcji

Polska nie radzi sobie z rasizmem Redakcja

list referencyjny - Dega

LE PLAISIR DU CHAUFFAGE À LA FRANÇAISE

PRODUKT: Hermetyczna powłoka ochronna – elastomer