Tadeusz Pankowski www.put.poznan.pl/~tadeusz.pankowski

Transakcje i ich właściwości Transakcje Tadeusz Pankowski wwwputpoznanpl/~tadeuszpankowski W SZBD stosuje się pojęcie transakcji jako jednostki operowania na bazie danych podlegającej sterowaniu i kontroli 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 (c) T Pankowski, Transakcje 1 (c) T Pankowski, Transakcje 2 Transakcje i ich właściwości Transakcją T nazywamy ciąg ntępujących operacji na wspólnej bazie danych: r T [x] czytanie (read) danej x przez transakcję T, w T [x] zapisanie (write) (aktualizacja) danej x przez transakcję T, a T odrzucenie (abort, rollback) (wycofanie) transakcji T, c T zatwierdzenie () 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 procedure UMNIEJSZ_PKO @nrrach char(5, @kwota money 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 create trigger IC_PKO on PKO for UPDATE declare @saldo money select @saldo = PKOSaldo from PKO, deleted d where PKONrRach = dnrrach if @saldo < 0 rollback Definiowanie transakcji - przykład create procedure POWIEKSZ_WBK @nrrach char(5, @kwota money 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 (c) T Pankowski, Transakcje 3

Definiowanie transakcji przykład (cd) Transakcja przykład (cd) create procedure PRZELEW_PKO_WBK @zrach char(5, @narach char(5, @kwota money declare @stan int exec @stan = UMNIEJSZ_PKO @zrach, @kwota exec @stan = POWIEKSZ_WBK @narach, @kwota return rollback (c) T Pankowski, Transakcje 5 create procedure PRZELEW_PKO_WBK @zrach char(5, @narach char(5, @kwota money declare @stan int exec @stan = UMNIEJSZ_PKO @zrach, @kwota exec @stan = POWIEKSZ_WBK @narach, @kwota return rollback T: exec PRZELEW_PKO_WBK '11-11', 11', '22-22', 22', 100 r T [ 11-11 ], 11 ], w T [11-11 ], 11 ], r T [ 22-22 ], 22 ], w T [ 22-22 ], 22 ], c T (c) T Pankowski, Transakcje 6 Transakcja przykład (cd) Transakcja przykład (cd) create procedure PRZELEW_PKO_WBK @zrach char(5, @narach char(5, T: exec PRZELEW_PKO_WBK '11-12', 12', '22-22',100 22',100 @kwota money r T [ 11-12 ], 12 ], a T declare @stan int exec @stan = UMNIEJSZ_PKO @zrach, @kwota exec @stan = POWIEKSZ_WBK @narach, @kwota return rollback (c) T Pankowski, Transakcje 7 create procedure PRZELEW_PKO_WBK @zrach char(5, @narach char(5, T: exec PRZELEW_PKO_WBK '11-11', 11', '22-22',1000 22',1000 @kwota money r T [ 11-11 ], 11 ], w T [ 11-11 ], 11 ], a T declare @stan int exec @stan = UMNIEJSZ_PKO @zrach, @kwota exec @stan = POWIEKSZ_WBK @narach, @kwota return rollback (c) T Pankowski, Transakcje 8

Transakcja przykład (cd) Przykład - podsumowanie create procedure PRZELEW_PKO_WBK @zrach char(5, @narach char(5, T: exec PRZELEW_PKO_WBK '11-11', 11', '22-23',10 23',10 @kwota money r T [ 11-11 ], 11 ], w T [ 11-11 ], 11 ], r T [ 22-23 ], 23 ], a T declare @stan int exec @stan = UMNIEJSZ_PKO @zrach, @kwota exec @stan = POWIEKSZ_WBK @narach, @kwota return rollback (c) T Pankowski, Transakcje 9 Każde wykonywanie programu PRZELEW_PKO_WBK powoduje utworzenie nowej transakcji Przykłady takich transakcji: r T [ 11-11 ], w T [ 11-11 ], r T [ 22-22 ], w T [ 22-22 ], c T r T [ 11-12 ], a T r T [ 11-11 ], w T [ 11-11 ], a T r T [ 11-11 ], w T [ 11-11 ], r T [ 22-23 ], a T 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 ntępna (inicjowana na przykład z inne stanowiska komputerowe) 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) (c) T Pankowski, Transakcje 10 Właściwości ACID Przyjmuje się, że transakcje i protokoły zarządzania transakcjami muszą posiadać właściwość ACID wyrażoną przez ntę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 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 (c) T Pankowski, Transakcje 11 Właściwości ACID (cd) 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łutrwał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) (c) T Pankowski, Transakcje 12

