Zarz ądzanie transakcjami i odtwarzanie po awarii

1. Zarządzanie transakcjamii odtwarzanie po awarii • Przygotował Lech Banachowski na podstawie: • Raghu Ramakrishnan, Johannes Gehrke, Database Management Systems, McGrawHill, 2000 (książka i slide’y). • Lech Banachowski, Krzysztof Stencel, Systemy zarzadzania bazami danych, Wyd. PJWSTK.

2. Zagadnienia • Aksjomaty realizacji transakcji. • Protokół Strict-2PL i jego uzupełnienia oraz modyfikacje. • Realizacja trybów izolacji realizacji transakcji. • Dziennik wycofań i jego zastosowania. • Dziennik powtórzeń i punkt kontrolny i ich zastosowanie do odtwarzania stanu bazy danych. • Baza danych rezerwowa STAND-BY.

3. Spójność • Stan bazy danych jest poprawny gdy jest wiernym odzwierciedleniem rzeczywistości biznesowej. • Stan bazy danych jest spójny gdy są spełnione wszystkie zdefiniowane więzy spójności – sprawdzane przez system. • Nie wszystkie ograniczeniabiznesowe (baza danych jako „wierne odzwierciedlenie biznesu”) mogą być sprawdzone przez system.

4. Współbieżność • Współbieżne wykonywanie programów użytkowników jest istotne dla szybkości działania aplikacji bazodanowych. • Dostęp do danych na dysku i w sieci jest częsty i względnie wolny, więc procesor może współbieżnie wykonywać kilka programów. • Transakcjana poziomie fizycznym jest ciągiem odczytów i zapisów danych dokonywanych przez użytkownika w bazie danych. • Współbieżność uzyskuje się przez przeplecenie odczytów i zapisów różnych transakcji.

5. „Klasyczna” poprawność transakcji • Wykonanie instrukcji SQL (transakcji) jest poprawne gdy zachowuje spójność stanu bazy danych. • Wykonanie szeregowe zbioru transakcjijest poprawne gdy wykonanie każdej transakcji z osobna zachowuje spójność stanu bazy danych. • Wykonanie współbieżne zbioru transakcjijest poprawne gdy jest równoważne szeregowemu poprawnemu wykonaniu zbioru transakcji. • różna kolejność wykonywania transakcji może prowadzić do innego poprawnego końcowego stanu.

6. Aksjomaty współbieżnego wykonywania transakcji ACID • Atomowość (niepodzielność) - albo wszystkie akcje wchodzące w skład transakcji są wykonywane albo żadna. Użytkownik może traktować transakcję jako jedną operację na danych. • Spójność - po współbieżnym wykonaniu zbioru transakcji stan bazy danych jest spójny. • Izolacja - wynik działania transakcji powinien być taki sam, jakby od chwili rozpoczęcia transakcji nie działała na wspólnych danych żadna inna transakcja. Użytkownik powinien mieć poczucie, że sam korzysta z bazy danych. • Trwałość - dane zatwierdzone przez transakcję powinny być dostępne nawet w sytuacji awarii oprogramowania, sprzętu lub węzła sieciowego.

7. Mechanizmy SZBD • blokady (zamki) (ang. lock) zakładane na obiekty – ograniczające albo wręcz uniemożliwiające działanie innych transakcji na zablokowanym obiekcie, • dziennik (ang. log) - zapisywanie wszystkich zmian w bazie danych do specjalnego dziennika (logu), aby w razie potrzeby móc: • dla nie zatwierdzonej transakcji wycofać wprowadzone przez nią zmiany, • w przypadku awarii odtworzyć aktualny, spójny stan bazy danych. • wielowersyjność - możliwość odczytywania danych zmienianych równocześnie przez inne transakcje w takiej postaci w jakiej istniały w pewnych chwilach w przeszłości (np. w chwili rozpoczynania się danego zapytania lub danej transakcji).

8. Mechanizmy SZBD • kopia zabezpieczająca bazy danych (backup) - wykonywana w regularnych odstępach czasu, na przykład raz na godzinę lub raz na dzień; w przypadku awarii danych na dysku pozwala przywrócić spójny stan bazy danych. • zapasowa instalacja tej samej bazy danych utrzymywana w trybie stand-by.

