PODSTAWY BAZ DANYCH Wykład 9

Transkrypt

1 PODSTAWY BAZ DANYCH Wykład 9 7. Transakcje Podstawy teoretyczne 2005/2006 Wykład "Podstawy baz danych" 1

2 Zbiór cech transakcji Transakcja jest to zespół operacji na bazie danych (INSERT, UPDATE, DELETE ) charakteryzujący się następującymi własnościami: Niepodzielność (Atomicity) Spójność stanu (Consistency) Trwałość (Durability) Wyłączność (Isolation) Szeregowalność (Serializability) 2005/2006 Wykład "Podstawy baz danych" 2

3 Zbiór r cech transakcji Niepodzielność (Atomicity) Transakcja musi być niepodzielną jednostką przetwarzania i może zostać zrealizowana w całości, albo nie zrealizowana w ogóle. Realizacja transakcji nie może zakłócić poprawności danych. Przez stan poprawny danych rozumiemy taki stan, w którym wszystkie wartości atrybutów obiektów występujących w bazie mają stan zgodny z oczekiwaniami, tzn. wartość należącą do zbioru wartości danego atrybutu i właściwie odzwierciedlającą stan modelowanej rzeczywistości. 2005/2006 Wykład "Podstawy baz danych" 3

4 Zbiór r cech transakcji Spójność stanu (Consistency) Poprawne wykonanie transakcji musi przeprowadzić bazę z jednego stanu spójnego w drugi. Stan spójny, to taki, w którym wszelkie istniejące powiązania pomiędzy obiektami tworzą logiczną całość tzn. np. nie ma odwołań do obiektów nie istniejących w bazie. 2005/2006 Wykład "Podstawy baz danych" 4

5 Zbiór r cech transakcji Trwałość (Durability) Niedokończenie transakcji spowodowane błędami środowiska systemowego nie może doprowadzić do uszkodzenia żadnej z baz. Wyłączność (Isolation) Zmiany wprowadzane przez transakcję do bazy danych nie mogą być widoczne dla innych transakcji aż do momentu ich ostatecznego zatwierdzenia (zrealizowania transakcji w całości). 2005/2006 Wykład "Podstawy baz danych" 5

6 Zbiór r cech transakcji Następna własność dotyczy kilku transakcji wykonywanych jednocześnie. Szeregowalność (Serializability) Efekt wykonania kilku transakcji jednocześnie (z przełączaniem zadań) musi być równoważny oddzielnemu wykonaniu każdej z nich w pewnej ustalonej kolejności. Wówczas transakcje takie nazywamy szeregowalnymi. 2005/2006 Wykład "Podstawy baz danych" 6

7 Przyczyny powodujące załamanie amanie procesu wykonania transakcji 1.Błąd systemu komputerowego (system crash). Awarie związane z oprogramowaniem lub sprzętem, zaistniałe podczas wykonywania transakcji. Prawie zawsze związane z utratą zawartości pamięci operacyjnej komputera. 2.Błąd transakcji lub SZBD. Załamanie wykonania może być spowodowane np. próbą wykonania przez transakcję operacji dzielenia przez zero, przekroczeniem zakresu typu danych, niewłaściwą wartością parametru lub poleceniem BREAK wydanym przez operatora. 2005/2006 Wykład "Podstawy baz danych" 7

8 Przyczyny powodujące załamanie amanie procesu wykonania transakcji 3.Błędy lokalne i wyjątki wykryte przez transakcję. Przykładem okoliczności zmuszających do przerwania transakcji jest np. w bankowej bazie danych, niewystarczający stan konta, uniemożliwiający wykonanie operacji przelewu pieniędzy. Transakcja sama powinna obsłużyć sytuację, wykonując operację ABORT. 4. Awarie dysku. Błędy zapisu lub odczytu danych z powierzchni dyskowych podczas wykonywania transakcji. 2005/2006 Wykład "Podstawy baz danych" 8

