Zarzdzanie transakcjami i odtwarzanie po awarii Przygotowa Lech

Zarządzanie transakcjami i odtwarzanie po awarii Przygotował Lech Banachowski na podstawie: 1. Raghu Ramakrishnan, Johannes Gehrke, Database Management Systems, Mc. Graw. Hill, 2000 (książka i slide’y). 2. Lech Banachowski, Krzysztof Stencel, Systemy zarzadzania bazami danych, Wyd. PJWSTK, SZB, Lech Banachowski /62

Zagadnienia v v v Aksjomaty realizacji transakcji. Protokół Strict-2 PL 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. PJWSTK, SZB, Lech Banachowski 2/62

Spójność v v 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. PJWSTK, SZB, Lech Banachowski 3/62

Współbieżność v Współbieżne wykonywanie programów użytkowników jest istotne dla szybkości działania aplikacji bazodanowych. – v 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. PJWSTK, SZB, Lech Banachowski 4/62

„Klasyczna” poprawność transakcji v v v 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. PJWSTK, SZB, Lech Banachowski 5/62

Aksjomaty współbieżnego wykonywania transakcji ACID 1. 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. 2. 3. 4. 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. PJWSTK, SZB, Lech Banachowski 6/62

Mechanizmy SZBD v v 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. v 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). PJWSTK, SZB, Lech Banachowski 7/62

Mechanizmy SZBD v v 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. PJWSTK, SZB, Lech Banachowski 8/62

Atomowość transakcji v 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. PJWSTK, SZB, Lech Banachowski 9/62

Uwaga v 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. v W SQL Server SET XACT_ABORT ON aby błąd w wykonywaniu instrukcji powodował wycofanie całej transakcji. Domyślna opcja: OFF. PJWSTK, SZB, Lech Banachowski 10/62

Plan wykonania transakcji v Plan szeregowy: Najpierw akcje jednej transakcji, następnie akcje drugiej transakcji itd. v Równoważne plany: Efekt realizacji obu planów taki sam dla każdego stanu bazy danych. v 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. PJWSTK, SZB, Lech Banachowski 11/62

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

Przykład - realizacja transakcji (c. d. ) v Możliwy poprawny przeplot akcji obu transakcji (plan): T 1: T 2: v A to niepoprawny plan: T 1: T 2: v A=A+100, B=B-100, A=1. 06*A, B=1. 06*B A=A+100, B=B-100 A=1. 06*A, B=1. 06*B Z punktu widzenia SZBD drugi plan jest postaci: T 1: T 2: R(A), W(A), R(B), W(B) R(A), W(A), R(B), W(B) PJWSTK, SZB, Lech Banachowski 13/62

Przykład v T 1: T 2: Plan, który nie jest szeregowalny: R(A), W(A), R(B), W(B) R(A), W(A), R(B), W(B) A T 1 T 2 Graf zależności B v Przyczyna leży w cyklu grafu zależności. Wynik T 1 zależy od T 2 i vice-versa. PJWSTK, SZB, Lech Banachowski 14/62

Anomalie przy przeplataniu akcji v Odczyt niezatwierdzonych danych "dirty read": T 1: T 2: v R(A), W(A), R(B), W(B), C R(A), W(A), C Niepowtarzalny odczyt: T 1: T 2: R(A), Plan szeregowalny. R(A), W(A), C Plan nie szeregowalny. PJWSTK, SZB, Lech Banachowski 15/62

Anomalie przy przeplataniu akcji (c. d) v T 1: T 2: Nadpisanie niezatwierdzonych danych: W(A), R(B), W(B), C W(A), W(B), C Plan nie szeregowalny PJWSTK, SZB, Lech Banachowski 16/62

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 T 1: T 2: R(A), W(A), R(B), W(B) ? Rollback R(A), W(A), C jest planem szeregowalnym ale nie odtwarzalnym. PJWSTK, SZB, Lech Banachowski 17/62

Podstawowe rodzaje blokad v 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. v 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. PJWSTK, SZB, Lech Banachowski 18/62

Podwyższenie blokady v 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. PJWSTK, SZB, Lech Banachowski 19/62

Zarządzanie współbieżnością oparte na blokadach zakładanych na obiekty v Protokół ścisłego blokowania dwufazowego (Strict 2 PL): – – – 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ę. PJWSTK, SZB, Lech Banachowski 20/62

Własności protokołu Strict 2 PL v v v 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. PJWSTK, SZB, Lech Banachowski 21/62

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

Słabsze wersje protokołu 2 PL v v Umożliwiają wcześniejsze zwalnianie blokad. Protokół 2 PL 1: – transakcja nie może założyć żadnej nowej blokady po zwolnieniu jakiejkolwiek blokady; – gwarantuje szeregowalność transakcji, ale nie odtwarzalność. v Protokół 2 PL 2: – 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). PJWSTK, SZB, Lech Banachowski 23/62

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). PJWSTK, SZB, Lech Banachowski 24/62

