Zarządzanie transakcjami i odtwarzanie po awarii

Prezentacja na temat: "Zarządzanie transakcjami i odtwarzanie po awarii"— Zapis prezentacji:

1 Zarządzanie transakcjami i 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 ograniczenia biznesowe (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. Transakcja na 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 transakcji jest poprawne gdy wykonanie każdej transakcji z osobna zachowuje spójność stanu bazy danych. Wykonanie współbieżne zbioru transakcji jest 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. W aksjomatach nie jest wymagana poprawność realizacji zbioru transakcji

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ńczeniu wszystkich 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 ON aby błąd w wykonywaniu instrukcji powodował wycofanie całej transakcji. Domyślna opcja: OFF. Czyli za atomowość transakcji odpowiada rowniez projektant aplikacji nie tylko system SZBD generuje błąd, który aplikacja musi obsłużyć

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. Jeśli każda transakcja zachowuje spójność bazy danych, każdy plan szeregowalny także zachowuje spójność bazy danych (realizacja transakcji ma własność spójności).

12 Przykład: poprawna realizacja transakcji
T1: BEGIN A=A+100, B=B 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ży od 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 T1 -> T2 – T1 powinna być realizowana przed T2 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. Chociaz odczyt nie zatwierdzonych danych A, to jednak te dane juz nie sa zmieniane przez T1 Konfliktowe pary operacji (R,W), (W,R), (W,W). 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 Choć W(A) w T1 można byłoby pominąć w T1 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ści i trwałości. Plan jest planem szeregowalnym ale nie odtwarzalnym. Plan szeregowalny nie daje gwarancji, że przy wycofywaniu transakcji nie trzeba wycofać akcji innych splecionych z nią transakcji, co czasem może się okazać nie wykonalne, gdy jedna z tych transakcji zostanie w międzyczasie zatwierdzona. 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). Odtwarzalność jest konieczna, szeregowalność często się poświęca dla uzyskania większej współbieżności, zatem i wiekszej wydajnosci 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)
T1, T2, T3, T4 przestają działać i czekają w nieskończoność na zwolnienie blokady. 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 oczekiwania timeout, 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 z Job = ‘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. Zatem zawsze co najmniej jeden węzeł w drzewie pozostaje zablokowany w trybie wyłącznym.

34 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. Rekord Tabela Strona Baza danych Hierarchiczna struktura bazy danych zawiera Czas przetwarzania blokad, czas realizacji transakcji, poziom współbieżności Z punktu widzenia czasu lepiej założyć jedną blokadę S na całą tabelę, niż milion blokad S na jej wszystkie rekordy. 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. Z punktu widzenia czasu lepiej założyć jedną blokadę S na całą tabelę, niż milion blokad S na jej wszystkie rekordy.

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 Na przykładzie tabeli S na tabeli oznacza S na wszystkich jej wierszach (implicite) IS na tabeli oznacza S tylko na niektórych jej wierszach explicite wskazywanych SIX – zakładająca blokadę transakcja może zakładać blokady X na wiersze, natomiast żadna inna transakcja nie może zakłądac blkokad X na iwerszach, ale może zakładac blokady S Może być tylko jedna blokada SiX na tabeli 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 najpierw zwolnić wszystkie blokady explicite z jej wierszy. Blokady zakładane explicite lub wnioskowane implicite Podobnie dla innych obiektiow w hierarchii np. Dla calej bazy danych

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. Inny protokół od klasycznego Strict 2PL

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: Główny segment (Aktualne wersje obiektów) Pula wersji (Starsze wersje obiektów używane przez procesy odczytujące.) O’ O O’’ Jeśli w chwili rozpoczynania zmiany są aktywne transakcje odczytujące zmieniane dane wtedy, dane są kopiowane do puli wersji do uzycia przez transakcje odczutujące. Odczyty transakcji odczytującej są przekierowywane do puli wersji. Inny protokół od klasycznego Strict 2PL 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, a który został wprowadzony przez zatwierdzoną transakcję w trakcie wykonywania transakcji.