9. Atomowość transakcji • Transakcja może dokonać swojego zatwierdzenia (commit) po zakończeniuwszystkich swoich akcji lub • dokonaćsamo-wycofania (ROLLBACK) – w wyniku decyzji użytkownika/aplikacji, • zostać przerwana przez SZBD lub DBA (abort)i wycofana a następnie restartowana od początku (np. z powodu zakleszczenia - deadlocku), • zostać przerwana przez awarię - po podniesieniu systemu po awarii transakcja zostaje wycofana przez system.

10. Uwaga • W praktyce, podniesienie wyjątku (np. no_data_found lub too_many_rows)przy wykonywaniu pojedynczej instrukcji SQL powoduje tylko wycofanie tej jednej instrukcji i samo nie powoduje jeszcze automatycznego wycofania transakcji i powinno być odpowiednio obsłużone w aplikacji, która zgłasza transakcję do wykonania – i w miarę potrzeby z zastosowaniem przez nią explicite instrukcji ROLLBACK. • W SQL Server SET XACT_ABORT ONaby błąd w wykonywaniu instrukcji powodował wycofanie całej transakcji. Domyślna opcja: OFF.

11. Plan wykonania transakcji • Plan szeregowy: Najpierw akcje jednej transakcji, następnie akcje drugiej transakcji itd. • Równoważne plany:Efekt realizacji obu planów taki sam dla każdego stanu bazy danych. • Plan szeregowalny: Plan, który jest równoważny pewnemu planowi szeregowemu. Gwarantuje poprawną realizację zbioru transakcji. • własność izolacji, • własność spójności. • Plan szeregowalny nie gwarantuje ani atomowości ani trwałości.

12. Przykład:poprawna realizacja transakcji T1: BEGIN A=A+100, B=B-100 END T2: BEGIN A=1.06*A, B=1.06*B END • Intuicyjnie transakcja T1 dokonuje transferu 100 z konta B na konto A. Transakcja T2 dopisuje do obu kont 6% odsetki. • Poprawna realizacja obu transakcji powinna być równoważna albo szeregowemu wykonaniu T1 potem T2 albo szeregowemu wykonaniu T2 potem T1. W przykładzie w obu przypadkach efekt jest inny. • Efekt wykonania zbioru transakcji jest niedeterministyczny – uzależniony od kolejności transakcji.

13. Przykład - realizacja transakcji (c.d.) • Możliwy poprawny przeplot akcji obu transakcji(plan): T1: A=A+100, B=B-100, T2: A=1.06*A, B=1.06*B • A to niepoprawny plan: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B • Z punktu widzenia SZBD drugi plan jest postaci: T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B)

14. Przykład • Plan, który nie jest szeregowalny: • Przyczyna leży w cyklu grafu zależności. Wynik T1 zależyod T2 i vice-versa. T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B) A T1 T2 Graf zależności B

15. Anomalie przy przeplataniu akcji • Odczyt niezatwierdzonych danych "dirty read": • Niepowtarzalny odczyt: T1: R(A), W(A), R(B), W(B), C T2: R(A), W(A), C Plan szeregowalny. T1: R(A),R(A), W(A), C T2: R(A), W(A), C Plan nie szeregowalny.

16. Anomalie przy przeplataniu akcji (c.d) • Nadpisanie niezatwierdzonych danych: T1: W(A), R(B), W(B), C T2: W(A), W(B), C Plan nie szeregowalny

17. Plan odtwarzalny Plan, który umożliwia wycofanie każdej niezatwierdzonej transakcji, nazywa się planem odtwarzalnym. Plan odtwarzalny jest istotny do zapewnienia własności atomowościitrwałości. Plan jest planem szeregowalnym ale nie odtwarzalnym. T1: R(A), W(A), R(B), W(B) ?Rollback T2: R(A), W(A),C