9 Przyczyny powodujące załamanie amanie procesu wykonania transakcji 5. Kontrola współbieżności. Procesy bazy odpowiedzialne za kontrolę dostępu równoległego mogą zadecydować o konieczności przerwania transakcji i jej późniejszym restarcie. Przyczyną może być niespełnienie warunku szeregowalności czy też wykrycie stanu zakleszczenia. 6. Przyczyny zewnętrzne. Wynikające z zaniku napięcia, przypadkowego lub celowego zamazanie danych przez operatora, pożaru, kradzieży, itp. 2005/2006 Wykład "Podstawy baz danych" 9

10 Strata zapisanej informacji, np. dla transakcji T i T 1 2 Ogólnie mówiąc problemy, które mogą wyniknąć przy jednoczesnym działaniu wielu transakcji równocześnie, można podzielić na dwie kategorie: (1) W wyniku wykonania takiej sekwencji operacji, otrzymujemy niepoprawną końcową wartość X, tracona jest informacja zapisana przez transakcję T 1 T 1 T 2 1. READ(X) 2. READ(X) 3. X=X-1 4. WRITE(X) 5. X=X-2 6. WRITE(X) 2005/2006 Wykład "Podstawy baz danych" 10

11 (2) Odczytanie niepoprawnej informacji w funkcjach agregujących T 1 T 3 1. sum=0 2. READ(A) 3. sum=sum+a 4. READ(X) 5. READ(X) 6. X=X-1 7. WRITE(X) 8. sum=sum+x 9. READ(Y) 10. sum=sum+y Wartość X odczytana przez transakcję T 3 obliczającą sumę A+X+Y nie jest poprawna, gdyż w międzyczasie obliczeń, transakcja T 1 zdążyła ją zaktualizować. Widać więc jak istotne jest wprowadzenie mechanizmów synchronizujących dostęp do bazy danych i rozstrzygających ewentualne konflikty. 2005/2006 Wykład "Podstawy baz danych" 11

12 Teoria szeregowalności Ponieważ zawsze jest możliwe, aby transakcje były wykonywane po kolei (sekwencyjnie), jest sensownie zakładać, że normalny lub zamierzony wynik jest taki sam jak wynik otrzymany wtedy, kiedy nie jest wykonywana współbieżnie żadna inna transakcja. Załóżmy więc, że współbieżne wykonanie kilku transakcji jest poprawne wtedy i tylko wtedy, gdy jego wynik jest taki sam jak wynik otrzymany przy sekwencyjnym wykonaniu tych samych transakcji w pewnej kolejności. 2005/2006 Wykład "Podstawy baz danych" 12

13 Teoria szeregowalności Dla potrzeb teorii szeregowalności, wprowadźmy potrzebne definicje. Definicja. Kolejność, w której są wykonywane elementarne operacje transakcji (blokowanie, odczyt, zapis, itd.) nazywamy harmonogramem zbioru transakcji. T 1 1. READ(X) T 2 2. READ(X) 3. X=X-1 4. WRITE(X) 5. X=X-2 6. WRITE(X) 2005/2006 Wykład "Podstawy baz danych" 13

14 Teoria szeregowalności Definicja. Harmonogram zbioru transakcji nazywamy sekwencyjnym (serial) jeśli wszystkie operacje każdej transakcji występują kolejno po sobie. T 1 1. READ(X) T 2 2. X=X-1 3. WRITE(X) 4. READ(X) 5. X=X-2 6. WRITE(X) 2005/2006 Wykład "Podstawy baz danych" 14

15 Teoria szeregowalności Definicja. Harmonogram zbioru transakcji nazywamy szeregowalnym (serializable), jeśli jego wynik jest równoważny wynikowi otrzymanemu za pomocą pewnego harmonogramu sekwencyjnego. Poniższy przykład uwidacznia różnice pomiędzy harmonogramem sekwencyjnym, szeregowalnym i nieszeregowalnym. 2005/2006 Wykład "Podstawy baz danych" 15

16 Teoria szeregowalności Przykład. Rozważmy dwie transakcje przeksięgowania kwot pieniężnych z konta na konto T 1 : READ(A); A=A-10; WRITE(A); READ(B); B=B+10; WRITE(B); T 2 : READ(B); B=B-20; WRITE(B); READ(C); C=C+20; WRITE(C); 2005/2006 Wykład "Podstawy baz danych" 16