42 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. NIE Serializable TAK Repeatable Reads Read Committed Read Uncommitted Fantomy Niepowtarzalny odczyt Niezatw-ierdzonyodczyt Poziom izolacji Realizacja poziomów izolacji jest inna w Standardzie i w Oracle! W oracle tylko Read Committed (domyslnie) i Serializable (Set … pierwszą instrukcją w transakcji). W DB2 inne nazwy np.. Serializable nazywa się Read Committed

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ść
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. Odczytywana jest 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; ALTER DATABASE mydatabase SET READ_COMMITED_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)

51 Realizacje transakcji READ ONLY
SET TRANSACTION READ ONLY; Jej zakończenie jest szybkie bo nie wprowadza zmian. Realizacja taka sama jak zwykłej transakcji z zakładaniem blokad S. Gdy w systemie działa transakcja READ ONLY, transakcja zmieniajaca obiekt pozostawia stara wersje obiektu w pomocniczej kolejce. W razie potrzeby, transakcja READ ONLY korzysta z nich. W razie potrzeby transakcja READ ONLY korzysta z zapisów w dzienniku (np. z dziennika wycofań w Oracle). Przy 2 i 3 transakcje READ ONLY nie zakładają blokad S i nie trzeba ich zwalniać.

52 Poziom izolacji obrazu migawkowego w SQL Server
Przy odczytywaniu danych transakcja widzi dane takie jakie były w chwili rozpoczynania się transakcji. ALTER DATABASE mydatabase SET ALLOW_SNAPSHOT_ISOLATION ON SET TRANSACTION ISOLATION LEVEL SNAPSHOT Transakcja może zmieniać dane w swoich lokalnych buforach i propagować zmiany do bazy danych przy COMMIT. Jeśli w międzyczasie inna transakcja zmieniła te dane lub założyła blokadę X, transakcję trzeba wycofać. Realizowany jest więc model optymistycznego blokowania.

53 SERIALIZABLE w wersji Oracle
Nie używane są blokady S na wierszach. Wszystkie odczyty dotyczą chwili rozpoczynania transakcji. Gdy szeregowalna transakcja chce założyć blokadę X na obiekcie zablokowanym blokadą X przez inną transakcję, czeka na zakończenie tej transakcji. Jeśli kończy się ona wycofaniem (ROLLBACK), szeregowalna transakcja zakłada blokadę X. Jeśli kończy się zatwierdzeniem (COMMIT), system generuje błąd Cannot serialize access error który przez aplikację może być dowolnie obsłużony np. przez ROLLBACK. Oracle® Database Application Developer's Guide - Fundamentals 10g Release 2 (10.2), chapter 2 SQL Processing for Application Developers Oracle Database transactions executing in SERIALIZABLE mode are transaction set consistent on an individual-transaction basis, because all statements in a SERIALIZABLE transaction execute on an image of the database as of the beginning of the transaction. Row-Level Locking Both read committed and serializable transactions use row-level locking, and both will wait if they try to change a row updated by an uncommitted concurrent transaction. The second transaction that tries to update a given row waits for the other transaction to commit or undo and release its lock. If that other transaction rolls back, the waiting transaction, regardless of its isolation mode, can proceed to change the previously lockebyc rd row as if the other transaction had not existed. However, if the other blocking transaction commits and releases its locks, a read committed transaction proceeds with its intended update. A serializable transaction, however, fails with the error Cannot serialize access error, because the other transaction has committed a change that was made since the serializable transaction began. When a serializable transaction fails with an ORA error ("cannot serialize access"), the application can take any of several actions: Commit the work executed to that point Execute additional, different, statements, perhaps after rolling back to a prior savepoint in the transaction Roll back the entire transaction and try it again Oracle Database stores control information in each data block to manage access by concurrent transactions. To use the SERIALIZABLE isolation level, you must use the INITRANS clause of the CREATE TABLE or ALTER TABLE command to set aside storage for this control information. To use serializable mode, INITRANS must be set to at least 3. serializable transactions - transaction-level read consistency or "repeatable reads"—where transactions query a consistent set of data for the duration of the transaction, knowing that the data has not been changed by any other transactions.