Właściwości ACID - przykład Atomowość oznacza, że transakcję T i = (r i [Konto1], w i [Konto1], r i [Konto2], w i [Konto2], c i ), 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ś czie zrealizuje dwie ntępne operacje Byłaby to koncepcja wyróżniania podtransakcji, co w tradycyjnych systemach baz danych jest niedopuszczalne Jeśli więc z jakieś powodu wykonanie transakcji ulegnie przerwaniu (na przykład w wyniku awarii) po dwóch pierwszych operacjach, to system musi zapewnić wycofanie dokonanych zmian 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 W rozważanym przypadku warunkiem spójności może być wymaganie, aby stan rachunku bankowe 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) (c) T Pankowski, Transakcje 13 (c) T Pankowski, Transakcje 14 Właściwości ACID - przykład 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 ntępujący ciąg operacji: r 1 [Konto1], w 1 [Konto1], r 1 [Konto2], r 2 [Konto2], c 2, w 1 [Konto2], c 1, gdzie T 1 jest transakcją przelewu, a T 2 odczytuje stan konta Konto2, zanim jeszcze transakcja zmieniająca ten stan została zatwierdzona Naruszony jest więc ryrystyczny warunek odizolowania Często jednak sytuacja taka jest dopuszczalna (zwłzcza wtedy gdy odczytana wartość nie będzie wykorzystana do aktualizacji bazy danych) Właściwości ACID - przykład 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 fizyczne zniszczenia nośnika danych) musi istnieć mechanizm ich odtwarzania Automatycznie jest wówcz odtwarzany ostatni poprawny (spójny) stan bazy danych Tak rozumiane odtwarzania nie należy mylić z odtwarzaniem bazy danych z archiwum (c) T Pankowski, Transakcje 15 (c) T Pankowski, Transakcje 16

Historie przetwarzania transakcji Z punktu widzenia analizy poprawności protokołów (alrytmów) zarządzania transakcjami istotne jest analizowanie historii przetwarzania transakcji Historia taka znana jest oczywiście dopiero po wykonaniu dane 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óre historia posiada pożądane cechy, to możemy orzec, że protokół ten jest właściwy Historie przetwarzania transakcji Definicja Niech Σ = {T 1, T 2,, T n } będzie zbiorem transakcji Ciąg H = (o 1, o 2,, o m ) 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 (c) T Pankowski, Transakcje 17 (c) T Pankowski, Transakcje 18 Nieodtwarzalne historie przetwarzania scenariusz Nieodtwarzalne historie przetwarzania przykład Przypuśćmy, że transakcja T zmieniła wartość danej x Ntę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(!) Rozważmy historię przetwarzania H 1 : w 1 [x] r 2 [x] w 2 [y] c 2 w 1 [z] a 1 H 1 opisuje przetwarzanie nieodtwarzalne Transakcja T 2 czyta z transakcji T 1, w 1 [x] < r 2 [x], i T 2 jest zatwierdzana przed odrzuceniem T 2, c 2 < a 1 Operacja w 2 [y] może oznaczać zapis wartości danej y wyznaczonej na podstawie wartości danej x Zmiany dokonanej przez operację w 2 [y] nie można jednak wycofać (podcz wycofywania konsekwencji transakcji T 1 ), gdyż transakcja T 2 została wcześniej zatwierdzona (c) T Pankowski, Transakcje 19 (c) T Pankowski, Transakcje 20