17 Teoria szeregowalności Każdy harmonogram sekwencyjny powyższych transakcji ma własność zachowania sumy A+B+C. Przestawienia kolejności wykonywania pojedynczych operacji wewnątrz transakcji, mogą doprowadzić do stworzenia harmonogramów niesekwencyjnych ale szeregowalnych (sytuacja pożądana) albo nieszeregowalnych, (sytuacja niepożądaną). 2005/2006 Wykład "Podstawy baz danych" 17

18 Teoria szeregowalności Poniższe przykłady, to: a) harmonogram sekwencyjny b) harmonogram szeregowalny, niesekwencyjny c) harmonogram nieszeregowalny, dla którego nie istnieje żaden harmonogram sekwencyjny tego samego zbioru transakcji dający takie same wyniki. 2005/2006 Wykład "Podstawy baz danych" 18

19 Teoria szeregowalności a) harmonogram sekwencyjny 1. READ(A) 2. A=A WRITE(A) 4. READ(B) 5. B=B WRITE(B) T 1 T 2 7. READ(B) 8. B=B WRITE(B) 10. READ(C) 11. C=C WRITE(C) A=10, B=20, C=30 A=10, B=20, C=30 A=0 A=0, B=30 A=0, B=10, C=30 A=0, B=10, C= /2006 Wykład "Podstawy baz danych" 19

20 Teoria szeregowalności b) harmonogram szeregowalny, niesekwencyjny 1. READ(A) T 1 T 2 2. READ(B) 3. A=A B=B WRITE(A) 6. WRITE(B) 7. READ(B) 8. READ(C) 9. B=B C=C WRITE(B) 12. WRITE(C) A=10, B=20, C=30 A=10, B=20, C=30 A=0 B=10 B=0 C=50 A=0, B=10, C= /2006 Wykład "Podstawy baz danych" 20

21 Teoria szeregowalności c) harmonogram nieszeregowalny 1. READ(A) 2. A=A-10 T 1 T 2 3. READ(B) 4. WRITE(A) 5. B=B READ(B) 7. WRITE(B) 8. B=B READ(C) 10. WRITE(B) 11. C=C WRITE(C) A=10, B=20, C=30 A=10, B=20, C=30 A=0 B=20 B=30 B=0 C=50 A=0, B=30, C= /2006 Wykład "Podstawy baz danych" 21

22 Teoria szeregowalności Istnieją dwie metody zapewnienia szeregowalności w współbieżnych procesach realizacji transakcji w bazach danych. Pierwsza, to zastosowanie programów szeregujących, będących częścią systemu zarządzania bazą danych, odpowiedzialną za rozstrzyganie konfliktów pomiędzy sprzecznymi żądaniami. Pogramy te mogą eliminować sytuacje zakleszczenia i nieszeregowalność poprzez przerwanie wykonania i restart w późniejszym terminie jednej bądź większej ilości transakcji. Dotychczasowe efekty działania przerwanych transakcji są wówczas wymazywane z bazy danych. 2005/2006 Wykład "Podstawy baz danych" 22

23 Teoria szeregowalności Drugą metodą jest zastosowanie protokołów, czyli zbiorów zasad jakie muszą być stosowane przez wszystkie transakcje. Zależnie od protokołu, zasady te mają różne cele: zapewnić szeregowalnośc transakcji, wyeliminować możliwość powstania zakleszczenia, itp. 2005/2006 Wykład "Podstawy baz danych" 23

24 Teoria szeregowalności Odpowiednie narzędzia (menadżery transakcji) bazy danych muszą zapewnić przestrzeganie protokołu i w przypadku naruszenia określających go zasad przez którąkolwiek z transakcji, przerwać jej wykonanie oraz przywrócić stan bazy sprzed jej startu. 2005/2006 Wykład "Podstawy baz danych" 24

25 Teoria szeregowalności Klasyczne metody synchronizacji można podzielić na dwie grupy: optymistyczna - oparta na niezależnym wykonaniu transakcji i późniejszym wykrywaniu ewentualnych konfliktów między poszczególnymi transakcjami. pesymistyczna - oparta na blokadzie dostępu do danych, 2005/2006 Wykład "Podstawy baz danych" 25