18. Podstawowe rodzaje blokad • Współdzielona (ang. shared lock), S - daje transakcji współdzielony dostęp do zasobu. Np. kilka transakcji może jednocześnie pracować na tej samej tabeli. Jeśli transakcja zakłada współdzieloną blokadę, inne transakcje też mogą założyć współdzieloną blokadę, ale nie mogą założyć wyłącznej blokady. • Wyłączna (ang. exclusive lock), X - daje transakcji wyłączny dostęp do obiektu. Tylko jedna transakcja może mieć założoną wyłączną blokadę na obiekcie i w tym czasie nie może być założonej żadnej innej blokady nawet współdzielonej.

19. Podwyższenie blokady • Transakcja, która założyła blokadę S, może ją zmienić na X, pod warunkiem, że na obiekcie nie ma założonej innej blokady S.

20. Zarządzanie współbieżnością oparte na blokadach zakładanych na obiekty • Protokółścisłego blokowania dwufazowego (Strict 2PL): • Każda transakcja musi uzyskać blokadę S (współdzieloną) na obiekcie zanim odczyta ten obiekt oraz blokadę X (wyłączną) na obiekcie przed zapisaniem go. • Jeśli transakcja trzyma blokadę X na obiekcie, żadna inna transakcja nie ma prawa założyć żadnej blokady (ani S ani X) na tym obiekcie. • Jeśli transakcja trzyma blokadę S na obiekcie, żadna inna transakcja nie ma prawa założyć blokady X na tym obiekcie. • Gdy transakcja nie może założyć blokady na obiekcie, może ustawić się w kolejce oczekujących transakcji stowarzyszonej z tym obiektem. • Żadnej blokady nie można zwolnić przed końcem transakcji. • Wszystkie blokady założone przez transakcję są jednocześnie zwalniane gdy transakcja kończy się.

21. Własności protokołu Strict 2PL • Gwarantuje realizację wyłącznie planów szeregowalnych i odtwarzalnych. • Gwarantuje poprawną realizację zbioru transakcji oraz aksjomaty atomowości, spójności i izolacji ACID. • Nie dopuszcza do powstania zjawisk niezatwierdzonego odczytu, niepowtarzalnego odczytu i nadpisywania nie zatwierdzonych danych.

22. Dwufazowość protokołu Strict 2PL • Dwie fazy działania transakcji: • zakłada blokady i dokonuje wymaganych odczytów i zapisów na obiektach, na których założyła blokadę; • wykonuje COMMIT/ROLLBACK i zwalnia wszystkie blokady.

23. Słabsze wersje protokołu 2PL • Umożliwiają wcześniejsze zwalnianie blokad. • Protokół 2PL1: • transakcja nie może założyć żadnej nowej blokady po zwolnieniu jakiejkolwiek blokady; • gwarantuje szeregowalność transakcji, ale nie odtwarzalność. • Protokół 2PL2: • transakcja nie może przed swoim końcem zwolnić żadnej blokady X, ale w każdej chwili może zwolnić założoną do odczytu blokadę S (np. w chwili skończenia odczytu); • gwarantuje odtwarzalność, ale nie szeregowalność; • używany w praktyce (zwiększa wydajność systemu).

24. Zarządzanie blokadami • W pamięci RAM: • tablica transakcji - dla każdej transakcji przechowywana jest informacja o założonych przez nią blokadach, • tablica blokad – tablica zablokowanych obiektów. • Z każdym obiektem jest przechowywana informacja: • rodzaj(e) blokad, • lista transakcji, które założyły blokadę, • kolejka transakcji, które czekają aby założyć blokadę na obiekcie. • Operacje zakładania i zdejmowania blokady muszą być operacjami atomowymi (niepodzielnymi).

25. Zakleszczenia (deadlocks) • Cykl transakcji oczekujących wzajemnie na zwolnienie blokady. • Trzy sposoby radzenia sobie z zakleszczeniami: • zapobieganie, • wykrywanie, • timeout.

26. Wykrywanie zakleszczeń • Utwórz graf oczekiwań na blokadę: • Węzłami są transakcje. • Istnieje krawędź od Ti do Tj jeśli Ti oczekuje na zwolnienie blokady przez Tj. • Co jakiś czas sprawdzaj czy jest cykl np. przy wkładaniu transakcji do kolejki. • Jeśli jest cykl, wycofaj jedną z transakcji w cyklu.