Nieodtwarzalne historie przetwarzania przyczyna i unikanie anomalii Rozważmy nieodtwarzalną historię przetwarzania H 1 : w 1 [x] r 2 [x] w 2 [y] c 2 w 1 [z] a 1 Powodem anomalii braku odtwarzalności jest to, że transakcja czytająca dane z innej transakcji, T 2, została zatwierdzona w czie aktywności transakcji, T 1, z której czytała Aby sytuacji takiej uniknąć, należałoby czekać z zatwierdzeniem transakcji T 2 do czu, aż zostanie zatwierdzona transakcja T 1 Definicja (zada odtwarzalności) Historia H przetwarzania transakcji opisuje przetwarzanie odtwarzalne, jeśli każda transakcja jest zatwierdzana po zatwierdzeniu wszystkich transakcji, z których czyta Historie przetwarzania z kkadą odrzuceń scenariusz Przestrzeganie zady 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 kkady 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ą te jest także konieczność odrzucenia transakcji T Może to spowodować konieczność kkadowe odrzucanie wielu transakcji (c) T Pankowski, Transakcje 21 (c) T Pankowski, Transakcje 22 Historie przetwarzania z kkadą odrzuceń przykład Rozważmy ntępującą historię H 2 powstałą z historii H 1 : H 2 : w 1 [x] r 2 [x] w 2 [u] a 1 H 2 opisuje przetwarzanie odtwarzalne Jednak wykonanie operacji a 1 powoduje odrzucenie (wycofanie) transakcji T 1 i w konsekwencji kkadowe odrzucenie transakcji T 2 Historie przetwarzania z kkadą odrzuceń przyczyna i unikanie anomalii Rozważmy historię przetwarzania z kkadą odrzuceń: H 2 : w 1 [x] r 2 [x] w 2 [u] a 1 Powodem występowania kkady 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 brudne czytania) Definicja (zada zapobiegania kkadzie odrzuceń) Historia H opisuje przetwarzanie bez kkady odrzuceń, jeśli żadna z transakcji wchodząca w skład H nie czyta z transakcji nie zatwierdzonych (c) T Pankowski, Transakcje 23 (c) T Pankowski, Transakcje 24

Historie przetwarzania z anomalią powtórne czytania scenariusz Przypuśćmy, że transakcja T czyta daną x, a ntę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ówcz przy próbie ponowne czytania, transakcja T ma informację, że danej x nie ma w bazie danych Opisaną anomalię nazywamy anomalią powtórne czytania Historie przetwarzania z anomalią powtórne czytania przykład Rozważmy ntępującą historię przetwarzania transakcji: H 3 : r 1 [y] w 2 [y] c 2 r 1 [y] c 1 W H 3 występuje anomalia powtórne czytania, gdyż między dwoma wystąpieniami operacji czytania, r 1 [y], wystąpiła operacja zapisu w 2 [y], czyli r 1 [y] < w 2 [y] < r 1 [y] Wartość danej y przy pierwszym wystąpieniu operacji r 1 [y] może być różna niż przy drugim wykonaniu tej operacji Uwaga: zauważmy, że drugie wystąpienie operacji r 1 [y] poprzedzone jest operacją zatwierdzenia transakcji T 2 Zakładamy bowiem, że zabronione jest czytanie z nie zatwierdzonych transakcji Możliwe jest natomit zapisywanie w nie zatwierdzonych transakcjach (operacja w 2 [y]) (c) T Pankowski, Transakcje 25 (c) T Pankowski, Transakcje 26 Historie przetwarzania z anomalią powtórne czytania przyczyna i unikanie anomalii Historie przetwarzania z fantomami scenariusz Rozważmy historię przetwarzania z anomalią powtórne czytania: H 3 : r 1 [y] w 2 [y] c 2 r 1 [y] c 1 Powodem występowania anomalii powtórne 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 (zada zapobiegania anomalii powtórne czytania) Historia H opisuje przetwarzanie bez anomalii powtórne czytania (tj z powtarzalnym czytaniem), jeśli żadna z transakcji wchodząca w skład H nie zapisuje w transakcjach nie zatwierdzonych Przypuśćmy, że transakcja T wczytała z tabeli R zbiór rekordów spełniających warunek ϕ Ntę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ące 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ą (c) T Pankowski, Transakcje 27 (c) T Pankowski, Transakcje 28

