Wykład11 PDF

Plan Transakcje, odtwarzanie oraz kontrola współbieżności Transakcje i zarządzanie transakcjami Odtwarzanie Kontrola współbieżności Własności ACID transakcji 1 Transakcje, odtwarzanie i kontrola współbieżności Większość baz danych dla wielu u...

Plan Transakcje, odtwarzanie oraz kontrola współbieżności Transakcje i zarządzanie transakcjami Odtwarzanie Kontrola współbieżności Własności ACID transakcji 1 Transakcje, odtwarzanie i kontrola współbieżności Większość baz danych dla wielu użytkowników (multi user databases) Równoczesny dostęp do tych samych danych może powodować różnego rodzaju anomalie Błędy mogą wystąpić w DBMS lub jego środowisku DBMS musi wspierać własności ACID (Atomicity, Consistency, Isolation, Durability) 2  Transakcje, odtwarzanie i kontrola współbieżności Transakcja: zbiór operacji bazy danych wywoływana przez pojedynczego użytkownika lub aplikację, którą można traktować jako jedną niepodzielną jednostkę pracy – np. transfer między dwoma rachunkami bankowymi Transakcja powinna zawsze „zakończyć się sukcesem” lub „niepowodzeniem” w całości Transakcja przenosi bazę danych z jednego stanu spójnego w inny stan spójny 3  Transakcje, odtwarzanie i kontrola współbieżności Rodzaje błędów: awaria dysku twardego, awaria aplikacji/DBMS, dzielenie przez 0, … Odtwarzanie: działanie polegające na zapewnieniu, że niezależnie od tego, który z problemów wystąpił, baza danych zostanie przywrócona do spójnego stanu bez późniejszej utraty danych Kontrola współbieżności: koordynacja transakcji, które są realizowane jednocześnie na tych samych danych, tak aby nie powodowały niespójności w danych z powodu wzajemnej ingerencji 4  Transakcje i zarządzanie transakcjami Określanie transakcji i cyklu życia transakcji Komponenty DBMS zaangażowane w zarządzanie transakcjami Plik dziennika 5 Określanie transakcji i cyklu życia transakcji Granice transakcji można określić niejawnie lub jawnie – jawnie: begin_transaction and end_transaction – niejawnie: pierwsza wykonywalna instrukcja SQL Po wykonaniu pierwszej operacji transakcja jest aktywna Jeśli transakcja zakończyła się pomyślnie, można ją zatwierdzić (committed). Jeżeli nie – należy ją wycofać (rolled back). 6  Określanie transakcji i cyklu życia transakcji UPDATE account SET balance = balance - :amount WHERE accountnumber = :account_to_debit UPDATE account SET balance = balance + :amount WHERE accountnumber = :account_to_credit 7 Komponenty DBMS zaangażowane w zarządzanie transakcjami Tfurther operations 3 Transaction manager input Tn, Tn-1,..., T1, T0 input area 1 scheduler Tstarted Tactive 2 Tterminated Tcompleted 4 5a 5b Output area not ok ok Tunsuccessful Tsuccessful 5b1 5b2 abort commit 5a 5b1 5b2 recovery stored buffer manager datamanager manager database 8  Plik dziennika Plik dziennika rejestruje – unikalny numer sekwencji dziennika – unikalny identyfikator transakcji – oznaczenie początku transakcji, wraz z czasem rozpoczęcia transakcji i wskazaniem, czy transakcja jest tylko do odczytu, czy do odczytu/ zapisu – identyfikatory rekordów bazy danych zaangażowanych w transakcję, a także operacje, którym zostały poddane – obrazy przed (before images) wszystkich rekordów biorących udział w transakcji – obrazy po (after images) wszystkich rekordów, które zostały zmienione przez transakcję – aktualny stan transakcji (active, committed or aborted) 9  Plik dziennika Plik dziennika może również zawierać punkty kontrolne (checkpoints) – momenty, w których aktualizacje buforowane przez aktywne transakcje, obecne w buforze bazy danych, są natychmiast zapisywane na dysk Strategia zapisu dziennika do przodu (write ahead log) – wszystkie aktualizacje są rejestrowane w pliku dziennika przed zapisaniem na dysku – before images są zawsze rejestrowane w pliku dziennika przed nadpisaniem rzeczywistych wartości w fizycznych plikach bazy danych 10  Odtwarzanie Rodzaje awarii Odtwarzanie systemu Odtwarzanie nośników 11  Rodzaje awarii Awaria transakcji wynika z błędu w logice, która kieruje operacjami transakcji i/lub w logice aplikacji Awaria systemu występuje w przypadku awarii systemu operacyjnego lub bazy danych Awaria nośnika występuje, gdy dodatkowa pamięć masowa jest uszkodzona lub niedostępna 12  Odtwarzanie systemu W przypadku awarii systemu 2 rodzaje transakcji – osiągnęły już stan zatwierdzenia przed awarią – nadal w stanie aktywnym Plik dziennika jest niezbędny, aby uwzględnić, które aktualizacje zostały wykonane przez które transakcje (i kiedy) oraz aby śledzić obrazy przed i po, potrzebne do UNDO i REDO Strategia opróżniania bufora bazy danych ma wpływ na UNDO i REDO 13  Odtwarzanie systemu Uwaga 1: punkt kontrolny oznacza moment, w którym menedżer bufora ostatnio „opróżnił” bufor bazy danych na dysk! Uwaga 2: podobne rozumowanie można zastosować w przypadku niepowodzenia transakcji (np. T3, T5) 14  Odtwarzanie nośników Odzyskiwanie nośników opiera się na pewnym typie nadmiarowości danych – Przechowywanych na offline (np. taśmy) lub online mediach (np. zapasowy dysk twardy online) Kompromis między kosztami utrzymania nadmiarowych danych a czasem potrzebnym do przywrócenia systemu Dwa rodzaje: mirroring dysku i archiwizacja 15  Odtwarzanie nośników Mirroring dysku – podejście w czasie (prawie) rzeczywistym, w którym te same dane są zapisywane jednocześnie na 2 lub więcej dyskach fizycznych – ograniczony czas przełączania awaryjnego, ale często droższe niż archiwizacja – (ograniczony) negatywny wpływ na wydajność zapisu, ale możliwości równoległego dostępu do odczytu Archiwizacja – pliki baz danych są okresowo kopiowane na inne nośniki danych (np. taśma, dysk twardy) – kompromis między kosztem częstszych kopii zapasowych a kosztem utraty danych – pełna vs przyrostowa kopia zapasowa 16  Kontrola współbieżności Typowe problemy ze współbieżnością Harmonogramy i harmonogramy seryjne Serializowalne harmonogramy Optymistyczne i pesymistyczne harmonogramy Blokowania i protokoły blokowania 17  Typowe problemy ze współbieżnością Scheduler odpowiada za planowanie wykonywania transakcji i ich operacji Proste wykonanie seryjne byłoby bardzo nieefektywne Scheduler zapewni, że operacje transakcji mogą być wykonywane z przeplotem Mogą wystąpić problemy z interferencją – problem utraconej aktualizacji (utraty zmian) – problem niezatwierdzonych zależności – problem analizy niespójności 18  Typowe problemy ze współbieżnością Problem utraconej aktualizacji (lost update problem) występuje, jeśli udana aktualizacja danych przez transakcję jest nadpisywana przez inną transakcję, która nie była „świadoma” pierwszej aktualizacji time T1 T2 amountx t1 begin transaction 100 t2 begin transaction read(amountx) 100 t3 read(amountx) amountx = amountx + 120 100 t4 amountx = amountx - 50 write(amountx) 220 t5 write(amountx) commit 50 t6 commit 50 19  Typowe problemy ze współbieżnością Jeśli transakcja odczytuje jedną lub więcej danych, które są aktualizowane przez inną, jeszcze niezatwierdzoną transakcję, możemy napotkać problem niezatwierdzonych zależności (odczyt niepewnych/brudnych danych) (uncommited dependency problem/dirty read problem) time T1 T2 amountx t1 begin transaction 100 t2 read(amountx) 100 t3 amountx = amountx + 120 100 t4 begin transaction write(amountx) 220 t5 read(amountx) 220 t6 amountx = amountx – 50 rollback 100 t7 write(amountx) 170 t8 commit 170 20  Typowe problemy ze współbieżnością Problem analizy niespójności (incosistent analysis problem) oznacza sytuację gdy transakacja odczytuje częściowe wyniki innej transakcji, która równolegle oddziałuje na te same dane ( i aktualizuje je). time T1 T2 amountx y z sum t1 begin transaction 100 75 60 t2 begin transaction sum = 0 100 75 60 0 t3 read(amountx) read(amountx) 100 75 60 0 t4 amountx = amountx – 50 sum = sum + amountx 100 75 60 100 t5 write(amountx) read(amounty) 50 75 60 100 t6 read(amountz) sum = sum + amounty 50 75 60 175 t7 amountz = amountz + 50 50 75 60 175 t8 write(amountz) 50 75 110 175 t9 commit read(amountz) 50 75 110 175 t10 sum = sum + amountz 50 75 110 285 t11 commit 50 75 110 285 21  Typowe problemy ze współbieżnością Inne problemy związane ze współbieżnością – niepowtarzalny odczyt (nonrepeatable read) występuje gdy transakcja T1 odczytuje ten sam wiersz wiele razy, ale uzyskuje różne kolejne wartości, ponieważ w międzyczasie inna transakcja T2 zaktualizowała ten wiersz – odczyt fantomów (Phantom reads) może wystąpić, gdy transakcja T2 wykonuje operacje wstawiania lub usuwania na zestawie wierszy odczytywanych przez transakcję T1 22  Harmonogramy i harmonogramy szeregowe Definiujemy harmonogram S jako zbiór n transakcji I sekwencyjne uporządkowanie instrukcji tych transakcji, dla których zachodzi następująca własność: “Dla każdej transakcji T która uczestniczy w harmonogramie S i dla wszystkich instrukcji si i sj które należą do tej samej transakcji T: jeżeli instrukcja si poprzedza instrukcję sj w T, to si ma zostać wykonana przed sj w S.” Harmonogram zachowuje kolejność poszczególnych instrukcji wewnątrz każdej transakcji, ale pozwala na dowolną kolejność instrukcji między transakcjami 23  Harmonogramy i szeregowe harmonogramy Harmonogram S jest szeregowy jeżeli wszystkie instrukcje si tej samej transakcji T są zaplanowane kolejno, bez przeplotu z instrukcjami z innej transakcji Szeregowe harmonogramy uniemożliwiają równoległe wykonywanie transakcji Potrzeba nieszeregowego poprawnego harmonogramu 24  Harmonogramy szeregowalny Harmonogram szeregowalny to hamonogram niesekwencyjny, który jest równoważny harmonogramowi sekwencyjnemu 2 harmonogramy S1 i S2 (z tymi samymi transakcjami T1, T2,..., Tn) są równoważne jeżeli – Dla każdej operacji readx transakcji Ti w S1 zachodzi: jeżeli wartość x która jest odczytana przez tę operację, została ostatnio zapisana przez operację writex transakcji Tj w S1, to ta sama operacja readx transakcji Ti w S2 powinna odczytać wartość x, zapisaną przez tę samą operację writex Tj w S2 – Dla każdej wartości x na którą ma wpływ operacja zapisu w tych harmonogramach, ostatnia operacja zapisu writex w harmonogramie S1, wykonana jako część transakcji Ti, powinna również być ostatnią operacją zapisu x w harmonogramie S2, 25 ponownie jako część transakcji Ti. Harmonogramy szeregowalne 26  Harmonogramy szeregowalne Graf pierwszeństwa do testowania harmonogramu pod kątem szeregowalności – utwórz węzeł dla każdej transakcji Ti – utwórz skierowaną krawędź Ti → Tj jeżeli Tj czyta wartość po zapisaniu jej przez Ti – utwórz skierowaną krawędź Ti → Tj jeżeli Tj zapisuje wartość po jej odczytaniu przez Ti – utwórz skierowaną krawędź Ti → Tj jeżeli Tj zapisuje wartość po jej zapisaniu przez Ti Jeżeli graf pierwszeństwa zawiera cykl – harmonogram nie jest szeregowalny 27  Harmonogramy optymistyczne i pesymistyczne Scheduler wykorzystuje protokół harmonogramowania Protokół optymistyczny – konflikty między równoległymi transakcjami są rzadkie – operacje transakcji są planowane bez opóźnień – gdy transakcja jest gotowa do zatwierdzenia, jest weryfikowana pod kątem konfliktów – jeśli nie ma konfliktów, transakcja jest zatwierdzana; w przeciwnym razie - wycofywana Protokół pesymistyczny – jest prawdopodobne, że transakcje będą kolidować i powodować konflikty – realizacja operacji transakcyjnych opóźniona do czasu, gdy scheduler będzie mógł je zaplanować w taki sposób, aby zminimalizować ryzyko konfliktów – do pewnego stopnia zmniejszenie przepustowości – np. harmonogram sekwencyjny 28 Harmonogramy optymistyczne i pesymistyczne Blokowanie może być używane do harmonogramowania optymistycznego i pesymistycznego – Pesymistyczne harmonogramowanie: blokowanie służy do ograniczenia jednoczesnego wykonania transakcji – Optimistyczne harmonogramowanie: blokowanie służy do wykrywania konfliktów podczas realizacji transakcji Znacznik czasowy (timestamping) – Znaczniki czasowe odczytu i zapisu to atrybuty powiązane z obiektem bazy danych – Znaczniki czasowe służą do wymuszenia wykonania zbioru operacji transakcji w odpowiedniej kolejności 29  Blokowanie i protokoły blokowania Cele blokowania Protokół dwufazowego blokowania Two-Phase Locking Protocol (2PL) Kaskadowe wycofywania (Cascading Rollbacks) Radzenie sobie z zakleszczeniaim (Dealing with Deadlocks) Poziomy izolacji Ziarnistość blokad 30  Cele blokowania Zapewnienie, że w sytuacjach, w których różne współbieżne transakcje próbują uzyskać dostęp do tego samego obiektu bazy danych, dostęp jest udzielany tylko w taki sposób, aby nie mogły wystąpić konflikty Blokada to zmienna powiązana z obiektem bazy danych, w której wartość zmiennej ogranicza typy operacji, które mogą być wykonywane na obiekcie w danym czasie Menedżer blokad odpowiada za przyznawanie blokad i zwalnianie blokad poprzez zastosowanie protokołu blokowania 31  Cele blokowania Blokada na wyłączność (exclusive lock) (x-lock lub blokada zapisu) oznacza, że pojedyncza transakcja uzyskuje wyłączne uprawnienie do interakcji z tym konkretnym obiektem bazy danych w danym czasie – żadne inne transakcje nie mogą go czytać ani zapisywać Blokada współdzielona (shared lock) (blokada s-lock lub blokada odczytu) gwarantuje, że żadne inne transakcje nie zaktualizują tego samego obiektu tak długo, jak utrzymywana jest blokada – inne transakcje mogą również posiadać współdzieloną blokadę na tym samym obiekcie, jednak mogą tylko go czytać 32  Cele blokowania Jeśli transakcja chce zaktualizować obiekt, wymagana jest blokada na wyłączność – możliwa do uzyskania tylko wtedy, gdy żadna inna transakcja nie blokuje obiektu Macierz kompatybilności (compatibility matrix) 33  Cele blokowania Menadżer blokad implementuje protokół blokowania – zbiór reguł określających jakie blokady można przyznać w jakiej sytuacji (na podstawie np. macierzy kompatybilności ) Menadżer blokad wykorzystuje również tabelę blokad – które blokady są aktualnie utrzymywane przez jaką transakcję, które transakcje czekają na zdobycie określonych blokad itp. Menadżer blokad musi zapewnić „uczciwość” planowania transakcji, aby np. uniknąć zagłodzenia 34  Protokół dwufazowego blokowania (2PL) Protokół 2PL działa w następujący sposób: 1. Zanim transakcja będzie mogła odczytać (zaktualizować) obiekt bazy danych, powinna uzyskać współdzieloną (wyłączną) blokadę tego obiektu 2. Menadżer blokad określa, czy można przyznać żądane blokady, na podstawie macierzy kompatybilności 3. Uzyskiwanie i zwalnianie blokad odbywa się w 2 fazach faza wzrostu: można uzyskiwać blokady, ale nie można ich zwalniać faza zmniejszania: blokady są stopniowo zwalniane i nie można uzyskać dodatkowych blokad 35  Protokół dwufazowego blokowania (2PL) Warianty – Rygorystyczny 2PL: transakcja utrzymuje wszystkie swoje blokady, dopóki nie zostanie zatwierdzona – Statyczny 2PL (Zachowawczy 2PL): transakcja uzyskuje wszystkie swoje blokady od razu na początku transakcji 36 Protokół dwufazowego blokowania (2PL) # locks held by T (a) 2PL processing of T growth phase shrink phase (b) Rigorous 2PL (c) Static 2PL 37  Protokół dwufazowego blokowania (2PL) Problem utraconej aktualizacji z blokowaniem time T1 T2 amountx t1 begin transaction 100 t2 begin transaction x-lock(amountx) 100 t3 x-lock(amountx) read(amountx) 100 t4 wait amountx = amountx + 120 100 t5 wait write(amountx) 220 t6 wait commit 220 t7 wait unlock(amountx) 220 t8 read(amountx) 220 t9 amountx = amountx - 50 220 t10 write(amountx) 170 t11 commit 170 t12 unlock(amountx) 170 38  Protokół dwufazowego blokowania (2PL) Problem niezatwierdzonych zależności z blokowaniem time T1 T2 amountx t1 begin transaction 100 t2 x-lock(amountx) 100 t3 read(amountx) 100 t4 begin transaction amountx = amountx + 120 100 t5 x-lock(amountx) write(amountx) 220 t6 wait rollback 100 t7 wait unlock(amountx) 100 t8 read(amountx) 100 t9 amountx = amountx - 50 100 t10 write(amountx) 50 t11 commit 50 t12 unlock(amountx) 50 39  Kaskadowe wycofywanie Problem niezatwierdzonych zależności – problem zostanie rozwiązany, jeżeli T2 utrzyma wszystkie swoje blokady aż nie zostanie wycofana – przy protokole 2PL blokady można zwolnić już przed zatwierdzeniem lub przerwaniem transakcji (faza zmniejszania) time T1 T2 amountx t1 begin transaction 100 t2 x-lock(amountx) 100 t3 read(amountx) 100 t4 begin transaction amountx = amountx + 120 100 t5 x-lock(amountx) write(amountx) 220 t6 wait unlock(amountx) 220 t7 read(amountx) 220 t8 amountx = amountx - 50 rollback 220 t9 write(amountx) 170 t10 commit 170 t11 unlock(amountx) 170 t12 40  Kaskadowe wycofywania Zanim transakcja T1 będzie mogła zostać zatwierdzona, SZBD powinien upewnić się, że wszystkie transakcje, które dokonały zmian w danych, które zostały następnie odczytane przez T1 są najpierw zatwierdzone Jeżeli transakcja T2 zostanie wycofana, wszystkie niezatwierdzone transakcje Tu które mają odczytane wartości zapisane prze T2 muszą zostać wycofane Wszystkie transakcje, które z kolei mają odczytane wartości zapisane przez Tu również muszą zostać wycofane, itd Kaskadowe wycofywanie zmian powinno być stosowane rekurencyjnie – może być czasochłonne – najlepszym sposobem na uniknięcie tego jest trzymanie blokad przez wszystkie transakcje, dopóki nie osiągną stanu „zatwierdzonego” (np. rygorystyczne 2PL) 41  Radzenie sobie z zakleszczeniami Zakleszczenie (deadlocks) występuje, gdy 2 lub więcej transakcji czeka na zwolnienie swoich blokad Np. time T1 T2 t1 begin transaction t2 x-lock(amountx) begin transaction t3 read(amountx) x-lock(amounty) t4 amountx = amountx - 50 read(amounty) t5 write(amountx) amounty = amounty - 30 t6 x-lock(amounty) write(amounty) t7 wait x-lock(amountx) t8 wait wait 42  Radzenie sobie z zakleszczeniami Zapobieganie zakleszczeniu można osiągnąć dzięki statycznemu 2PL – transakcja musi uzyskać wszystkie swoje blokady na początku Wykrywanie i rozwiązywanie – graf oczekiwań (wait for graph) składa się z węzłów reprezentujących aktywne transakcje i skierowanych krawędzi Ti → Tj dla każdej transakcji Ti oczekującej na uzyskanie blokady aktualnie posiadanej prze transakcję Tj – zakleszczenie istnieje, jeżeli graf oczekiwań zawiera cykl – wybór ofiary 43  Poziomy izolacji Poziom izolacji transakcji oferowany przez 2PL może być zbyt rygorystyczny Ograniczona ilość inferencji może być akceptowalna dla lepszej przepustowości Blokada długoterminowa jest przyznawana i zwalniana zgodnie z protokołem i jest utrzymywana przez dłuższy czas, aż do zatwierdzenia transakcji Blokada krótkoterminowa jest utrzymywana tylko w przedziale czasu potrzebnym do zakończenia powiązanej operacji – użycie krótkoterminowych blokad narusza regułę 3 protokołu 2PL 44 – może służyć do poprawy przepustowości  Poziomy izolacji Niezatwierdzony odczyt (Read uncommitted) 0 - to najniższy poziom izolacji. Blokady długoterminowe nie są brane pod uwagę; zakłada się, że konflikty współbieżności nie występują lub po prostu ich wpływ na transakcje z tym poziomem izolacji nie jest problematyczny. Ten poziom izolacji jest zwykle dozwolony tylko dla transakcji tylko do odczytu, które i tak nie wykonują aktualizacji. Odczyt zatwierdzonych danych (Read committed) 1 - używa długoterminowych blokad zapisu, ale krótkoterminowych blokad odczytu. W ten sposób transakcja ma gwarancję, że nie odczyta żadnych danych, które są wciąż aktualizowane przez jeszcze niezatwierdzoną transakcję. To rozwiązuje utraconą aktualizację, a także problem niezatwierdzonych zależności. Jednak problem z analizą niespójności może nadal występować na tym poziomie izolacji, a także w przypadku odczytów niepowtarzalnych i odczytów fantomowych. 45  Poziomy izolacji Powtarzalne odczyty (Repeatable read) 2 - używa zarówno długoterminowych blokad odczytu, jak i blokad zapisu. W ten sposób transakcja może wielokrotnie odczytywać ten sam wiersz, bez ingerencji w operacje wstawiania, aktualizowania lub usuwania przez inne transakcje. Mimo to problem odczytów fantomowych pozostaje nierozwiązany przy tym poziomie izolacji. Serializowalny (Serializable) 3 - jest najsilniejszym poziomem izolacji i odpowiada mniej więcej implementacji 2PL. Teraz unika się również odczytów fantomowych. Należy zauważyć, że w praktyce definicja serializacji w kontekście poziomów izolacji sprowadza się jedynie do braku problemów ze współbieżnością, takich jak odczyty niepowtarzalne i odczyty 46 fantomowe.  Poziomy izolacji Poziom izolacji Utracone Niezatwierdzone Analiza Niepowtarzalny Odczyt aktualizacje zależności niespójności odczyt fantomów Read uncommited Tak Tak Tak Tak Tak Read commited Nie Nie Tak Tak Tak Repeatable read Nie Nie Nie Nie Tak Serializable Nie Nie Nie Nie Nie 47  Ziarnistość blokad Obiekt bazy danych do blokowania może być krotką, kolumną, tabelą, przestrzenią tabel, blokiem dysku itp. Kompromis między kosztem blokowania, a przepustowością transakcji Wiele DBMS zapewnia opcję posiadania optymalnego poziomu granulacji określonego przez system bazy danych Protokół wielokrotnej ziarnistości (Multiple Granularity Locking - MGL) zapewnia, że odpowiednie transakcje, które uzyskały blokady na obiektach bazy danych, które są ze sobą powiązane hierarchicznie, nie mogą być ze sobą w konflikcie 48  Ziarnistość blokad Protokół MGL wprowadza dodatkowe blokady – intencyjna blokada do odczytu (is-lock): koliduje tylko z x-locks – intencyjna blokada do zapisu (ix-lock): konfliktuje za zarówno z x-locks i s-locks – blokada dzielona i intencja blokady wyłącznej (six-lock): jest w konflikcie ze wszystkimi innymi typami blokad, z wyjątkiem is-lock 49 Ziarnistość blokad 50  Ziarnistość blokad Zanim blokada na obiekcie x będzie mogła zostać przyznana, blokada intencji jest umieszczana na wszystkich większych ziarnistościach obiektów obejmujących x – Np. jeśli transakcja żąda blokady s-lock (x-lock) na określonej krotce, is-lock (ix-lock) zostanie umieszczona w odpowiednim obszarze tabel, tabeli i bloku dysku 51  Ziarnistość blokad Według MGL, transakcja Ti może zablokować obiekt będący częścią struktury hierarchicznej, jeśli : 1. przestrzegane są wszystkie kompatybilności w macierzy kompatybilności 2. blokadę początkową należy umieścić w katalogu głównym hierarchii 3. zanim Ti może uzyskać s-lock albo is-lock na obiekcie x, powinn uzyskać is- lock lub ix-lock na rodzicu x 4. zanim Ti może uzyskać x-lock, six-lock lub ix-lock na obiekcie x, powinien uzyskać ix-lock lub six-lock na rodzicu x 5. Ti może uzyskać dodatkowe blokady tylko wtedy, gdy nie zwolnił jeszcze żadnej blokady 6. Zanim Ti będzie mógł zwolnić blokadę na x, powinny zostać zwolnione wszystkie blokady na wszystkich dzieciach x W protokole MGL wszystkie blokady są uzyskiwane top-down, a zwalniane bottom-up 52  Własności ACID transakcji ACID: Atomicity, Consistency, Isolation, Durability Atomowość (Atomicity) gwarantuje, że wiele operacji bazodanowych zmieniających stan bazy danych można traktować jako jedną niepodzielną jednostkę pracy – menedżer odtwarzania może w razie potrzeby wywołać wycofanie, za pomocą operacji UNDO Spójność (Consistency) odnosi się do faktu, że transakcja, jeśli jest wykonywana w izolacji, powoduje przekształcenie bazy danych z jednego spójnego stanu w inny spójny stan – odpowiedzialność dewelopera – również nadrzędna odpowiedzialność systemu zarządzania transakcjami DBMS 53  Własności ACID transakcji Izolacja (Isolation) oznacza, że w sytuacjach, gdy wiele transakcji jest wykonywanych jednocześnie, wynik powinien być taki sam, jak gdyby każda transakcja była wykonywana oddzielnie – odpowiedzialność za mechanizmy kontroli współbieżności DBMS, koordynowane przez scheduler Trwałość (Durability) odnosi się do faktu, że skutki zatwierdzonej transakcji powinny być zawsze na trwale zapisywane w bazie danych – Odpowiedzialność managera odzyskiwania (np. przez operacje REDO lub redundancję danych) 54