Właściwości transakcji

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 NrRach BGZ Saldo 1111 1000 NrRach WBK Saldo 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 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 NrRach Saldo 1111 1000 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 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED go begin transaction Transakcja T2 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED GO 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 SET TRANSACTION ISOLATION LEVEL READ COMMITTED go begin transaction Transakcja T2 SET TRANSACTION ISOLATION LEVEL READ COMMITTED GO 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 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ go begin transaction Transakcja T2 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ GO 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 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ go begin transaction Transakcja T2 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ GO 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 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE go begin transaction Transakcja T2 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE GO 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 O: READ UNCOMMITED 1: READ COMMITED Brak odtwarzal ności Anomalia powtórnego czytania T T T N T T Fantomy 2: REPEATABLE READ N N T 3: SERIALIZABLE N N N

Dziękuję za uwagę