Zakleszczenia (deadlocks) v Cykl transakcji oczekujących wzajemnie na zwolnienie blokady. v Trzy sposoby radzenia sobie z zakleszczeniami: – zapobieganie, – wykrywanie, – timeout. PJWSTK, SZB, Lech Banachowski 25/62

Wykrywanie zakleszczeń v 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. v Co jakiś czas sprawdzaj czy jest cykl np. przy wkładaniu transakcji do kolejki. v Jeśli jest cykl, wycofaj jedną z transakcji w cyklu. PJWSTK, SZB, Lech Banachowski 26/62

Przykład T 1: S(A), R(A), S(B) T 2: X(B), W(B) X(C) T 3: S(C), R(C) X(A) T 4: X(B) T 1 T 2 T 4 T 3 T 3 PJWSTK, SZB, Lech Banachowski 27/62

Zapobieganie zakleszczeniom timeout • Gdy transakcja czeka bezczynnie na zwolnienie blokady dłużej niż ustalony okres oczekiwania timeout, transakcja zostaje wycofana przez system. PJWSTK, SZB, Lech Banachowski 28/62

Zjawisko "zagłodzenia" transakcji v v 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. PJWSTK, SZB, Lech Banachowski 29/62

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

Problem v Potrzebne są blokady na zbiory rekordów określone przez predykaty np. E. Job='SALESMAN'. PJWSTK, SZB, Lech Banachowski 31/62

Dane Rozwiązanie v v Indeks Job=‘SALESMAN’ Jeśli jest indeks na polu Job, T 1 blokuje stronę indeksu zawierającą pozycje danych z Job = ‘SALESMAN’. Jeśli nie ma indeksu na polu Job, T 1 musi zablokować cały plik/tabelę w trybie S. PJWSTK, SZB, Lech Banachowski 32/62

Blokady zakładane na węzłach B+ drzewa v v 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. PJWSTK, SZB, Lech Banachowski 33/62

Blokady wielo-poziomowe v Obiekty bazodanowe są zagnieżdżone. Blokada na pod-obiekcie implikuje pewną blokadę na nadobiekcie (i na odwrót) – explicite lub implicite. Baza danych Tabela zawiera Strona Hierarchiczna struktura bazy danych Rekord • 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. 34/62 PJWSTK, SZB, Lech Banachowski

• 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. PJWSTK, SZB, Lech Banachowski 35/62

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. PJWSTK, SZB, Lech Banachowski 36/62

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. PJWSTK, SZB, Lech Banachowski 37/62

Przykłady 1. 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. 2. 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. 3. Transakcja T przebiega całą tabelę R i aktualizuje kilka rekordów (SELECT FOR 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. PJWSTK, SZB, Lech Banachowski 38/62

Optymistyczne blokowanie – inne podejście niż Strict 2 PL v Faza 1: Transakcja wczytuje potrzebne dane do swoich lokalnych buforów i na nich dokonuje zmian bez zakładania jakichkolwiek blokad. v 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. v Tylko w czasie realizacji Fazy 2 jest konieczność założenia blokad X na zmieniane obiekty. PJWSTK, SZB, Lech Banachowski 39/62

Wielowersyjność – inne podejście niż Strict 2 PL v 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) v O O’ O’’ Pula wersji (Starsze wersje obiektów używane przez procesy odczytujące. ) Procesy odczytujące mogą działać bez zakładania blokad (np. transakcje READ ONLY). PJWSTK, SZB, Lech Banachowski 40/62

Zjawiska związane ze współbieżnymi transakcjami v Odczyt niezatwierdzonych danych (ang. dirty read) - transakcja odczytuje dane, które zmieniła inna transakcja ale ich nie zatwierdziła. v Niepowtarzalny odczyt - w ramach tej samej transakcji, widać zmiany wprowadzane przez zatwierdzone transakcje. v 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. PJWSTK, SZB, Lech Banachowski 41/62

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

Ustawianie poziomu izolacji w SQL Na przeciąg jednej transakcji: v SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; . . . . SET TRANSACTION ISOLATION LEVEL READ COMMITTED; . . . . Na przeciąg sesji (Oracle): v ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE; ………… v v ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED; v ……… PJWSTK, SZB, Lech Banachowski 43/62

SERIALIZABLE v v v 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ć. PJWSTK, SZB, Lech Banachowski 44/62

Implementacja SERIALIZABLE v v Transakcja T uzyskuje blokady do odczytu i zapisu obiektów i zwalnia je zgodnie z protokołem Strict 2 PL. 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). PJWSTK, SZB, Lech Banachowski 45/62