54 Blokady w Oracle System Oracle automatycznie zakłada blokadę X na wiersz, który ma być zmieniony. Blokada zostaje zdjęta w chwili wykonywania COMMIT lub ROLLBACK. Jeśli użytkownik chce mieć pewność, że wszystkie obiekty będą dostępne w trakcie wykonywania jego instrukcji musi sam na początku swojej transakcji założyć blokady na wszystkie potrzebne mu obiekty (tabele lub konkretne wiersze).

55 Blokady w Oracle (c.d) Przy wykonywaniu instrukcji DDL (CREATE/ALTER/DROP)też są zakładane blokady: dla obiektu bezpośrednio związanego z operacją - blokada wyłączna; dla obiektu pośrednio związanego z operacją - np. przy CREATE PROCEDURE - tabele w niej występujące - blokada współdzielona. Oracle nie używa blokad współdzielonych na wierszach (na tabelach tak), do odczytu używa wielowersyjności.

56 Przykład założenia wyłącznej blokady na wybrane wiersze
 SELECT * FROM Klienci WHERE Kraj = 'Polska' FOR UPDATE; -- założenie blokady wyłącznej na wiersze klientów z Polski i odpowiedniej intencyjnej na tabelę Klienci

57 Przykłady założenia blokady na tabelę
LOCK TABLE Klienci IN EXCLUSIVE MODE; -- zablokowanie całej tabeli w trybie wyłącznym IN SHARE MODE; -- zablokowanie całej tabeli w trybie współdzielonym

58 ROW SHARE (odpowiednik IS)
SELECT ... FROM table ... FOR UPDATE OF ... ; LOCK TABLE table IN ROW SHARE MODE; Najmniej restryktywny rodzaj blokady na tabeli. Dozwolone operacje: inne transakcje mogą wykonywać zapytania, insert, update, delete, zakładać blokady: row share, row exlusive, share, share row exclusive. Niedozwolona operacja: LOCK TABLE table IN EXCLUSIVE MODE;

59 ROW EXCLUSIVE (odpowiednik IX)
INSERT INTO table ... ; UPDATE table ... ; DELETE FROM table ... ; LOCK TABLE table IN ROW EXCLUSIVE MODE; Dozwolone operacje: inne transakcje mogą wykonywać zapytania, insert, update, delete, zakładać blokady: row share, row exlusive. Niedozwolone operacje: LOCK TABLE table IN SHARE MODE; LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE; LOCK TABLE table IN EXCLUSIVE MODE;

60 SHARE LOCK TABLE table IN SHARE MODE;
Dozwolone operacje: inne transakcje mogą tylko wykonywać zapytania, zakładać blokady na wiersze przy użyciu SELECT ... FOR UPDATE lub LOCK TABLE ... IN SHARE MODE, aktualizacje wierszy przez daną transakcję tylko jeśli żadna inna transakcja nie ma założonej blokady SHARE na tabelę (nawet jeśli zostały zablokowane przy użyciu SELECT ... FOR UPDATE). Niedozwolone operacje dla innych transakcji: Aktualizacje wierszy LOCK TABLE table IN ROW EXCLUSIVE MODE; LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE; LOCK TABLE table IN EXCLUSIVE MODE;

61 SHARE ROW EXCLUSIVE (odpowiednik SIX)
LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE; Dozwolone operacje: Tylko jedna transakcja w jednej chwili może mieć założoną blokadę SHARE ROW EXCLUSIVE na danej tabeli. Inne transakcje mogą wykonywać zapytania lub blokować wiersze używając SELECT z klauzulą FOR UPDATE, ale nie mogą dokonywać zmian w tabeli. Niedozwolone operacje dla innych transakcji : Aktualizacje wierszy LOCK TABLE table …. <wszystkie postacie>

62 EXCLUSIVE LOCK TABLE table IN EXCLUSIVE MODE;
Tylko jedna transakcja może mieć taką blokadę na tabeli. Inne transakcje mogą wykonywać tylko zapytania na tej tabeli – nie mogą ani jej zmieniać ani zakładać żadnej blokady do końca transakcji.

