zarz ądzanie transakcjami i odtwarzanie po awarii

1/62PJWSTK, SZB, Lech Banachowski

Zarządzanie transakcjami i odtwarzanie po awarii

Przygotował Lech Banachowski na podstawie: 1. Raghu Ramakrishnan, Johannes Gehrke, Database Management

Systems, McGrawHill, 2000 (książka i slide’y). 2. Lech Banachowski, Krzysztof Stencel, Systemy zarzadzania bazami

danych, Wyd. PJWSTK.


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.


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.


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.


„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.


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. Spójność - po współbieżnym wykonaniu zbioru transakcji stan bazy danych jest spójny.

3. 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.

4. Trwałość - dane zatwierdzone przez transakcję powinny być dostępne nawet w sytuacji awarii oprogramowania, sprzętu lub węzła sieciowego.


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).


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.


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.


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.


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.


Przykład: poprawna realizacja transakcji

T1: BEGIN A=A+100, B=B-100 ENDT2: 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.


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)


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)

T1 T2A

B

Graf zależności


Anomalie przy przeplataniu akcji

Odczyt niezatwierdzonych danych "dirty read":

Niepowtarzalny odczyt:

T1: R(A), W(A), R(B), W(B), CT2: R(A), W(A), C

T1: R(A), R(A), W(A), CT2: R(A), W(A), C

Plan nie szeregowalny.

Plan szeregowalny.


Anomalie przy przeplataniu akcji (c.d)

Nadpisanie niezatwierdzonych danych:

T1: W(A), R(B), W(B), CT2: W(A), W(B), C

Plan nie szeregowalny


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.

T1: R(A), W(A), R(B), W(B) ?RollbackT2: R(A), W(A), C


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.


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.


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ę.


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.


Dwufazowość protokołu Strict 2PL

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.


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).


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).


Zakleszczenia (deadlocks)

Cykl transakcji oczekujących wzajemnie na

zwolnienie blokady.

Trzy sposoby radzenia sobie z

zakleszczeniami:

– zapobieganie,

– wykrywanie,

– timeout.


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.


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

T4 T3

T1 T2

T3 T3


Zapobieganie zakleszczeniom - timeout

• Gdy transakcja czeka bezczynnie na zwolnienie

blokady dłużej niż ustalony okres oczekiwania timeout,

transakcja zostaje wycofana przez system.


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.


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ć!


Problem

Potrzebne są blokady na zbiory

rekordów określone przez predykaty

np. E.Job='SALESMAN'.


Rozwiązanie

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.

Job=‘SALESMAN’

Dane

Indeks


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.


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

zawiera

Hierarchicznastrukturabazy danych

• 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.


• 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.


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.


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.


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, 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.


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.


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:

O O’

O’’

Głównysegment(Aktualnewersjeobiektów)

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).


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.


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.

NIENIENIESerializable

TAKNIENIERepeatable Reads

TAKTAKNIERead Committed

TAKTAKTAKRead Uncommitted

FantomyNiepowtarzalny odczyt

Niezatw-ierdzonyodczyt

Poziom izolacji


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; ………


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ć.


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).


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.


REPEATABLE READS


Ż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.


READ COMMITTED


Ż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.


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;


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)


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).

Przy 2 i 3 transakcje READ ONLY nie zakładają blokad S i nie trzeba ich zwalniać.


Poziom izolacji obrazu migawkowego w SQL Server

Przy odczytywaniu danych transakcja widzi dane takie jakie były w chwili rozpoczynania się transakcji.

ALTER DATABASE mydatabaseSET 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.


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.


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).


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.


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


Przykłady założenia blokady na tabelę

LOCK TABLE Klienci IN EXCLUSIVE MODE; -- zablokowanie całej tabeli w trybie wyłącznym LOCK TABLE Klienci IN SHARE MODE; -- zablokowanie całej tabeli w trybie

współdzielonym


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;


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;


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 wierszyLOCK TABLE table IN ROW EXCLUSIVE MODE; LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE; LOCK TABLE table IN EXCLUSIVE MODE;


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>


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.


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.


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.


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.


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.


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 EmpAS OF SCN(:SCN_FLASH);


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) .


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).


Zasada WAL- WriteAheadLogging

(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.



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.



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.


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.


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ń.


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.

zarz ądzanie transakcjami i odtwarzanie po awarii

Documents