27. Przykład T1: S(A), R(A), S(B) T2: X(B),W(B) X(C) T3: S(C), R(C) X(A) T4: X(B) T1 T2 T1 T2 T4 T3 T3 T3

28. Zapobieganie zakleszczeniom - timeout • Gdy transakcja czeka bezczynnie na zwolnienie blokady dłużej niż ustalony okres oczekiwaniatimeout, transakcja zostaje wycofana przez system.

29. Zjawisko "zagłodzenia" transakcji • Nawet jeśli nie będziemy dopuszczać do zakleszczenia, mogą wystąpić "pechowe" transakcje, które będą wielokrotnie wybierane do wycofania i w konsekwencji mogą nigdy nie doczekać się realizacji. • Przypisz transakcji priorytet, związany z momentem pierwszej próby jej realizacji (nazywany też znacznikiem czasowym). Wycofuj transakcję w cyklu, która ma najniższy priorytet. Z czasem transakcja uzyskuje coraz wyższy priorytet i w końcu "wygra" z innymi, później rozpoczętymi transakcjami.

30. Problem fantomów (duchów) • ProtokółStrict 2PL (w dotychczasowej postaci) jest poprawny pod warunkiem, że baza danych jest ustaloną, nie zmieniającą się kolekcją obiektów: • T1 blokuje wszystkie strony zawierające rekordy pracowników z E.Job='SALESMAN' i wyznacza zarabiającego najwięcej (E.Sal = 3000). • Następnie T2 wstawia nowego pracownika: E.Job='SALESMAN', E.Sal = 3500. • T2 usuwa najlepiej zarabiającego pracownika z E.Job='MANAGER' (zarabiającego powiedzmy E.Sal = 5000) i zatwierdza. • T1 blokuje wszystkie strony zawierające rekordy pracowników z E.Job='MANAGER' i wyznacza najlepiej zarabiającego (powiedzmy E.Sal = 4500). • Wykonywania tych transakcji nie da się uszeregować!

31. Problem • Potrzebne są blokady na zbiory rekordów określone przez predykaty np. E.Job='SALESMAN'.

32. Dane Rozwiązanie Indeks Job=‘SALESMAN’ • Jeśli jest indeks na polu Job, T1 blokuje stronę indeksu zawierającą pozycje danych zJob = ‘SALESMAN’. • Jeśli nie ma indeksu na polu Job, T1 musi zablokować cały plik/tabelę w trybie S.

33. Blokady zakładane na węzłach B+ drzewa • Przy wyszukiwaniu, węzły na ścieżce od korzenia do liścia nie muszą być blokowane (z wyjątkiem odczytywanego węzła z blokadą do odczytu). • Przy wykonywaniu instrukcji INSERT(podobnie dla DELETE), węzeł na ścieżce od korzenia do modyfikowanego liścia musi zostać zablokowany w trybie X tylko jeśli proces podziału węzłów może zostać propagowany do niego od modyfikowanego liścia. Schodząc w dół drzewa dokonujemy blokady aktualnego węzła i sprawdzamy, czy możemy zdjąć blokadę z węzłów, które leżą wyżej na ścieżce do korzenia.

34. Baza danych Tabela Strona Rekord Blokady wielo-poziomowe • Obiekty bazodanowe są zagnieżdżone. Blokada na pod-obiekcie implikuje pewną blokadę na nad-obiekcie (i na odwrót) – explicite lub implicite. Hierarchicznastrukturabazy danych zawiera • Jest możliwość wyboru poziomu zakładania blokady np. gdy trzeba zaktualizować kilka wierszy tabeli blokadę X można założyć albo na całą bazę danych, albo na całą tabelę, albo na wybrane wiersze.

35. Z punktu widzenia czasu realizacji pojedynczej transakcji lepiej założyć jedną blokadę (S lub X) na całą tabelę, niż milion blokad (S lub X) na jej wszystkie wiersze. • Z punktu widzenia poziomu współbieżności lepiej pozwolić transakcjom zakładać blokady na najniższym poziomie, czyli wierszy. • Omawiane dalej blokady intencyjne są kompromisem między czasem przetwarzania blokad a poziomem współbieżności.

