PODSTAWY BAZ DANYCH 11. Transakcje 1
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) 2
Zbiór cech transakcji - Niepodzielność 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. 3
Zbiór cech transakcji Spójność stanu - Trwałość 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. Trwałość (Durability) Niedokończenie transakcji spowodowane błędami środowiska systemowego nie może doprowadzić do uszkodzenia żadnej z baz. 4
Zbiór cech transakcji Wyłączność - Szeregowalność 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). 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. 5
Przyczyny powodujące zał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. 3. Awarie dysku. Błędy zapisu lub odczytu danych z powierzchni dyskowych podczas wykonywania transakcji. 4. Przyczyny zewnętrzne. Wynikające z zaniku napięcia, przypadkowego lub celowego zamazanie danych przez operatora, pożaru, kradzieży, itp. 6
Przyczyny powodujące załamanie procesu wykonania transakcji 5. 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. 6. 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 7
Strata zapisanej informacji, np. dla transakcji T 1 i T 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) 8
Odczytanie niepoprawnej informacji w funkcjach agregujących (2) 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 tych 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 w jakiś sposób rozstrzygających ewentualne konflikty. 9
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. 10
Teoria szeregowalności Dla potrzeb teorii szeregowalności, wprowadźmy pewne 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) 11
Teoria szeregowalności Definicja. Harmonogram zbioru transakcji nazywamy sekwencyjnym (serial) jeśli wszystkie operacje każdej transakcji występują kolejno po sobie. T 1 T 2 1. READ(X) 2. X=X-1 3. WRITE(X) 4. READ(X) 5. X=X-2 6. WRITE(X) Definicja. Harmonogram zbioru transakcji nazywamy szeregowalnym (serializable), jeśli jego wynik jest równoważny wynikowi otrzymanemu za pomocą pewnego harmonogramu sekwencyjnego. 12
Teoria szeregowalności Poniższy przykład uwidacznia różnice pomiędzy harmonogramem sekwencyjnym, szeregowalnym i nieszeregowalnym. 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); T 2 : READ(B); READ(C); B=B+10; WRITE(B); B=B-20; WRITE(B); C=C+20; WRITE(C); 13
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ą). 14
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. 15
Teoria szeregowalności a) harmonogram sekwencyjny T 1 T 2 A=10, B=20, C=30 A=10, B=20, C=30 1. READ(A) 2. A=A-10 3. WRITE(A) A=0 4. READ(B) 5. B=B+10 6. WRITE(B) A=0, B=30 7. READ(B) 8. B=B-20 9. WRITE(B) A=0, B=10, C=30 10. READ(C) 11. C=C+20 12. WRITE(C) A=0, B=10, C=50 16
Teoria szeregowalności b) harmonogram szeregowalny, niesekwencyjny T 1 T 2 A=10, B=20, C=30 A=10, B=20, C=30 1. READ(A) 2. READ(B) 3. A=A-10 4. B=B-20 5. WRITE(A) A=0 6. WRITE(B) B=0 7. READ(B) 8. READ(C) 9. B=B+10 10. C=C+20 C=50 11. WRITE(B) B=10 12. WRITE(C) A=0, B=10, C=50 17
Teoria szeregowalności c) harmonogram nieszeregowalny T 1 T 2 A=10, B=20, C=30 A=10, B=20, C=30 1. READ(A) 2. A=A-10 3. READ(B) 4. WRITE(A) A=0 5. B=B-20 6. READ(B) B=20 7. WRITE(B) B=0 8. B=B+10 9. READ(C) 10. WRITE(B) B=30 11. C=C+20 C=50 12. WRITE(C) A=0, B=30, C=50 18
Teoria szeregowalności Istnieją dwie metody zapewnienia szeregowalności we 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, odpowiedzialnych 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. 19
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. 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. 20
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 (trudna w realizacji) pesymistyczna - oparta na blokadzie dostępu do danych uniemożliwiając dokonywania zmian na pewnych danych. 21
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 może być rekordem postaci <id obiektu bazy, stan blokady>. Rekordy te mogą być na przykład przechowywane w pewnych tabelach np. gdy blokowanie jest na poziomie wiersza może to być tabela: ROWID Stan_blokady AAAQ2UAAEAAABYGAAA LOCK...... 22
Mechanizm blokad - Blokowanie binarne Każda transakcja, chcąca wykorzystać wartość danej X, musi zawierać w swojej treści polecenia wykonania operacji LOCK(X) i UNLOCK(X). O tym czy transakcja otrzyma prawo dostępu do obiektu, decyduje proces systemu zarządzania bazą danych nazywany menadżerem blokad (lock manager). Może on postępować według następującego algorytmu: 23
Mechanizm blokad - Blokowanie binarne gdy transakcja żąda dostępu do obiektu X jeżeli LOCK(X)= =0 to LOCK(X)=1 //tzn. obiekt nie jest zablokowany przez inną transakcję //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. 24
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ć operacji LOCK(X) jeżeli już posiada blokadę X 4. T nie może wykonać UNLOCK(X) o ile nie wykonała wcześniej operacji LOCK(X) 25
Mechanizm blokad - Blokowanie binarne Uwagi. 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ć. 26
Mechanizm blokad - Blokowanie binarne Uwagi. 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). 27
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 zapisu (READ_LOCK) żadna transakcja nie może aktualizować obiektu, który został zamknięty tą blokadą przez jakąkolwiek inną 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 - read-sharable) 28
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). Zależności pomiędzy poszczególnymi trybami blokowania przez transakcje T1 i T2 możemy przedstawić w tabeli: T1 T2 READ_LOCK(X) WRITE_LOCK(X) READ_LOCK(X) dozwolony niedozwolony WRITE_LOCK(X) niedozwolony niedozwolony Jak widać blokada zapisu (READ_LOCK) przez jedną transakcję nie wyklucza możliwości zastosowania takiej samej blokady na tym samym obiekcie przez inną transakcję. 29
Mechanizm blokad - Blokowanie zapisu i blokowanie aktualizacji Realizację programową opisanego sposobu blokowania, możemy zapewnić poprzez wykorzystanie rekordów postaci <id obiektu, stan blokady, ilość blokad READ_LOCK >. 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. 30
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; nie próbuje całkowicie zablokować jednostki (WRITE_LOCK), którą już w ten sposób blokuje; nie próbuje zablokować do zapisu jednostki (READ_LOCK), którą blokuje w jakikolwiek sposób. 31
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ł: 32
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) 33
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) 34
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) ] 35
Protokół dwufazowy i sprawdzanie szeregowalności Szeregowalność danego 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. 36
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) R -> W W -> W (W_L) U -> R (W_L) 37
Protokół dwufazowy i sprawdzanie szeregowalności Graf pierwszeństwa jest postaci: T1 T2 T4 T3 Ponieważ graf pierwszeństwa dla naszego harmonogramu zawiera cykle więc nasz harmonogram nie jest szeregowalny. 38
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. T1 T2 T1 T2 T4 T3 T4 T3 Po wycofaniu T4 będzie szeregowalny. Po wycofaniu T2 nie będzie szeregowalny. 39
Protokół dwufazowy i sprawdzanie szeregowalności Uwaga. Jak widać z poprzedniego przykładu sam mechanizm blokad nie zapewnia szeregowalności dowolnego harmonogramu wykonania transakcji. Stąd też nie gwarantuje utrzymania bazy danych w stanie spójnym. 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. 40
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. 41
Protokół dwufazowy i sprawdzanie szeregowalności Pewne przypadki ograniczające współbieżność: 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. 42
Protokół dwufazowy i sprawdzanie szeregowalności 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. 43
Protokół dwufazowy i sprawdzanie szeregowalności Protokół blokowania dwufazowego zapewnia szeregowalność 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. 44
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 danego 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. 45
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ędzie obsłużony. Obsługuje ona transakcje w kolejności zgłoszenia potrzeby zablokowania. 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ę. 46
Zakleszczenie Możliwość powstania tego problemu tzn. zakleszczenia 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ć całkowitą blokadę na jednostkę B, ale musi czekać, bo jest ona zablokowana przez T 2 4. T 2 chce nałożyć całkowitą blokadę na jednostkę A, ale musi czekać, bo jest ona zablokowana przez T 1 47
Zakleszczenie T 1 T 2 1 WRITE_LOCK(A) 2 WRITE_LOCK(B) 3 WRITE_LOCK(B) 4 WRITE_LOCK(A) 5...... 6 Jak widać z powyższej sytuacji ani transakcja T 1 ani T 2 nie mogą być kontynuowane - występuje zakleszczenie. 48
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. 49
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. 50
Zakleszczenie W wykrywaniu zakleszczenia może być pomocne generowanie grafu bieżących transakcji według następującej reguły: jeśli transakcja T 1 żąda blokady jednostki, która jest zablokowana przez transakcję T 2, wówczas węzły T 1 i T 2 łączymy krawędzią. Przykład. T 1 T 2 1 WRITE_LOCK(A) 2... 3 WRITE_LOCK(B) 4... 5 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 51
Zakleszczenie Waiting_tran (czekająca) A Waited_tran B B C lista transakcji B F oczekujących F G G A ( ten rekord stworzy cykl i wykaże zakleszczenie ) Graf bieżących transakcji dla powyższych transakcji: 52
Przykład transakcji w Oracle Przykłady transakcji w Oracle: SET TRANSACTION NAME t1 ;... UPDATE zatrudnienia SET pensja=pensja*1.2 WHERE pensja<1000;... ROLLBACK; lub COMMIT; 53
Przykład transakcji w Oracle Przykłady transakcji w Oracle: SAVEPOINT t1;... UPDATE zatrudnienia SETpensja=pensja*2 WHERE pensja<1000;... ROLLBACK; lub ROLLBACK TO SAVEPOINT t1; SAVEPOINT t1;... UPDATE zatrudnienia SET pensja=pensja*2 WHERE pensja<1000;... COMMIT; 54
PODSTAWY BAZ DANYCH 12. Współbieżność w systemie Oracle 55
Współbieżność w systemie Oracle - Wstęp Wszystkie operacje wykonywane w Oracle odbywają się w trybie transakcyjnym. Z transakcjami wiąże się ściśle zjawisko blokowania danych. Blokowanie danych ma na celu zapewnienie synchronizacji zapisów. Polecenia z grupy DDL (np. Create, Alter, Drop Table) oraz polecenia z grupy DCL (Grant, Revoke) kończą się niejawnym zatwierdzeniem transakcji. 56
Współbieżność w Oracle Tryby w jakich może pracować transakcja Transakcja może być realizowana w jednym z trzech trybów: Tryb READ COMMITTED. (domyślny) Tryb READ ONLY. Tryb SERIALIZABLE. Do ustawiania trybu pracy transakcji służy polecenie: SET TRANSACTION { READ ONLY ISOLATION LEVEL { SERIALIZABLE READ COMMITTED } nazwa_transakcji; 57
Współbieżność w Oracle Tryb READ COMMITED Tryb READ COMMITTED Wszystkie transakcje w Systemie Oracle wykonywane są domyślnie w tym trybie. Transakcja T 1 widzi dane zmodyfikowane przez transakcję T 2 dopiero po jej zatwierdzeniu poleceniem COMMIT. Polecenie umożliwiające przestawienie pojedynczej transakcji w tryb Read Commited: SET TRANSACTION ISOLATION LEVEL Read Committed; 58
Współbieżność w Oracle Tryb READ COMMITED Uwaga. Polecenie należy wykonać jako pierwsze w ramach transakcji: SET TRANSACTION NAME t1 ; SET TRANSACTION ISOLATION LEVEL Read Committed;... COMMIT; Polecenie umożliwiające ustawienie trybu Read Committed dla wszystkich transakcji realizowanych w ramach danej sesji: ALTER SESSION SET ISOLATION_LEVEL = Read Committed; 59
Współbieżność w Oracle Tryb READ ONLY Tryb READ ONLY Transakcja T 1 operuje na wersji danych z momentu jej rozpoczęcia. Transakcja w tym trybie nie może modyfikować danych. Nie widzi zmian wprowadzonych w między czasie przez inne, zatwierdzone transakcje. Tryb Read Only stosowany jest w przypadku obliczeń analitycznych. 60
Współbieżność w Oracle Tryb READ ONLY Polecenie umożliwiające przestawienie pojedynczej transakcji w tryb Read Only: SET TRANSACTION Read Only; Uwaga. Polecenie należy wykonać jako pierwsze w ramach transakcji: SET TRANSACTION NAME t1 ; SET TRANSACTION Read Only;... COMMIT; 61
Współbieżność w Oracle Tryb Serializable Tryb SERIALIZABLE Transakcja w trybie Serializable, podobnie jak transakcja w trybie Read Only, operuje na wersji danych z momentu jej rozpoczęcia. Różnica polega na tym, że można modyfikować dane, które nie zostały zmienione przez inne transakcje w trakcie jej trwania. Polecenie umożliwiające przestawienie pojedynczej transakcji w tryb Serializable: SET TRANSACTION ISOLATION LEVEL Serializable; Uwaga. Polecenie należy wykonać jako pierwsze w ramach transakcji. 62
Współbieżność w Oracle Mechanizm blokowania danych Mechanizm blokowania danych. Blokady zakładane są na czas trwania transakcji. Dwie blokady są ze sobą zgodne jeżeli mogą być założone na tę samą daną przez wiele transakcji. Blokowanie może dotyczyć: tabeli (table lock), rekordu (row lock). Blokowanie całej tabeli zmniejsza stopień współbieżności. Blokowanie całej tabeli powoduje, że blokada dotyczy wszystkich jej rekordów a co za tym idzie system nie musi blokować każdego z nich oddzielnie. 63
Współbieżność w Oracle Mechanizm blokowania danych Operacja SELECT nie wymaga nakładania blokady na tabeli i rekordzie. Blokowanie rekordów odbywa się zawsze w trybie EXCLUSIVE. Blokowanie tabeli odbywa się w trybie RS, RX, S, SRX oraz X gdzie: RS RX S SRX X ROW SHARE ROW EXCLUSIVE SHARE SHARE ROW EXCLUSIVE EXCLUSIVE 64
Współbieżność w Oracle Mechanizm blokowania danych Zgodność blokad tabeli: Brak RS RX S SRX X Brak TAK TAK TAK TAK TAK TAK RS TAK TAK TAK TAK TAK Nie RX TAK TAK TAK Nie Nie Nie S TAK TAK Nie TAK Nie Nie SRX TAK TAK Nie Nie Nie Nie X TAK Nie Nie Nie Nie Nie Blokady mogą być nałożone w następujący sposób: niejawny - w momencie wykonywania operacji modyfikujących dane, jawny nałożenie blokady następuje po wydaniu polecenia LOCK TABLE. 65
Współbieżność w Oracle Mechanizm blokowania danych Do jawnego założenia blokady na tabeli służy polecenie: LOCK TABLE { table view } [ PARTITION ( partition ) ] [, { table view } [ { PARTITION ( partition ) ]... IN tryb_blokady MODE [ NOWAIT ]; gdzie tryb_blokady jest identyfikatorem jednego z dostępnych trybów blokowania podany pełną nazwą. 66
Współbieżność w Oracle Właściwości blokad ROW SHARE WŁAŚCIWOŚCI BLOKADY RS (ROW SHARE) Pozwala na współbieżny dostęp ( SELECT, UPDATE, DELETE, INSERT) do zablokowanej tabeli, ale nie pozwala jej zablokować innym użytkownikom w trybie EXCLUSIVE (wyłącznym) LOCK TABLE osoby IN ROW SHARE MODE; Jej założenie następuje automatycznie przy realizacji polecenia: SELECT lista_atrybutów FROM nazwa_tabeli WHERE warunek_selekcji FOR UPDATE [NOWAIT]; Użycie NOWAIT powoduje, że polecenie zostanie automatycznie przerwane, jeżeli nie można założyć blokady RS ze względu na istnienie innej blokady z nią niezgodnej. 67
Współbieżność w Oracle Właściwości blokad ROW EXCLUSIVE WŁAŚCIWOŚCI BLOKADY RX (ROW EXCLUSIVE) Tak jak, powyżej, ale dodatkowo nie pozwala zablokować innym w trybie SHARE. LOCK TABLE osoby IN ROW EXCLUSIVE MODE; Blokada ROW EXCLUSIVE pojawia się automatycznie przy UPDATE, INSERT i DELETE. Modyfikowane rekordy są zawsze blokowane w trybie EXCLUSIVE (X). Pojawienie się blokady tego typu oznacza, że niektóre lub wszystkie rekordy tabeli zostały zmodyfikowane. 68
Współbieżność w Oracle Właściwości blokad ROW SHARE WŁAŚCIWOŚCI BLOKADY S (SHARE) Zakładana jest gdy transakcja T 1 chce uniemożliwić zmianę danych w tabeli przez inne równolegle działające transakcje i jednocześnie sama nie będzie ich modyfikowała. Pozwala na współbieżne zapytania, ale zabrania operacji UPDATE na zablokowanej tabeli. LOCK TABLE osoby IN SHARE MODE; Transakcje nie zmieniające zawartości tabeli mogą współpracować z transakcją T 1. 69
Współbieżność w Oracle Właściwości blokad SHARE ROW EXCLUSIVE WŁAŚCIWOŚCI BLOKADY SRX (SHARE ROW EXCLUSIVE) Pozwala wszystkim widzieć całą tabelę, ale zabrania zarówno operacji UPDATE jak i zablokowania jej w trybie SHARE. LOCK TABLE osoby IN SHARE ROW EXCLUSIVE MODE; 70
Współbieżność w Oracle Właściwości blokad EXCLUSIVE WŁAŚCIWOŚCI BLOKADY X (EXCLUSIVE) Uniemożliwia innym transakcjom modyfikowanie danych dopuszczając tylko ich przeglądanie. Założenie innej blokady nie jest możliwe. LOCK TABLE osoby IN EXCLUSIVE MODE; Gdy zastosowano opcje NOWAIT Oracle zwraca sterowanie natychmiast, jeśli podana do zablokowania tabela jest już zablokowana przez innego użytkownika (podaje odpowiedni komunikat). Bez tego słowa Oracle będzie czekał, aż będzie można założyć pożądaną blokadę. 71
Współbieżność w Oracle Właściwości blokad EXCLUSIVE Przykład. Transakcja z blokowaniem. SET TRANSACTION NAME t1 ; LOCK TABLE zatrudnienia IN EXCLUSIVE MODE; UPDATE zatrudnienia SET pensja=pensja*1.2 WHERE pensja<1000; ROLLBACK; /*tabela zatrudnienia zostaje zwolniona */ Punkt zachowania został utworzony. Tabela(e) zablokowana(e). 2 wierszy zostało zmodyfikowanych. Wycofywanie zostało zakończone. 72
Współbieżność w Oracle Właściwości blokad Uwagi Uwagi. 1. W przypadku blokowania perspektywy (view) Oracle zablokuje bazowe tabele widoku. 2. W przypadku partycji Oracle najpierw niejawnie uzyska blokadę na całej tabeli. Będzie ona tego samego trybu co wyszczególniona blokada dla partycji. LOCK TABLE faktury PARTITION(m_10_2003) IN SHARE MODE; 73
Współbieżność w Oracle - Zakleszczenie Zakleszczenia (deadlocks) Zaletą metody blokowania danych jest zapewnienie synchronizacji zapisu w przypadku wielu transakcji próbujących modyfikować te same dane. Metoda ta posiada jednak dwie wady: zmniejsza stopień współbieżności (transakcja, która próbuje założyć blokady niezgodne z blokadami już założonymi przez inną transakcję, musi czekać na zdjęcie blokad); wprowadza możliwość wystąpienia zakleszczenia (deadlock), kiedy dwie transakcje blokują sobie wzajemnie zasoby. Wówczas żadna z transakcji nie może kontynuować pracy. 74
Współbieżność w Oracle - Zakleszczenie System Oracle wykrywa zakleszczenie i rozwiązuje je wykorzystując pewien algorytm wyboru tej transakcji, która zostanie przerwana, tj. jej ostatnie polecenie zostanie przerwane, wycofane. Przykład. Przykład wystąpienia zakleszczenia. Pierwsza sesja: 1. SET TRANSACTION NAME 't1'; 3. SELECT * FROM osoby FOR UPDATE; 5. SELECT * FROM zatrudnienia FOR UPDATE; Druga sesja: 2. SET TRANSACTION NAME 't2'; 4. SELECT * FROM zatrudnienia FOR UPDATE; 6. SELECT * FROM osoby FOR UPDATE; 75
Współbieżność w Oracle - Zakleszczenie Właściciel transakcji, dla której nastąpiło zakleszczenie otrzymuje wówczas komunikat: ORA-.: deadlock detected while waiting for resource Algorytm wyboru transakcji do przerwania nie został wyspecyfikowany w dokumentacji Oracle. 76