v Poziom izolacji SERIALIZABLE gwarantuje szeregowalność i odtwarzalność. Jest więc zgodny z teoretycznym modelem współbieżnego wykonywania transakcji. v 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. PJWSTK, SZB, Lech Banachowski 46/62

REPEATABLE READS v v v 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-2 PL. PJWSTK, SZB, Lech Banachowski 47/62

READ COMMITTED v v v 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 2 PL 2. PJWSTK, SZB, Lech Banachowski 48/62

READ COMMITTED w wersji Oracle v v v 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; PJWSTK, SZB, Lech Banachowski 49/62

READ UNCOMMITED v v v 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. v 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) PJWSTK, SZB, Lech Banachowski 50/62

Realizacje transakcji READ ONLY SET TRANSACTION READ ONLY; Jej zakończenie jest szybkie bo nie wprowadza zmian. 1. Realizacja taka sama jak zwykłej transakcji z zakładaniem blokad S. 2. 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. 3. W razie potrzeby transakcja READ ONLY korzysta z zapisów w dzienniku (np. z dziennika wycofań w Oracle). 4. Przy 2 i 3 transakcje READ ONLY nie zakładają blokad S i nie trzeba ich zwalniać. 51/62 PJWSTK, SZB, Lech Banachowski

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. PJWSTK, SZB, Lech Banachowski 52/62

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. PJWSTK, SZB, Lech Banachowski 53/62

Blokady w Oracle v System Oracle automatycznie zakłada blokadę X na wiersz, który ma być zmieniony. Blokada zostaje zdjęta w chwili wykonywania COMMIT lub ROLLBACK. v 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). PJWSTK, SZB, Lech Banachowski 54/62

Blokady w Oracle (c. d) v 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. v Oracle nie używa blokad współdzielonych na wierszach (na tabelach tak), do odczytu używa wielowersyjności. PJWSTK, SZB, Lech Banachowski 55/62

Przykład założenia wyłącznej blokady na wybrane wiersze v 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 PJWSTK, SZB, Lech Banachowski 56/62

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

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; PJWSTK, SZB, Lech Banachowski 58/62

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; PJWSTK, SZB, Lech Banachowski 59/62

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; PJWSTK, SZB, Lech Banachowski 60/62

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> PJWSTK, SZB, Lech Banachowski 61/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. PJWSTK, SZB, Lech Banachowski 62/62

Dzienniki bazy danych v v v 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ść, beforeimage, after-image, poprzedni. LSN> 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ść: u before-image (czyli poprzednia wartość), przechodzi na wartość u after-image (czyli nową wartość). – poprzedni. LSN to identyfikator LSN rekordu dziennika dla poprzednio wykonanej akcji w ramach tej samej transakcji. PJWSTK, SZB, Lech Banachowski 63/62

Dziennik wycofań v 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. PJWSTK, SZB, Lech Banachowski 64/62

Dziennik wycofań i wielowersyjność (Oracle) v 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). v 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. PJWSTK, SZB, Lech Banachowski 65/62

Algorytm wykonywania zapytania w Oracle v 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. v W podobny sposób są wykonywane transakcje raportujące typu READ ONLY i zapytania retrospektywne. PJWSTK, SZB, Lech Banachowski 66/62

Zapytania retrospektywne – zastosowanie wielowersyjności (Oracle) …. COMMIT; VARIABLE SCN_FLASH Number; EXECUTE : SCN_FLASH : = DBMS_FLASHBACK. GET_SYSTEM_CHANGE_NUMBER; DELETE * FROM Emp; COMMIT; …. . SELECT * FROM Emp AS OF SCN(: SCN_FLASH); PJWSTK, SZB, Lech Banachowski 67/62

Dziennik powtórzeń i odtwarzanie v 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ę. v 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). PJWSTK, SZB, Lech Banachowski 68/62

Zapisywanie zmian wprowadzanych przez transakcję v 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). PJWSTK, SZB, Lech Banachowski 69/62

Zasada WAL- Write. Ahead. Logging (1) 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. PJWSTK, SZB, Lech Banachowski 70/62

Dziennik powtórzeń i odtwarzanie v 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. v W przypadku awarii serwera bazy danych analiza samego dziennika powtórzeń pozwala na odtworzenie stanu bazy danych w chwili awarii. PJWSTK, SZB, Lech Banachowski 71/62

Dziennik powtórzeń i odtwarzanie v 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 v 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. PJWSTK, SZB, Lech Banachowski 72/62

Punkt kontrolny (checkpoint) v v 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. PJWSTK, SZB, Lech Banachowski 73/62

Rezerwowa baza danych (stand-by) v 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. v 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. v 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ń. PJWSTK, SZB, Lech Banachowski 74/62

Rezerwowa baza danych c. d. v 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. v Zamiast rezerwowej bazy danych alternatywę stanowi użycie replikacji bazy danych. PJWSTK, SZB, Lech Banachowski 75/62