36. Blokady intencyjne na złożonych obiektach W celu ewentualnego wykonania pewnych czynności na podobiektach - bez zakładania na całym obiekcie pełnej dla tej czynności blokady: IS – oznacza intencję (zamierzenie) zakładania blokad współdzielonych na podobiektach danego obiektu, IX – oznacza intencję (zamierzenie) zakładania blokad wyłącznych na podobiektach danego obiektu. Możliwość współistnienia różnych rodzajów blokad na jednym złożonym obiekcie Dodatkowo wprowadza się łączoną blokadę typu SIX.

37. Na tabeli • S oznacza S na wszystkich jej wierszach implicite. • IS oznacza S tylko na niektórych jej wierszach explicite wskazywanych. • X oznacza X na wszystkich jej wierszach implicite. • IX oznacza X tylko na niektórych jej wierszach explicite wskazywanych. • SIX oznacza S na wszystkich jej wierszach implicite oraz X tylko na niektórych jej wierszach explicite wskazywanych. • Najpierw są zakładane blokady intencyjne na tabelę, potem sukcesywnie, explicite w miarę potrzeby na jej wiersze. • Zanim transakcja zwolni blokadę na danej tabeli musi najpierwzwolnić wszystkie blokadyexplicite z jej wierszy.

38. Przykłady • Transakcja T używa indeksu do odczytania części tabeli R (SELECT):T uzyskuje blokadę IS na R, a następnie kolejno uzyskuje blokadę S na odczytywanych rekordach w R. • Transakcja T używa indeksu do odczytania części tabeli R a następnie aktualizuje wybrane wiersze (UPDATE, DELETE):T uzyskuje blokadę IX na R, a następnie kolejno uzyskuje blokadę X na zmienianych rekordach w R. • Transakcja T przebiega całą tabelę R i aktualizuje kilka rekordów (SELECT FOR UPDATE, UPDATE, DELETE):T uzyskuje blokadę SIX na R, następnie kolejno uzyskuje blokadę S na rekordach w R i czasami podwyższa blokadę rekordu do blokady X.

39. Optymistyczne blokowanie – inne podejście niż Strict 2PL • Faza 1: Transakcja wczytuje potrzebne dane do swoich lokalnych buforów i na nich dokonuje zmian bez zakładania jakichkolwiek blokad. • Faza 2: Transakcja sprawdza czy dokonane przez nią odczyty i zapisy nie pozostają w konflikcie z odczytami i zapisami zatwierdzonych już transakcji. Jeśli nie, następuje przepisanie zmian z lokalnych buforów do globalnych i zatwierdzenie transakcji. Jeśli tak, następuje restartowanie jeszcze raz tej samej transakcji. • Tylko w czasie realizacji Fazy 2 jest konieczność założenia blokad X na zmieniane obiekty.

40. Wielowersyjność– inne podejście niż Strict 2PL • Idea: Procesy zapisujące tworzą nową kopię obiektu podczas gdy procesy odczytujące korzystają ciągle ze starej wersji: Pula wersji (Starsze wersje obiektów używane przez procesy odczytujące.) Główny segment (Aktualne wersje obiektów) O’ O O’’ • Procesy odczytujące mogą działać bez zakładania blokad (np. transakcje READ ONLY).

41. Zjawiska związane ze współbieżnymi transakcjami • Odczyt niezatwierdzonych danych (ang. dirty read) - transakcja odczytuje dane, które zmieniła inna transakcja ale ich nie zatwierdziła. • Niepowtarzalny odczyt - w ramach tej samej transakcji, widać zmiany wprowadzane przez zatwierdzone transakcje. • Fantom (duch) - wiersz, którego nie było w tabeli na początku wykonywania transakcji obliczającej zapytanie na tej tabeli, aktóry został wprowadzony przez zatwierdzoną transakcję w trakcie wykonywania transakcji.

42. Poziom izolacji Niezatw-ierdzonyodczyt Niepowtarzalny odczyt Fantomy Read Uncommitted TAK TAK TAK Read Committed NIE TAK TAK Repeatable Reads NIE NIE TAK Serializable NIE NIE NIE Transakcje w SQL-92– nie tylko Strict 2PL Standard ANSI/ISO definiuje poziomy izolacji:czy transakcje widzą zmiany dokonywane przez inne współbieżnie działające transakcje.