Historie przetwarzania z fantomami przykład Rozważmy ntępującą historię przetwarzania transakcji: H 4 : r 1 [u] w 2 [z] c 1 r 1 [u] c 2 W historii H 4 może wystąpić zjawisko fantomów Jeśli bowiem operacja r 1 [u] wczytuje zbiór rekordów spełniających warunek ϕ, a operacja w 2 [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 r 1 [u] zwróci inny zbiór rekordów Anomalia ta jest podobna do anomalii powtórne 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 te zbioru) Historie przetwarzania z fantomami przyczyna i unikanie anomalii Rozważmy historię przetwarzania z fantomami: H 4 : r 1 [u] w 2 [z] c 1 r 1 [u] c 2 Powodem pojawienia się fantomów jest to, że dopuszczalna jest zmiana zbioru danych, na którym operuje transakcja T 1 Konflikt między T 1 i T 2 nie jest więc bezpośredni, jak miało to miejsce przy anomalii powtórne czytania Pojawianiu się fantomów można zapobiec zakładając, że zmiany wykonywane przez transakcję T 2 (dołączanie, usuwanie, aktualizacja) są takie, że nie powodują zmiany zbioru danych, na których operuje T 1 Należy więc uwzględniać formuły definiujące zbiory danych, na których działają transakcje Definicja (zada 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 (c) T Pankowski, Transakcje 29 (c) T Pankowski, Transakcje 30 Historie przetwarzania podsumowanie Rozważając historie przetwarzania transakcji zidentyfikowaliśmy cztery ich kly, 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 klą historii przetwarzania i tym samym, z jakimi anomaliami należy się wówcz 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ą Konfliktowość operacji Z punktu widzenia stosowane protokołów (alrytmó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 o i [x] i p j [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) (c) T Pankowski, Transakcje 31 (c) T Pankowski, Transakcje 32

Konfliktowość operacji (cd) Konfliktowość operacji (cd) Operacji o i [x] i p j [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 (p j [y]) powoduje zmianę zbioru danych x (wyznaczone przez pewną formułę ϕ), na których działa pierwsza operacja (o i [x]) Definiowanie konfliktowości zależy ponadto od intencji użytkownika co do poziomu wzajemne 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 cz wykonywania transakcji, ale jednocześnie tym większa niezawodność przetwarzania oraz je 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 czie, gdy obydwie te transakcje są aktywne Transakcje, których operacje wykonywane są współbieżnie, nazywamy transakcjami współbieżnymi (c) T Pankowski, Transakcje 33 (c) T Pankowski, Transakcje 34 Przetwarzanie transakcji 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 (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 konkretne 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ć nieuzadnione opóźnianie transakcji W dalszym ciągu omówimy problemy związane z przyjęciem poszczególnych poziomów izolacji Poziom izolacji 0 (READ UNCOMMITTED) Poziom izolacji 0 dopuszcza czytanie przez transakcję danych nie zatwierdzonych (unted), 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 ) (c) T Pankowski, Transakcje 35 (c) T Pankowski, Transakcje 36

Poziom izolacji 0 (READ UNCOMMITTED) (cd) Reguły współbieżności dla te 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 te rodzaju współbieżności operacji może doprowadzić do braku odtwarzalności, kkady odrzuceń, anomalii powtórne czytania oraz do pojawiania się fantomów Zaletą te 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 Poziom izolacji 1 (READ COMMITTED) Poziom izolacji 1 wprowadza zakaz czytania danych z transakcji niezatwierdzonych, a więc czytać można tylko dane zatwierdzone (ted) 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ówcz 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 (c) T Pankowski, Transakcje 37 (c) T Pankowski, Transakcje 38 Poziom izolacji 1 (READ UNCOMMITTED) (cd) 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 te rodzaju współbieżności operacji eliminuje brak odtwarzalności oraz kkadę odrzuceń Na tym poziomie izolacji mogą jednak wystąpić zarówno anomalia powtórne czytania, jak i zjawisko fantomów Poziom izolacji 2 (REPEATABLE READ) 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 natomit 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órne czytania (c) T Pankowski, Transakcje 39 (c) T Pankowski, Transakcje 40

Poziom izolacji 2 (REPEATABLE READ) (cd) 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 te rodzaju współbieżności operacji eliminuje brak odtwarzalności, kkadę odrzuceń oraz anomalię powtórne 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ć tylko wtedy, gdy jest to naprawdę konieczne Poziom izolacji 3 (SERIALIZABLE) Poziom izolacji 3 rozwiązuje problem fantomów Wymaga to poszerzenia rozważanych dotychcz 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 szerewalna, a więc jest równoważna pewnej historii szerewej (tj takiej, gdzie wszystkie operacje jednej transakcji poprzedzają wszystkie operacje innej transakcji) (c) T Pankowski, Transakcje 41 (c) T Pankowski, Transakcje 42 Poziom izolacji 3 (SERIALIZABLE) (cd) Poziom izolacji 3 (SERIALIZABLE) (cd) 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[ψ] Pojęcie współbieżności operacji rozszerzamy obecnie ntę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ązane 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 = (c) T Pankowski, Transakcje 43 (c) T Pankowski, Transakcje 44

Poziom izolacji 3 (SERIALIZABLE) (cd) 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ść) Poziomy izolacji przetwarzania transakcji podsumowanie Przyjęcie określone 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 te 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ć tylko wtedy, gdy jest to naprawdę konieczne (c) T Pankowski, Transakcje 45 (c) T Pankowski, Transakcje 46 Przetwarzanie transakcji na różnych poziomach izolacji 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 ntępującej postaci: Poziom izolacji READ UNCOMMITTED przykład Przy poziomie izolacji 0 możliwe jest czytanie danych zmienionych przez transakcje jeszcze nie zatwierdzone Mówi się wówcz o brudnym czytaniu Dopuszczenie takie 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ą komy SET TRANSACTION ISOLATION LEVEL (c) T Pankowski, Transakcje 47 (c) T Pankowski, Transakcje 48

Poziom izolacji READ UNCOMMITTED przykład Historia przetwarzania transakcji na poziomie izolacji READ UNCOMMITTED: zapis odczyt Transakcja T1: Transakcja T2: set transaction isolation level read ted set transaction isolation level read unted Poziom izolacji READ COMMITTED przykład Historia przetwarzania transakcji na poziomie izolacji READ COMMITTED: odczyt zapis: Transakcja T1: Transakcja T2: set transaction isolation level read ed set transaction isolation level read ted update Procesor set Cena = 300 where Nazwa = '200MMX' T1 zmienia cenę rollback T1 wycofuje zmianę select Cena from Procesor where Nazwa = '200MMX' T2 czyta zmienioną cenę (300) T2 ma niepoprawną informację o cenie (300 zamit 320) (c) T Pankowski, Transakcje 49 select Cena, Stan from Procesor where Nazwa = '200MMX T1 czyta cenę i stan towaru (320, 20) update Procesor set Cena = 310 where Nazwa = '200MMX' T2 zmienia cenę wczytaną przez T1 select sum(cena*stan) from Procesor where Nazwa = '200MMX T1 czeka na zakończenie T2 Wykonanie oczekującej operacji select dla T1 Wynik sprzeczny z poprzednią operacją select (zwracana wartość: 310*20 = 6200) (c) T Pankowski, Transakcje 50 Poziom izolacji REPEATABLE READ przykład 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 ntępnym slajdzie Poziom izolacji REPEATABLE READ przykład Historia przetwarzania transakcji na poziomie izolacji REPEATABLE READ: odczyt zapis odczyt: Transakcja T1: Transakcja T2: set transaction isolation level repeatable read set transaction isolation level repeatable read select Cena, Stan from Procesor where Nazwa = '200MMX T1 czyta cenę i stan towaru (320, 20) update Procesor set Cena = 310 where Nazwa = '200MMX' T2 czeka na zakończenie T1 select sum(cena*stan) from Procesor where Nazwa = '200MMX T1 oblicza wartość towaru (320*20 = 6400) Wykonanie oczekującej operacji update dla T2 (c) T Pankowski, Transakcje 51 (c) T Pankowski, Transakcje 52

Poziom izolacji REPEATABLE READ przykład Historia przetwarzania transakcji na poziomie izolacji REPEATABLE READ: odczyt dołączanie odczyt: Transakcja T1: Transakcja T2: set transaction isolation level repeatable read set transaction isolation level repeatable read Poziom izolacji SERIALIZABLE przykład Historia przetwarzania transakcji na poziomie izolacji SERIALIZABLE: odczyt dołączanie odczyt: Transakcja T1: Transakcja T2: set transaction isolation level serializable set transaction isolation level repeatable read select Cena, Stan from Procesor where Nazwa = '200MMX T1 czyta cenę i stan towaru (320, 20) select sum(cena*stan) from Procesor where Nazwa = '200MMX T1 oblicza wartość towaru (6400 + 2500) insert into Procesor values('200mmx', 250, 10) T2 dołącza nową krotkę, fantom select Cena, Stan from Procesor where Nazwa = '200MMX T1 czyta cenę i stan towaru (320, 20) select sum(cena*stan) from Procesor where Nazwa = '200MMX T1 oblicza wartość towaru (6400) insert into Procesor values('200mmx', 250, 10) T2 czeka na zakończenie T1 Wykonanie insert przez T2 (c) T Pankowski, Transakcje 53 (c) T Pankowski, Transakcje 54 Przykład: transakcja T1 Przykład: transakcja T2 300 300 (c) T Pankowski, Transakcje 55 (c) T Pankowski, Transakcje 56

Przykład: transakcja T3 300 (c) T Pankowski, Transakcje 57