26 Mechanizm blokad - Blokowanie binarne Najprostszym rodzajem kontroli współbieżności jest blokowanie binarne. Polega ono na skojarzeniu z każdym obiektem bazy znacznika wskazującego na zezwolenie na dostęp do obiektu lub jego brak. Znacznik taki jest rekordem postaci <id obiektu bazy, stan blokady>. Każda transakcja, chcąca wykorzystać wartość danej X, musi zawierać w swojej treści polecenia wykonania operacji LOCK(X) i UNLOCK(X). 2005/2006 Wykład "Podstawy baz danych" 26

27 Mechanizm blokad - Blokowanie binarne O tym czy transakcja otrzyma prawo dostępu do obiektu, decyduje proces systemu zarządzania bazą danych nazywany menadżerem blokad (lock manager). Postępuje on według następującego algorytmu: 2005/2006 Wykład "Podstawy baz danych" 27

28 Mechanizm blokad - Blokowanie binarne gdy transakcja żąda dostępu do obiektu X jeżeli LOCK(X)==0 //tzn. obiekt nie jest zablokowany przez inną transakcję to LOCK(X)=1 //tzn. zablokuj obiekt w przeciwnym przypadku czekaj aż LOCK(X)==0 //obiekt zostanie odblokowany oraz menadżer blokad wznowi wykonywanie transakcji //transakcja jest ustawiana w kolejce transakcji //oczekujących na pożądany zasób (dane bazy) gdy transakcja zwalnia blokadę obiektu X LOCK(X)=0 //tzn. odblokuj obiekt jeśli inne transakcje czekają na dostęp do X, wybierz jedną z nich i wznów jej działanie. 2005/2006 Wykład "Podstawy baz danych" 28

29 Mechanizm blokad - Blokowanie binarne Aby zapewnić poprawność procesu blokowania binarnego, każda transakcja T musi stosować się do poniższych reguł: 1. T musi wykonać operację LOCK(X) przed którąkolwiek z operacji READ(X) lub WRITE(X) 2. T musi wykonać operację UNLOCK(X) po zakończeniu wszystkich operacji READ(X) i WRITE(X) 3. T nie może wykonać LOCK(X) jeżeli już posiada blokadę X 4. T nie może wykonać UNLOCK(X) o ile nie wykonała wcześniej LOCK(X) 2005/2006 Wykład "Podstawy baz danych" 29

30 Mechanizm blokad - Blokowanie binarne Zadanie stosowania reguł 1, 3 i 4 przejmuje na siebie właściwie funkcjonujący menadżer transakcji, natomiast reguła 2 musi być przestrzegana przez programistę aplikacji systemu bazodanowego. Efektem niezastosowania reguły 2 będzie niepotrzebne blokowanie obiektu, uniemożliwiające realizację wszystkich transakcji chcących z niego skorzystać. 2005/2006 Wykład "Podstawy baz danych" 30

31 Mechanizm blokad - Blokowanie binarne Przestrzeganie reguł 1-4 uniemożliwia jednoczesne użycie tego samego obiektu przez dwie transakcje i stąd chroni bazę przed utratą spójności danych. Transakcje wykorzystujące różne obiekty bazy mogą funkcjonować równolegle i bezkolizyjnie. Mechanizm blokowania binarnego, opisany powyżej jest prosty w implementacji. Jednakże konieczność całkowitego blokowania obiektu nawet gdy transakcja wymaga jedynie odczytu, może powodować długie kolejki transakcji oczekujących na dostęp oraz sprzyja powstaniu zakleszczenia (opisane w dalszej części). 2005/2006 Wykład "Podstawy baz danych" 31

32 Mechanizm blokad - Blokowanie zapisu i blokowanie aktualizacji Ulepszeniem powyższej metody jest mechanizm oddzielnego blokowania zapisu i odczytu. W metodzie tej możemy wyróżnić dwa rodzaje blokad: 1. blokadę do czytania (READ_LOCK) żadna transakcja nie może aktualizować obiektu, który został zamknięty do czytania przez jakąkolwiek transakcję. Natomiast możliwa jest sytuacja, że wiele transakcji czyta dane z tego samego obiektu (dlatego też ten rodzaj nazywany jest trybem dzielonego dostępu do czytania - readsharable) 2005/2006 Wykład "Podstawy baz danych" 32

