Transcript PPT - pjwstk.edu.pl

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.
PJWSTK, SZB, Lech Banachowski
1/62
Zagadnienia
v
v
v
v
v
v
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.
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.
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.
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
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.
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
v
v
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.
PJWSTK, SZB, Lech Banachowski
11/62
Przykład: poprawna realizacja transakcji
T1:
T2:
v
v
BEGIN A=A+100, B=B-100 END
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.
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):
T1:
T2:
v
A=1.06*A,
B=B-100,
B=1.06*B
A to niepoprawny plan:
T1:
T2:
v
A=A+100,
A=A+100,
A=1.06*A, B=1.06*B
B=B-100
Z punktu widzenia SZBD drugi plan jest postaci:
T1:
T2:
R(A), W(A),
PJWSTK, SZB, Lech Banachowski
R(A), W(A), R(B), W(B)
R(B), W(B)
13/62
Przykład
v
T1:
T2:
Plan, który nie jest szeregowalny:
R(A), W(A),
R(A), W(A), R(B), W(B)
R(B), W(B)
A
T1
T2
Graf zależności
B
v
Przyczyna leży w cyklu grafu zależności.
Wynik T1 zależy od T2 i vice-versa.
PJWSTK, SZB, Lech Banachowski
14/62
Anomalie przy przeplataniu akcji
v
Odczyt niezatwierdzonych danych "dirty
read":
T1:
T2:
R(A), W(A),
R(A), W(A), C
R(B), W(B), C
Plan szeregowalny.
v
Niepowtarzalny odczyt:
T1:
T2:
R(A),
R(A), W(A), C
R(A), W(A), C
Plan nie szeregowalny.
PJWSTK, SZB, Lech Banachowski
15/62
Anomalie przy przeplataniu akcji (c.d)
v
T1:
T2:
Nadpisanie niezatwierdzonych danych:
W(A),
W(A), W(B), C
R(B), 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
T1:
T2:
R(A), W(A),
R(A), W(A), C
R(B), W(B) ?Rollback
jest planem szeregowalnym ale nie odtwarzalnym.
PJWSTK, SZB, Lech Banachowski
17/62
Podstawowe rodzaje blokad
v
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.
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 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ę.
PJWSTK, SZB, Lech Banachowski
20/62
Własności protokołu Strict 2PL
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 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.
PJWSTK, SZB, Lech Banachowski
22/62
Słabsze wersje protokołu 2PL
v
v
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ść.
v
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).
23/62
PJWSTK, SZB, Lech Banachowski
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
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.
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
T1: S(A), R(A),
S(B)
T2:
X(B),W(B)
X(C)
T3:
S(C), R(C)
X(A)
T4:
X(B)
T1
T2
T1
T2
T4
T3
T3
T3
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 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).
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, 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.
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
nad-obiekcie (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, 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 2PL
v
v
v
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.
PJWSTK, SZB, Lech Banachowski
39/62
Wielowersyjność – inne podejście niż
Strict 2PL
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
v
v
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.
PJWSTK, SZB, Lech Banachowski
41/62
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.
Poziom izolacji
Niezatw- Niepowtarzalny
ierdzony odczyt
odczyt
Fantomy
Read Uncommitted TAK
TAK
TAK
Read Committed
NIE
TAK
TAK
Repeatable Reads
NIE
NIE
TAK
Serializable
NIE
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
v
ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED;
………
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-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).
PJWSTK, SZB, Lech Banachowski
45/62
v
v
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.
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-2PL.
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 2PL2.
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)
50/62
PJWSTK, SZB, Lech Banachowski
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ć.
PJWSTK, SZB, Lech Banachowski
51/62
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
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.
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ę
v
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
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, 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ść:
u before-image (czyli poprzednia wartość), przechodzi na wartość
u after-image (czyli nową wartość).
– poprzedniLSN 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
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).
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
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ę.
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- 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.
PJWSTK, SZB, Lech Banachowski
70/62
Dziennik powtórzeń i odtwarzanie
v
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.
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
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
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
v
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.
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ń.
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