63 Dzienniki bazy danych Każdy rekord dziennika ma przypisany sobie identyfikujący go numer LSN (ang. log sequence number).  Przykładowo, rekord dziennika opisujący zmianę w bazie danych ma postać: LSN:: <typ operacji, IDtransakcji, IDstrony, offset, długość, before-image, after-image, poprzedniLSN> Rekord ten opisuje zmianę zawartości strony o identyfikatorze IDstrony od jej miejsca offset (czyli pozycji na stronie) na fragmencie długości długość: wartość: before-image (czyli poprzednia wartość), przechodzi na wartość after-image (czyli nową wartość). poprzedniLSN to identyfikator LSN rekordu dziennika dla poprzednio wykonanej akcji w ramach tej samej transakcji.

64 Dziennik wycofań W celu umożliwienia wycofania transakcji SZBD zapisuje wszystkie wykonywane przez nią zmiany w specjalnym dzienniku wycofań (ang. undo log) nazywanym w Oracle segmentami wycofań (ang. undo segments). Gdy trzeba wycofać transakcję system odczytuje w tył zapisy o zmianach wprowadzonych przez transakcję i przywraca poprzednie wartości danych.

65 Dziennik wycofań i wielowersyjność (Oracle)
Efekt wykonania zapytania powinien być spójny i odpowiadać chwili rozpoczęcia jego wykonywania. Już w chwili kończenia wykonywania instrukcji stan bazy danych może być inny (jeśli nie stosujemy blokad współdzielonych przy wykonywaniu zapytania). SCN - systemowy numer zmiany (znacznik czasu w bazie danych). Każda zatwierdzona transakcja zwiększa ten licznik o jeden. SCN może być uważany za identyfikator zatwierdzanej transakcji. Na każdej stronie jest zapisany SCN ostatniej transakcji, która ją zmieniła.

66 Algorytm wykonywania zapytania w Oracle
Niech q_SCN będzie aktualnym SCN w chwili rozpoczęcia wykonywania zapytania. W trakcie wykonywania zapytania są odczytywane strony danych. Dla każdej takiej strony z nagłówka jest odczytywany zapisany w nim s_SCN (numer transakcji, która ją ostatnio zmieniła). Jeśli s_SCN <= q_SCN, wtedy można zawartość strony użyć w obliczeniach. Jeśli s_SCN > q_SCN, wtedy w oparciu o segmenty wycofań należy obliczyć zawartość strony w chwili q_SCN i użyć tę zawartość do wykonania zapytania. W podobny sposób są wykonywane transakcje raportujące typu READ ONLY i zapytania retrospektywne.

67 Zapytania retrospektywne – zastosowanie wielowersyjności (Oracle)
…. COMMIT; VARIABLE SCN_FLASH Number; EXECUTE :SCN_FLASH := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER; DELETE * FROM Emp; ….. SELECT * FROM Emp AS OF SCN(:SCN_FLASH); Zastosowanie wielowersyjności Można też podać datę, godzinę.

68 Dziennik powtórzeń i odtwarzanie
Dziennik rejestrujący wszystkie zmiany zachodzące w bazie danych - nazywany dziennikiem powtórzeń (ang. redo log). Jest on z założenia trzymany na innym nośniku danych niż pliki z danymi w bazie danych. Na ogół dokonuje się stale jego archiwizacji przepisując go na taśmę. Zmiana danych na stronie na dysku i informacja o zatwierdzeniu są najpierw zapisywane do dziennika powtórzeń, dopiero potem uwzględniane w pliku danych na dysku. Po zapisie do dziennika powtórzeń nawet awaria serwera lub dysku z danymi nie spowoduje utraty danych bo można je odtworzyć (własność trwałości) .