33 Mechanizm blokad - Blokowanie zapisu i blokowanie aktualizacji 2. blokadę do aktualizacji (WRITE_LOCK - blokada całkowita) żadna inna transakcja, z wyjątkiem tej, która nałożyła blokadę nie ma dostępu (zarówno do czytania jak i aktualizacji) do danego obiektu (tryb wyłącznego dostępu do pisania - write-exclusive). 2005/2006 Wykład "Podstawy baz danych" 33

34 Mechanizm blokad - Blokowanie zapisu i blokowanie aktualizacji Zależności pomiędzy poszczególnymi trybami blokowania możemy przedstawić w tabeli: T 1 T 2 READ_LOCK(X) WRITE_LOCK(X) READ_LOCK(X) dozwolony niedozwolony WRITE_LOCK(X) niedozwolony niedozwolony Jak widać blokada do odczytu (READ_LOCK) przez jedną transakcję nie wyklucza możliwości zastosowania takiej samej blokady na tym samym obiekcie przez inną transakcję. 2005/2006 Wykład "Podstawy baz danych" 34

35 Mechanizm blokad - Blokowanie zapisu i blokowanie aktualizacjia Realizację programową opisanego sposobu blokowania, możemy zapewnić poprzez wykorzystanie rekordów postaci <id obiektu bazy, stan blokady, ilość blokad odczytu>. Pole stan blokady może przyjmować trzy różne wartości (odpowiednio zakodowane): zablokowane_do_odczytu, (WRITE_LOCK) zablokowane_do_aktualizacji, (READ_LOCK) niezablokowane. Obie blokady: zapisu i całkowitą usuwa operacja UNLOCK. 2005/2006 Wykład "Podstawy baz danych" 35

36 Mechanizm blokad - Blokowanie zapisu i blokowanie aktualizacji Analogicznie jak dla blokowania binarnego, transakcja musi przestrzegać pewnych reguł: wykonuje operację WRITE_LOCK lub READ_LOCK przed jakąkolwiek operacją READ; wykonuje operację WRITE_LOCK przed jakąkolwiek operacją WRITE; nie próbuje odblokować jednostki, której w żaden sposób nie blokuje; 2005/2006 Wykład "Podstawy baz danych" 36

37 Mechanizm blokad - Blokowanie zapisu i blokowanie aktualizacji nie próbuje całkowicie zablokować jednostki (WRITE_LOCK), którą już w ten sposób blokuje; nie próbuje zablokować do odczytu jednostki (READ_LOCK), którą blokuje w jakikolwiek sposób. 2005/2006 Wykład "Podstawy baz danych" 37

38 Protokół dwufazowy i sprawdzanie szeregowalności Algorytm sprawdzania szeregowalności harmonogramu S z blokadami: i zapisu (READ_LOCK) całkowitymi (WRITE_LOCK), opiera się na konstrukcji grafu zorientowanego G, w którym wierzchołki odpowiadają transakcjom, a krawędzie wyznacza się korzystając z następujących reguł: 2005/2006 Wykład "Podstawy baz danych" 38

39 Protokół dwufazowy i sprawdzanie szeregowalności 1. Jeśli transakcja T i z harmonogramu S blokuje zapis elementu A {READ_LOCK(A)},a T j jest następną transakcją (o ile taka istnieje), która chce całkowicie zablokować A {WRITE_LOCK(A)}, to prowadzimy krawędź T i T j. T i T j T i T j READ_LOCK(A) WRITE_LOCK(A) 2005/2006 Wykład "Podstawy baz danych" 39

40 Protokół dwufazowy i sprawdzanie szeregowalności 2. Jeśli transakcja T i z harmonogramu S blokuje całkowicie A {WRITE_LOCK(A)}, a T j jest następną transakcją (o ile taka istnieje), która chce całkowicie zablokować A {WRITE_LOCK(A)}, to prowadzimy krawędź T i T j. T i T j T i T j WRITE_LOCK(A) WRITE_LOCK(A) 2005/2006 Wykład "Podstawy baz danych" 40

