Transakcje

Transakcje
Właściwości transakcji
• Transakcja – jednostka operowania na bazie
danych podlegająca kontroli i sterowaniu
• System zarządzania transakcjami ma za
zadanie takie sterowanie operacjami na 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
• Osiąga się to za pomocą odpowiednich
protokołów zarządzania transakcjami.
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) danej x przez transakcję T;
aT – odrzucenie (abort, rollback) transakcji T;
cT – zatwierdzenie (commit) transakcji T;
• x jest jednostką danych o różnym poziomie
granulacji np.. dana elementarna, krotka
(rekord), zbiór krotek wyznaczony przez
warunek Φ, tabela bazy danych, itd..
Definiowanie transakcji - przykład
CREATE PROCEDURE ZmniejszBGZ
@nrrach nchar(6),
@kwota int
AS
BEGIN
IF NOT EXISTS (SELECT * FROM BGZ
WHERE NrRach = @nrrach)
RETURN -1
ELSE
UPDATE BGZ SET Saldo = Saldo - @kwota
WHERE NrRach = @nrrach
RETURN @@error
END
CREATE TRIGGER UpBGZ
ON BGZ
FOR UPDATE
AS
BEGIN
DECLARE @Saldo int
SELECT @Saldo = BGZ.Saldo
FROM BGZ, deleted d
WHERE BGZ.NrRach = d.NrRach
IF @Saldo < 0
rollback
END
BGZ
WBK
NrRach
Saldo
NrRach
Saldo
1111
1000
2222
1000
CREATE PROCEDURE ZwiekszWBK
@nrrach nchar(6),
@kwota int
AS
BEGIN
IF NOT EXISTS (SELECT * FROM WBK
WHERE NrRach = @nrrach)
RETURN -1
ELSE
UPDATE WBK SET Saldo = Saldo +
@kwota
WHERE NrRach = @nrrach
RETURN @@error
END
Definiowanie transakcji – przykład
BGZ
CREATE PROCEDURE Przelew_BGZ_WBK
@zrach nchar(5),
NrRach
Saldo
@narach nchar(5),
@kwota int
1111
1000
AS
BEGIN
DECLARE @stan int
BEGIN TRANSACTION
EXEC @stan = ZmniejszBGZ @zrach, @kwota
IF @stan = 0
EXEC @stan = ZwiekszWBK @narach, @ kwota
IF @stan = 0
BEGIN
commit
PRINT ('Transakcja powiodla sie')
return
END
rollback
PRINT ('Transakcja nie powiodla sie')
END
WBK
NrRach
Saldo
2222
1000
Definiowanie transakcji – przykład
CREATE PROCEDURE Przelew_BGZ_WBK
@zrach nchar(5),
@narach nchar(5),
@kwota int
AS
BEGIN
DECLARE @stan int
BEGIN TRANSACTION
EXEC @stan = ZmniejszBGZ @zrach, @kwota
IF @stan = 0
EXEC @stan = ZwiekszWBK @narach, @kwota
IF @stan = 0
BEGIN
commit
PRINT ('Transakcja powiodla sie')
return
END
rollback
PRINT ('Transakcja nie powiodla sie')
END
BGZ
WBK
NrRach
Saldo
NrRach
Saldo
1111
1000
2222
1000
T: exec Przelew_BGZ_WBK '1111', '2222', 100
rT [‘1111’], wT [‘1111’], rT [‘2222’], wT [‘2222’], cT
BGZ
WBK
NrRach
Saldo
NrRach
Saldo
1111
900
2222
1100
Definiowanie transakcji – przykład
CREATE PROCEDURE Przelew_BGZ_WBK
@zrach nchar(5),
@narach nchar(5),
@kwota int
AS
BEGIN
DECLARE @stan int
BEGIN TRANSACTION
EXEC @stan = ZmniejszBGZ @zrach, @kwota
IF @stan = 0
EXEC @stan = ZwiekszWBK @narach, @kwota
IF @stan = 0
BEGIN
commit
PRINT ('Transakcja powiodla sie')
return
END
rollback
PRINT ('Transakcja nie powiodla sie')
END
BGZ
WBK
NrRach
Saldo
NrRach
Saldo
1111
1000
2222
1000
T: exec Przelew_BGZ_WBK '1112', '2222', 100
rT [‘1112’], aT
BGZ
WBK
NrRach
Saldo
NrRach
Saldo
1111
1000
2222
1000
Definiowanie transakcji – przykład
CREATE PROCEDURE Przelew_BGZ_WBK
@zrach nchar(5),
@narach nchar(5),
@kwota int
AS
BEGIN
DECLARE @stan int
BEGIN TRANSACTION
EXEC @stan = ZmniejszBGZ @zrach, @kwota
IF @stan = 0
EXEC @stan = ZwiekszWBK @narach, @kwota
IF @stan = 0
BEGIN
commit
PRINT ('Transakcja powiodla sie')
return
END
rollback
PRINT ('Transakcja nie powiodla sie')
END
BGZ
WBK
NrRach
Saldo
NrRach
Saldo
1111
1000
2222
1000
T: exec Przelew_BGZ_WBK '1111', '2222', 1100
rT [‘1111’], wT [‘1111’], aT
Definiowanie transakcji – przykład
CREATE PROCEDURE Przelew_BGZ_WBK
@zrach nchar(5),
@narach nchar(5),
@kwota int
AS
BEGIN
DECLARE @stan int
BEGIN TRANSACTION
EXEC @stan = ZmniejszBGZ @zrach, @kwota
IF @stan = 0
EXEC @stan = ZwiekszWBK @narach, @kwota
IF @stan = 0
BEGIN
commit
PRINT ('Transakcja powiodla sie')
return
END
rollback
PRINT ('Transakcja nie powiodla sie')
END
BGZ
WBK
NrRach
Saldo
NrRach
Saldo
1111
1000
2222
1000
T: exec Przelew_BGZ_WBK '1111', '2223', 200
rT [‘1111’], wT [‘1111’], rT [‘2223’], aT
Definiowanie transakcji – podsumowanie
• Każde wykonanie procedury Przelew_BGZ_WBK
powoduje utworzenie nowej transakcji.
• Przykłady transakcji:
•
•
•
rT [‘1111’], wT [‘1111’], rT [‘2222’], wT [‘2222’], cT
rT [‘1112’], aT
rT [‘1111’], wT [‘2222’], aT
•
rT [‘1111’], wT [‘1111’], rT [‘2223’], aT
• W systemie, w którym istnieje wiele stanowisk
komputerowych może być tworzonych wiele transakcji
• Mogą się wykonywać współbieżnie, a więc przed
zakończeniem jednej może się uruchamiać inna.
Właściwości ACID
• Przyjmuje się, że transakcje i protokoły zarządzania transakcjami
powinny posiadać właściwości ACID:
• Atomowość (atomicity) – każda transakcja stanowi pojedynczą i
niepodzielną jednostkę przetwarzania. Każda transakcja jest
wykonywana w całości albo wcale.
• Spójność (consistency) – transakcja rozpoczynając się w spójnym
stanie bazy danych pozostawia bazę danych w stanie spójnym. Nie
może naruszyć warunków spójności.
• Odizolowanie (isolation) – zmiany wykonywane przez transakcję nie
zatwierdzoną nie są widziane przez inne transakcje (chyba, że
przyjęty 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.
Właściwości ACID - przykład
• Atomowość oznacza, że transakcję:
rT [‘1111’], wT [‘1111’], rT [‘2222’], wT [‘2222’], cT
traktujemy jako niepodzielną całość. Nie
może być sytuacji, że system wykona tylko
dwie operacje, a dwóch nie.
Właściwości ACID - przykład
• Spójność oznacza, że system nie dopuści do
zatwierdzenia transakcji, która naruszy
jakikolwiek warunek spójności bazy danych
• Przykładowo: stan rachunku bankowego musi
być większy od zera (statyczny warunek
spójności) lub suma stanów kont po wykonaniu
transakcji musi być taka sama jak suma przed
wykonaniem transakcji
Właściwości ACID - przykład
• Odizolowanie oznacza, że zmiany wykonane przez
jedną transakcję nie są widoczne w innych transakcjach
dopóty, dopóki transakcja ta nie zostanie zatwierdzona.
• Rozważmy następujący ciąg operacji:
r1[Konto1], w1[Konto1], r1[Konto2], r2[Konto2], c2, w1[Konto2], c1
Transakcja T2 odczytuje wartość Konto2 zanim
transakcja T1 została zatwierdzona. Naruszony jest
warunek odizolowania.
• Często jednak sytuacja taka jest dopuszczalna.
Właściwości ACID - przykład
• Trwałość oznacza, że zmiany
wprowadzone do bazy danych przez
zatwierdzoną transakcję są w tej bazie
trwałe.
• W przypadku awarii systemu musi istnieć
mechanizm ich odtwarzania.
Nieodtwarzalne historie przetwarzania - scenariusz
•
•
•
•
•
•
•
•
•
Przypuśćmy, że transakcja T1 zmieniła wartość danej x
H: w1[x]
Następnie transakcja T2 wczytała x i na podstawie jej wartości zmieniła
wartość danej y na bazie danych (T2 czyta z T1)
H: w1[x] r2[x] w2[x->y]
Następnie transakcja T2 została zatwierdzona, a po tym zdarzeniu powstała
konieczność odrzucenia T1.
H: w1[x] r2[x] w2[x->y] c2 w1[z] a1
Należy więc wycofać wszystkie zmiany, jakie wprowadziła w bazie danych
transakcja T1, a także wszystkie konsekwencje tych zmian, a więc zmianę
wartości danej y.
Ta ostatnia operacja nie jest jednak możliwa, gdyż T2 została zatwierdzona.
Jest to przykład historii nieodwracalnej.
Nieodtwarzalne historie przetwarzania –
przyczyna i unikanie
• Rozważmy nieodwracalną historię przetwarzania:
H: w1[x] r2[x] w2[x->y] c2 w1[z] a1
• Powodem anomalii braku odtwarzalności jest to, że
transakcja T2 czytająca dane z nie zatwierdzonej
transakcji (T1) została zatwierdzona w czasie działania
transakcji T1.
• Aby sytuacji takiej uniknąć należałoby czekać z
rozpoczęciem transakcji T2 do czasu, aż zostanie
zatwierdzona T1.
• Anomalię tę nazywa się brudnym czytaniem (ang. dirty
read).
Historie przetwarzania z anomalią powtórnego
czytania - scenariusz
•
•
•
•
•
•
•
•
•
•
Przypuśćmy, że transakcja T1 czyta wartość danej x
H: r1[x]
Następnie transakcja T2 zapisuje nową wartość x i jest zatwierdzana
H: r1[x] w2[x] c2
Jeśli teraz transakcja T1 ponownie czyta daną x, to może się okazać, że
dana ta ma inną wartość.
H: r1[x] w2[x] c2 r1[x] c1
Transakcja T dysponuje więc dwiema różnymi wartościami tej samej danej.
Może się zdarzyć, że T2 usunie daną x.
Wówczas przy próbie ponownego odczytania transakcja T1 na informację,
że danej x nie ma w bazie.
Jest to anomalia powtórnego czytania.
Historie przetwarzania z anomalią
powtórnego czytania– przyczyna i unikanie
• Rozważmy historię przetwarzania z anomalią powtórnego czytania:
H: r1[x] w2[x] c2 r1[x] 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 zatwierdzona.
• Żadna transakcja więc nie może zapisywać w transakcjach nie
zatwierdzonych.
Historie przetwarzania z fantomami - scenariusz
•
•
•
•
•
•
•
•
Przypuśćmy, że transakcja T1 wczytała z tabeli R zbiór rekordów
spełniających warunek Φ
H: r1[u]
Następnie transakcja T2 dołączyła do R nowy rekord spełniający warunek
Φ i została zatwierdzana
H: r1[u] w2[z] c2
Jeśli teraz transakcja T1 ponownie odwoła się do rekordów tabeli R
spełniających warunek Φ, to może się okazać, że zbiór jest inny.
H: r1[u] w2[z] c2 r1[u] c1
Transakcja T dysponuje więc dwiema różnymi zestawami danych
spełniających warunek Φ.
Nowy rekord pojawiający się w obszarze zainteresować transakcji T1
nazywa się fantomem.
Historie przetwarzania z fantomami –
przyczyna i unikanie
• Rozważmy historię przetwarzania z fantomami:
H: r1[u] w2[z] c2 r1[u] c1
• Powodem pojawienia się fantomów jest to, że dopuszczalna jest
zmiana zbioru danych, na którym operuje transakcja T1.
• Pojawianiu się fantomów można zapobiec zakładając, że zmiany
wykonywane przez transakcję (dołączanie, usuwanie, aktualizacja)
są takie, że nie powodują zmiany zbioru danych, na których operuje
T1.
• Należy więc uwzględnić formuły definiujące zbiory danych, na
których działają transakcje.
Historie przetwarzania - podsumowanie
• Rozważając historie przetwarzania transakcji
zdefiniowaliś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 pomiędzy wybranym
poziomem izolacji, a właściwą mu klasą przetwarzania i
tym samym, z jakimi anomaliami należy się liczyć.
• Do określenia poziomów izolacji konieczne jest
sprecyzowanie pojęcia konfliktowości między operacjami
tworzącymi historię przetwarzania transakcji.
Konfliktowość operacji
• Z góry można określić, jakie operacje nie są
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 wywołania drugiej została już zakończona
Konfliktowość operacji
• Operacje oi[x] i pj[y] mogą być konfliktowe, wtedy
gdy:
– i <> j, tj. operacje pochodzą z różnych transakcji,
– x = y, tj. operacje dotyczą tej samej danej (lub przecinających się
zbiorów danych),
– Co najmniej jedna z operacji jest operacją zapisu,
– Obydwie transakcje, z których pochodzą rozważane operacje są
aktywne,
– Druga operacja pj[y] powoduje zmianę zbioru danych zbioru
danych x, na których działa pierwsza operacja oi[x].
Przetwarzanie operacji na różnych
poziomach izolacji
• Wyróżniamy cztery poziomy izolacji transakcji:
najniższy(0) – zapewnia największą współbieżność, ale
wiąże się z największym ryzykiem występowania
anomalii; najwyższy(3) – pozwala uniknąć wszelkich
anomalii, ale jest najbardziej kosztowny (często
niepotrzebnie)
• Przyjęcie określonego poziomu izolacji wiąże się z
określonymi problemami:
– Zbyt niski: duża współbieżność – większe ryzyko anomalii
– Zbyt wysoki: nieuzasadnione opóźnienie transakcji
Poziomy izolacji - przykład
• Zakładamy istnienie tabeli Procesor o
następującej postaci:
Procesor
Nazwa Cena
Stan
200MMX
320
20
233MMX
370
50
Na tabeli będą działały dwie transakcje.
Poziom izolacji 0
(READ UNCOMMITED)
• Poziom izolacji 0 dopuszcza czytanie przez transakcje
danych nie zatwierdzonych, tj. danych które zostały
zmienione przez transakcję jeszcze nie zatwierdzoną.
• Za operacje konfliktowe uznaje się tylko operacje zapisu,
a dwie operacje, z których jedna jest operacją odczytu
nie są konfliktowe.
• Ten poziom izolacji nazywa się READ UNCOMMITED, a
popularnie dirty read (brudne czytanie).
• Ten rodzaj współbieżności prowadzi do braku
odtwarzalności, anomalii powtórnego czytania oraz do
pojawienia się fantomów.
• Zaletą jest wysoki poziom współbieżności.
Poziom izolacji READ UNCOMMITED przykład
Transakcja T1
Transakcja T2
SET TRANSACTION ISOLATION LEVEL READ
UNCOMMITTED
go
SET TRANSACTION ISOLATION LEVEL READ
UNCOMMITTED
GO
begin transaction
begin transaction
update Procesor set Cena = 300
where Nazwa = '200MMX'
select * from Procesor
where Nazwa = '200MMX'
rollback
T2 ma niepoprawną informację o cenie (300
zamiast 320)
Poziom izolacji 1
(READ COMMITED)
• Poziom wprowadza zakaz czytania danych z nie
zatwierdzonych transakcji, a więc czytać można tylko
dane zatwierdzone.
• Ten poziom izolacji nazywa się READ COMMITED
• Przy tym poziomie izolacji dopuszczalne jest jednak zapisywanie
danych w transakcjach nie zatwierdzonych.
• Domyślny poziom SQL Server
• Za konfliktowe uznaje się takie pary, gdzie pierwsza jest operacją
zapisu a druga odczytu, lub obydwie są operacjami zapisu.
• Nie są konfliktowe operacje, z których pierwsza jest operacją
czytania, a druga operacją zapisu.
• Przyjęcie tego poziomu eliminuje brak odtwarzalności.
• Na tym poziomie występują zarówno anomalia powtórnego czytania,
jak również fantomów.
Poziom izolacji READ COMMITED przykład
Transakcja T1
Transakcja T2
SET TRANSACTION ISOLATION LEVEL READ
COMMITTED
go
SET TRANSACTION ISOLATION LEVEL READ
COMMITTED
GO
begin transaction
begin transaction
select sum(Cena*Stan) from Procesor
where Nazwa = '200MMX'
update Procesor set Cena = 310
where Nazwa = '200MMX'
select sum(Cena*Stan)
from Procesor
where Nazwa = '200MMX'
Wynik różny dla pierwszego i drugiego SELECT
commit
Poziom izolacji 2
(REPEATABLE READ)
• Poziom 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 transakcja nie zatwierdzona zapisała jakąś daną, to nie można
jej ani odczytać ani tym bardziej zapisać, dopóki transakcja nie
zostanie zatwierdzona.
• Za konfliktowe uważa się takie pary operacji, gdzie co najmniej
jedna jest operacją zapisu. Za niekonfliktowe tylko operacje
czytania.
• Ten poziom izolacji nazywa się REPEATABLE READ.
• Przyjęcie tego poziomu eliminuje brak odtwarzalności oraz anomalię
powtórnego czytania.
• Na tym poziomie mogą pojawić się fantomy.
Poziom izolacji REPEATABLE READ przykład
Transakcja T1
Transakcja T2
SET TRANSACTION ISOLATION LEVEL
REPEATABLE READ
go
SET TRANSACTION ISOLATION LEVEL
REPEATABLE READ
GO
begin transaction
begin transaction
select sum(Cena*Stan) from Procesor
where Nazwa = '200MMX'
update Procesor set Cena = 310
where Nazwa = '200MMX'
select sum(Cena*Stan)
from Procesor
where Nazwa = '200MMX'
Wynik taki sam dla pierwszego i drugiego
SELECT
commit
Poziom izolacji REPEATABLE READ przykład
Transakcja T1
Transakcja T2
SET TRANSACTION ISOLATION LEVEL
REPEATABLE READ
go
SET TRANSACTION ISOLATION LEVEL
REPEATABLE READ
GO
begin transaction
begin transaction
select sum(Cena*Stan) from Procesor
where Nazwa = '200MMX'
insert into Procesor
values('200MMX', 250, 10)
select sum(Cena*Stan)
from Procesor
where Nazwa = '200MMX'
Wynik różny dla pierwszego i drugiego SELECT
commit
Poziom izolacji 3
(SERIALIZABLE)
• Poziom izolacji rozwiązuje problem fantomów.
• Za niekonfliktowe uznaje się tylko te operacje, gdy
działanie jednej z nich nie powoduje zmiany zbioru
danych, na których działa druga.
• SERIALIZABLE oznacza, że historia przetwarzania
transakcji jest szeregowalna, a więc wszystkie operacje
jednej transakcji. poprzedzają wszystkie operacje innej
transakcji.
• Przyjęcie tego poziomu eliminuje wszystkie anomalie, w
tym problem fantomów.
• Współbieżność transakcji jest najmniejsza, a więc
efektywność przetwarzania jest bardzo niska. Należy
stosować wtedy, gdy to jest konieczne.
Poziom izolacji SERIALIZABLE - przykład
Transakcja T1
Transakcja T2
SET TRANSACTION ISOLATION LEVEL
SERIALIZABLE
go
SET TRANSACTION ISOLATION LEVEL
SERIALIZABLE
GO
begin transaction
begin transaction
select sum(Cena*Stan) from Procesor
where Nazwa = '200MMX'
insert into Procesor
values('200MMX', 250, 10)
select sum(Cena*Stan)
from Procesor
where Nazwa = '200MMX'
Wynik taki sam dla pierwszego i drugiego
SELECT. Wynik nie uwzględnia INSERT
Wykonanie insert przez T2
Poziomy izolacji transakcji podsumowanie
Poziom
izolacji
Brak
odtwarzal
ności
T
Anomalia
Fantomy
powtórnego
czytania
T
T
1: READ
COMMITED
N
T
T
2: REPEATABLE
READ
N
N
T
3: SERIALIZABLE
N
N
N
O: READ
UNCOMMITED
Dziękuję za uwagę