69 Zapisywanie zmian wprowadzanych przez transakcję
Dane zmieniane przez transakcję nie muszą być zapisywane na dysk dokładnie w chwili kończenia transakcji (COMMIT) ale mogą zostać zapisane: przed jej zakończeniem (mówi się wtedy o zjawisku kradzieży ramek - ang. frame stealing); albo później, po jej zakończeniu (mówi się wtedy o strategii nie wymuszania - ang. no force).

70 Zasada WAL- WriteAheadLogging
Najpierw do dziennika powtórzeń na dysku jest zapisywany rekord opisujący zmianę zawartości strony, dopiero potem strona może być zapisana na dysku. Strategia ta zapewnia możliwość przywrócenia poprzedniej zawartości strony w przypadku awarii czyli zapewnia realizację własności atomowości transakcji. (2) Transakcja kończy się wtedy, gdy wszystkie rekordy dziennika powtórzeń dotyczące jej akcji zostaną przepisane z pamięci wewnętrznej na dysk a nie wtedy gdy dane zmienione przez transakcję zostaną zapisane na dysku. Po zatwierdzeniu, nawet w przypadku awarii serwera, jest możliwość przywrócenia danych czyli ta strategia zapewnia realizację własności trwałości transakcji.

71 Dziennik powtórzeń i odtwarzanie
Gdy nastąpi awaria dysku, pozycje dziennika powtórzeń (z części on-line na dysku lub części archiwizacyjnej na taśmie) zastosowane do kopii zabezpieczającej pozwalają odtworzyć stan bazy danych w chwili awarii. Jest to proces nazywany odtwarzaniem do przodu. W przypadku awarii serwera bazy danych analiza samego dziennika powtórzeń pozwala na odtworzenie stanu bazy danych w chwili awarii.

72 Dziennik powtórzeń i odtwarzanie
Ponieważ w dzienniku zapisane są również pozycje segmentów wycofań, jest możliwość wycofania nie zatwierdzonych transakcji, których działanie zostało przerwane w chwili awarii Jest to proces nazywany odtwarzaniem do tyłu. W rezultacie tych dwóch odtwarzań jest możliwość doprowadzenia stanu bazy danych do spójnego stanu.

73 Punkt kontrolny (checkpoint)
Odtwarzanie po awarii serwera musi mieć zdefiniowany punkt wyjściowy określający zawartość buforów pamięci RAM - sprowadzanych z bazy danych na dysku w chwili rozpoczynania odtwarzania. (Pełny) punkt kontrolny: zapisanie w dzienniku powtórzeń informacji o wszystkich transakcjach i stronach, aktualnie przetwarzanych w buforach pamięci RAM; przepisanie zawartości bufora dziennika powtórzeń do plików dziennika powtórzeń na dysku oraz przepisanie wszystkich zmienionych stron w buforach bazodanowych na dysk, również tych, których zmiany nie zostały jeszcze zatwierdzone. Oznacza to synchronizację aktualnych zawartości buforów pamięci RAM i dysku.

74 Rezerwowa baza danych (stand-by)
Dodatkowa instalacja bazy danych na osobnym komputerze utrzymywana stale w specjalnym trybie standby – z ciągle dokonywanym odtwarzaniem w oparciu o kopie zarchiwizowanego dziennika powtórzeń generowane przez główną, operacyjną bazę danych. W przypadku awarii dysku lub katastrofy w rodzaju trzęsienia ziemi, pożaru czy kradzieży, rezerwowa bazy danych przechodzi z trybu standby w tryb read write i przejmuje obowiązki głównej bazy danych. Rezerwowa baza danych zwykle znajduje się w fizycznie oddalonym węźle, do którego stale są przesyłane kolejne części zarchiwizowanego dziennika powtórzeń.

75 Rezerwowa baza danych c.d.
Rezerwowej bazy danych można używać do raportowania – przechodząc w tryb READ ONLY – napływające pozycje zarchiwizowanego dziennika powtórzeń utrzymywane są w kolejce, dopóki nie wrócimy do trybu STANDBY. Po przejściu bazy danych w tryb READ WRITE nie jest już możliwy jej powrót do trybu STANDBY. Zamiast rezerwowej bazy danych alternatywę stanowi użycie replikacji bazy danych.