41 Protokół dwufazowy i sprawdzanie szeregowalności 3. Jeśli T m jest transakcją blokującą zapis A {READ_LOCK(A)}, po tym, gdy T i zdjęła swoją całkowitą blokadę {UNLOCK(A)}, lecz zanim T j całkowicie zablokowała A {WRITE_LOCK(A)}, (jeśli T j nie istnieje, to T m jest dowolną transakcją blokującą zapis A po odblokowaniu jej przez T i ), to prowadzimy krawędź T i T m. T i T m T i T m T j WRITE_LOCK(A) UNLOCK(A) READ_LOCK(A)... [ WRITE_LOCK(A) ] 2005/2006 Wykład "Podstawy baz danych" 41

42 Protokół dwufazowy i sprawdzanie szeregowalności Szeregowalność harmonogramu rozstrzygamy sprawdzając istnienie cykli w tak skonstruowanym grafie (nazywanym również grafem pierwszeństwa). Jeśli G zawiera cykl, to harmonogram S nie jest szeregowalny. Twierdzenie. Przedstawiony algorytm sprawdzania szeregowalności w poprawny sposób stwierdza szeregowalność harmonogramu. Dowód poprawności powyższego algorytmu znajduje się m.in. w książce J.D Ullman Systemy baz danych. 2005/2006 Wykład "Podstawy baz danych" 42

43 Protokół dwufazowy i sprawdzanie szeregowalności W przypadku acyklicznosci (bez cykli) grafu G harmonogramu S, możemy otrzymać sekwencyjne uporządkowane transakcje według następującego algorytmu: 1. Wyznaczyć wierzchołek, który nie jest końcem żadnej krawędzi (w przeciwnym razie graf zawiera cykle) i wyrzucić go z grafu. 2. Czy usuneliśmy wszystkie wierzchołki? - jeśli nie to wracamy do punktu 1 algorytmu; - jeśli tak to przechodzimy do punktu Tworzymy ciąg transakcji według kolejności usuwania z grafu. 4. Koniec algorytmu. 2005/2006 Wykład "Podstawy baz danych" 43

44 Protokół dwufazowy i sprawdzanie szeregowalności Przykład. Dany jest graf pewnego harmonogramu dla transakcji T1, T2, T3, T4, T5: Z powyższego grafu możemy otrzymać wiele harmonogramów sekwencyjnych np.: 1. T5, T3, T2, T4, T1; 2. T5, T4, T1, T3, T /2006 Wykład "Podstawy baz danych" 44

45 Protokół dwufazowy i sprawdzanie szeregowalności Przykład. Przykład harmonogramu nieszeregowalnego. T 1 T 2 T 3 T 4 1. WRITE_LOCK (A) 2. READ_LOCK (B) 3. UNLOCK (A) 4. READ_LOCK (A) 5. UNLOCK (B) 6. WRITE_LOCK (B) 7. READ_LOCK (A) 8. UNLOCK (B) 9. WRITE_LOCK (B) 10. UNLOCK (A) 11. UNLOCK (A) 12. WRITE_LOCK (A) 13. UNLOCK (B) 14. READ_LOCK (B) 15. UNLOCK (A) 16. UNLOCK (B) 2005/2006 Wykład "Podstawy baz danych" 45

46 Protokół dwufazowy i sprawdzanie szeregowalności Graf pierwszeństwa jest postaci: Ponieważ graf pierwszeństwa zawiera cykle więc nasz harmonogram jest nieszeregowalny. 2005/2006 Wykład "Podstawy baz danych" 46

47 Protokół dwufazowy i sprawdzanie szeregowalności W przypadku wykrycia cyklu, należy uruchomić mechanizmy cofające efekt działania transakcji T powodującej konflikt, zawiadomić o fakcie program aplikacyjny lub zrestartować T w późniejszym terminie. Sam mechanizm blokad nie zapewnia szeregowalności dowolnego harmonogramu wykonania transakcji. Stąd też nie gwarantuje utrzymania bazy danych w stanie spójnym. 2005/2006 Wykład "Podstawy baz danych" 47