43. Ustawianie poziomu izolacji w SQL Na przeciąg jednej transakcji: • SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; ....... • SET TRANSACTION ISOLATION LEVEL READ COMMITTED; ....... Na przeciąg sesji (Oracle): • ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE; ………… • ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED; • ………

44. SERIALIZABLE • Transakcja T odczytuje tylko te obiekty, których zmiany zostały zatwierdzone. • Żadna wartość odczytana lub zmieniona przez T nie może być zmieniona przez inną transakcję, dopóki T nie skończy działać. • Wyniki instrukcji SELECT wyliczone przez transakcję T nie zmieniają się, dopóki T nie skończy działać.

45. Implementacja SERIALIZABLE • Transakcja T uzyskuje blokady do odczytu i zapisu obiektów i zwalnia je zgodnie z protokołem Strict-2PL. • Zakładane są blokady typu S na zbiory wierszy wynikowych instrukcji SELECT (realizowane albo poprzez zablokowanie węzła indeksu albo poprzez zablokowanie całej tabeli).

46. Poziom izolacji SERIALIZABLE gwarantuje szeregowalność i odtwarzalność. Jest więc zgodny z teoretycznym modelem współbieżnego wykonywania transakcji. • Wymienione poniżej poziomy izolacji gwarantują odtwarzalność, natomiast nie gwarantują już szeregowalności wykonywania transakcji, a więc również pełnej izolacji użytkowników.

47. REPEATABLE READS • Transakcja T odczytuje tylko te obiekty, których zmiany zostały zatwierdzone. • Żadna wartość odczytana lub zmieniona przez T nie może być zmieniona przez inną transakcję, dopóki T nie skończy działać. • Implementacja: Transakcja T uzyskuje blokady do odczytu i zapisu obiektów i zwalnia je zgodnie z protokołem Strict-2PL.

48. READ COMMITTED • Transakcja T odczytuje tylko te obiekty, których zmiany zostały zatwierdzone. • Żadna wartość zmieniona przez T nie może być zmieniona przez inną transakcję, dopóki T nie skończy się. • Implementacja: • Transakcja T uzyskuje blokady X aby wykonać zmiany i utrzymuje te blokady do końca swojego działania. • Do wykonania odczytu transakcja T uzyskuje blokadę S. Po zakończeniu aktualnej instrukcji blokada ta jest zwalniana (nie czekając na koniec transakcji) – zgodnie z protokołem 2PL2.

49. READ COMMITTED w wersji Oracle • Odczyt nie wymaga założenia blokady S na wiersz. Odczytywanajest zawartość ostatnio zatwierdzonej wersji tego obiektu (w chwili rozpoczynania instrukcji) - korzystając z cechy wielowersyjności danych. Zatem transakcja może odczytywać obiekty (ich zatwierdzone stany) niezależnie od założonych na nich blokad X. • Zastosowanie metody READ COMMITTED w wersji Oracle prowadzi do znacznego podniesienia wydajności bazy danych (odczyty są niezależne od zapisów, mniej zakleszczeń), kosztem zmniejszenia izolacji użytkowników. • Ten poziom izolacji jest też definiowany w MS SQL Server:ALTER DATABASE mydatabase SET READ_COMMITTED_SNAPSHOT ON;SET TRANSACTION ISOLATION LEVEL READ COMMITED;

50. READ UNCOMMITED • Transakcja T odczytuje obiekty w dowolnej chwili. • Transakcja T nie dokonuje żadnych zapisów. • Implementacja: • Transakcja nie zakłada żadnych blokad ale też nie ma prawa wprowadzać żadnych zmian do bazy danych. • Odczyt dotyczy zawsze aktualnego stanu obiektu - nawet jeśli jest on nie zatwierdzony. • A więc zablokowanie obiektu w trybie X nie ogranicza odczytu obiektu przez transakcje realizowane na poziomie: • READ UNCOMMITED (odczyt wersji niezatwierdzonej) • READ COMMITED w Oracle (odczyt wersji zatwierdzonej)