48 Protokół dwufazowy i sprawdzanie szeregowalności Gwarancję taką daje zastosowanie protokołu dwufazowego, którego jedynym wymaganiem jest aby transakcje wykonały blokowania wszystkich wymaganych przez siebie obiektów przed odblokowaniem któregokolwiek z nich. Transakcje, które przestrzegają tego protokołu uważane są za dwufazowe w takim sensie, że operacje zablokowania i odblokowania wykonywane są w dwóch różnych fazach w trakcie działania transakcji. Jeśli wszystkie transakcje są dwufazowe, ich równoległe wykonanie zawsze będzie szeregowalne. 2005/2006 Wykład "Podstawy baz danych" 48

49 Protokół dwufazowy i sprawdzanie szeregowalności Prawdziwe jest następujące twierdzenie. Twierdzenie. Dowolny harmonogram S transakcji dwufazowych jest harmonogramem szeregowalnym. Zaletą protokołu dwufazowego jest fakt, iż przy niewielkich wymaganiach i stosunkowo niewielkim nakładzie pracy w implementacji, gwarantuje on szeregowalność harmonogramów transakcji. Wadą natomiast jest to, że blokowanie dwufazowe może ograniczyć współbieżność w bazie danych. 2005/2006 Wykład "Podstawy baz danych" 49

50 Protokół dwufazowy i sprawdzanie szeregowalności Często zdarza się, że transakcja T nie może zwolnić blokady na obiekcie X po jego wykorzystaniu, ponieważ w dalszym planie swego działania przewiduje blokadę na innym obiekcie Y. Aby zwolnić obiekt X, transakcja musi zablokować obiekt Y wcześniej niż jest to wymagane do jej działania. Zablokowanie Y wówczas, gdy staje się on niezbędny pociąga za sobą konieczność zbędnego przetrzymania blokady X. W obu przypadkach, obiekt X musi pozostać zablokowany aż do chwili gdy T uzyska wszystkie wymagane blokowania. W tym czasie inne transakcje wymagające dostępu do X są postawione w stan oczekiwania, pomimo iż transakcja T nie korzysta już z X. Jeśli natomiast Y zostaje zablokowane przed czasem, działanie transakcji wymagających dostępu do Y jest wstrzymywane, pomimo, że T nie korzysta jeszcze z obiektu Y. 2005/2006 Wykład "Podstawy baz danych" 50

51 Protokół dwufazowy i sprawdzanie szeregowalności Protokół blokowania dwufazowego zapewnia szeregowalnośc transakcji, ale nie eliminuje możliwości wystąpienia sytuacji: zakleszczenia (deadlock) impasu (livelock), występujących we wszystkich systemach sterujących współbieżnością w oparciu o mechanizmy blokowania. Poniżej przedstawione zostaną przyczyny powstawania problemu i techniki jego eliminacji 2005/2006 Wykład "Podstawy baz danych" 51

52 Impas Mówimy, że transakcja jest w stanie impasu, jeśli nie może kontynuować pracy przez nieokreślenie długi (w stosunku do innych transakcji) czas, podczas gdy inne transakcje są realizowane bez przeszkód. Sytuacja taka może zaistnieć, gdy mechanizm przyznawania blokad (lock manager) nie jest skonstruowany poprawnie i daje pierwszeństwo pewnym typom transakcji. Niestety, praktycznie niemożliwe jest wykrycie impasu w trakcie wykonywania programu realizującego transakcje. Łatwo co prawda zaobserwować, że pewna transakcja czeka bardzo długo na zdarzenie (np. możliwość zablokowania zasobu), które wystąpiło już wiele razy, ale nie wiadomo, jak system zachowa się w przyszłości. 2005/2006 Wykład "Podstawy baz danych" 52

53 Impas Aby uniknąć problemu, należy zastosować maksymalnie optymalny menadżer blokad. Jednym z takich rozwiązań jest zastosowanie techniki kolejek FIFO: pierwszy-wszedł-pierwszy-będzieobsłużony. Obsługuje ona transakcje w kolejności zgłoszenia potrzeby zablokowania obiektu. Innym rozwiązaniem jest dopuszczenie różnych priorytetów dla różnych transakcji ale równocześnie wprowadzenie procesu podnoszenia priorytetu transakcjom długo oczekującym na blokadę. Transakcje te mogą w końcowym stadium osiągnąć najwyższy priorytet i dzięki temu mają zapewnioną realizację. 2005/2006 Wykład "Podstawy baz danych" 53

54 Zakleszczenie Możliwość powstania tego problemu najlepiej ilustruje poniższa sekwencja działań: 1. Transakcja T 1 blokuje całkowicie jednostkę A 2. Transakcja T 2 blokuje całkowicie jednostkę B 3. T 1 chce nałożyć blokadę do czytania na jednostkę B, ale musi czekać, bo jest ona zablokowana przez T 2 4. T 2 chce nałożyć blokadę do czytania na jednostkę A, ale musi czekać, bo jest ona zablokowana przez T /2006 Wykład "Podstawy baz danych" 54

55 Zakleszczenie T 1 T 2 1 WRITE_LOCK(A) 2 WRITE_LOCK(B) 3 WRITE_LOCK(B) 4 WRITE_LOCK(A) Jak widać z powyższej sytuacji ani transakcja T 1 ani T 2 nie mogą być kontynuowane - występuje zakleszczenie. 2005/2006 Wykład "Podstawy baz danych" 55

56 Zakleszczenie Można znaleźć różne strategie zapobiegające powstawaniu zakleszczeń. Przykładem jest strategia wstępnego rezerwowania obiektów (pre-claim strategy). Każda transakcja przed rozpoczęciem działania nakłada blokady na wszystkie obiekty, z których będzie korzystać w trakcie swej realizacji. Taka strategia może jednak powodować, że przy dużym stopniu jednoczesności dostępu (rozumianym jako duża liczba transakcji rywalizujących o zasoby) wiele transakcji będzie musiało długo czekać na rozpoczęcie swego działania. 2005/2006 Wykład "Podstawy baz danych" 56

57 Zakleszczenie Inną wadą tej strategii jest to, że przed rozpoczęciem realizacji nie zawsze znany jest pełen zbiór obiektów, do których będzie potrzebny dostęp. Taki zbiór może być wyznaczany dynamicznie podczas realizacji transakcji i generalnie może zależeć od danych wejściowych, stanu bazy i algorytmu transakcji. Strategia taka jest więc mało praktyczna w systemach bazodanowych. Właściwszą metodą wydaje się dopuszczenie możliwości powstawania zakleszczeń, ale równocześnie stworzenie mechanizmów do ich wykrywania i eliminowania. 2005/2006 Wykład "Podstawy baz danych" 57

58 Zakleszczenie W wykrywaniu zakleszczenia może być pomocne generowanie grafu bieżących transakcji według następującej reguły: jeśli T 1 żąda blokady jednostki, która jest zablokowana przez T 2, wówczas węzły T 1 i T 2 łączymy krawędzią. Sytuacja zakleszczenia odpowiada powstaniu cyklu w grafie. Ilustruje to poniższy przykład: 1 READ_LOCK(A) T 1 T READ_LOCK(B) WRITE_LOCK(B) 6 WRITE_LOCK(A) Graf bieżących transakcji dla T 1 i T 2 T 1 i T 2 w stanie zakleszczenia 2005/2006 Wykład "Podstawy baz danych" 58

59 Zakleszczenie Waiting_tran Waited_tran A B B C lista transakcji oczekujących B F F G G A ( ten rekord stworzy cykl i wykaże zakleszczenie ) Graf oczekiwań dla powyższych transakcji: 2005/2006 Wykład "Podstawy baz danych" 59

60 Przykład transakcji w Oracle Przykłady transakcji: SAVEPOINT t1;... UPDATE pensje SET pensja=pensja*1.2 WHERE pensja<1000;... ROLLBACK; lub ROLLBACK t1; SAVEPOINT t1;... UPDATE pensje SET pensja=pensja*1.2 WHERE pensja<1000;... COMMIT; 2005/2006 Wykład "Podstawy baz danych" 60

61 Przykład transakcji w Oracle Transakcje mogą być zagnieżdżone. SAVEPOINT t1;... SAVEPOINT t2;... ROLLBACK t2;... ROLLBACK t1; SAVEPOINT t1;... SAVEPOINT t2;... COMMIT t2;... ROLLBACK t1; 2005/2006 Wykład "Podstawy baz danych" 61