Wykład 3 Wojciech Pieprzyca Systemy Baz Danych Wykład 3 Wojciech Pieprzyca

Transakcje Dane przechowywane w bazie danych powinny być spójne tzn. powinny odzwierciedlać bieżący stan modelowanej rzeczywistości. System zarządzania bazą danych odpowiada za to, aby skutkiem wykonania określonej operacji (grupy operacji), było przeprowadzanie bazy danych z jednego stanu spójnego do innego stanu spójnego. Dotrzymanie powyższych warunków może jednak być zagrożone poprzez jedno z poniższych zjawisk: Awarie sprzętu i oprogramowania, Współbieżny dostęp do bazy wielu użytkowników, Rozproszenie bazy danych.

Transakcje Klasycznym przykładem jest operacja przelewu bankowego pewnej kwoty z konta A na konto B. Składa się ona z kilku operacji elementarnych: Sprawdzenie czy na koncie A znajdują się wymagane fundusze, Pobranie kwoty z konta A, Dopisanie kwoty do konta B. Na pierwszy rzut oka powyższe operacje są jasne i nieskomplikowane. Analiza tego przypadku prowadzi jednak do kilku możliwych anomalii: Brak możliwości przeprowadzenia wszystkich operacji, np. awaria po pobraniu kwoty z konta A, a przed dopisaniem jej do konta B, Jednoczesne odczyt i zapis wartości dla tego samego konta przez wielu użytkowników bazy danych.

Transakcje Opisane wcześniej problemy rozwiązuje się stosując mechanizm transakcji. Transakcja jest sekwencją logicznie ze sobą powiązanych operacji, które przeprowadzają bazę danych z jednego spójnego stanu w drugi stan spójny. Przeprowadzane zwykle operacje to odczyt/zapis danych, zatwierdzenie transakcji, odrzucenie transakcji. Przykład transakcji: start transaction //sprawdzenie warunków początkowych update konta set stan = stan – kwota where id_konta=A; update konta set stan = stan + kwota where id_konta = B; //sprawdzenie warunków końcowych commit (rollback)

Transakcje Podstawowe zasady transakcji (ACID): Atomowość (Atomicity) – operacje wchodzące w skład transakcji są niepodzielne tzn. mogą być wykonane wszystkie z powodzeniem albo wcale Spójność (Consistency) – transakcja przeprowadza bazę z jednego stanu spójnego w inny stan spójny. W trakcie przeprowadzania transakcji baza może być chwilo niespójna, jednak po jej zakończeniu musi powrócić do stanu spójności. Izolacja (Isolation) – transakcje wzajemnie na siebie nie oddziałują, mogą być co prawda wykonywane współbieżnie (równocześnie), ale widzą stan danych taki jak gdyby były wykonywane sekwencyjnie. Trwałość (Durability) – transakcje zatwierdzone nie mogą zostać odwołane ani utracone np. w wyniku awarii. Wymusza to istnienie odpowiednich mechanizmów odtwarzania bazy danych np. dziennika zdarzeń bazy danych.

Transakcje Poniższy graf przedstawia możliwe stany w czasie wykonywania transakcji: Begin Transaction – rozpoczęcie transakcji Read/Write – operacje odczytu/zapisu End Transaction – zakończenie transakcji Partially Comitted – transakcja częściowo zatwierdzona Comitted – transakcja zatwierdzona Failed – transakcja wycofana Terminated – transakcja zakończona zatwierdzeniem lub wycofaniem

Transakcje Podział transakcji według różnych kryteriów: Kryterium porządku operacji: Transakcje sekwencyjne – wykonywane jedna po drugiej. Transakcje współbieżne – wykonywane równocześnie. Kryterium zależności operacji: Transakcje zależne od danych – zbiór danych nie jest w całości znany przed rozpoczęciem transakcji, ale dopiero w trakcie trwania transakcji uzupełniany o dodatkowe informacje konieczne do pomyślnego zakończenia transakcji. Transakcje niezależne od danych – zbiór danych jest w całości znany przed rozpoczęciem transakcji. Kryterium typu wykonywanych operacji: Transakcje odczytu (read only) – możliwy tylko odczyt danych Transakcje aktualizujące (read/write) – możliwy odczyt i zapis danych

Transakcje Mechanizmy ułatwiające realizowanie transakcji: Blokady (locks) obiektów bazy danych (np.blokada rekordu) – tymczasowo uniemożliwia dostęp do zablokowanego obiektu przez inne transakcje. Dziennik zdarzeń (log) – zapisywane są w nim wszystkie zmiany przeprowadzane na bazie danych, tak aby w razie awarii możliwe było wycofanie operacji niedokończonej transakcji i odtworzenie spójnego stanu bazy danych. Kopia bezpieczeństwa (backup) – wykonywana okresowo kopia całej bazy danych, aby umożliwić odtworzenie danych po awarii.

Transakcje Przykład transakcji: T1: BEGIN A=A+100, B=B-100 END Z całą pewnością jeżeli te dwie transakcje będą wykonywane sekwencyjnie to otrzymany wynik będzie poprawny, jednak w przypadku współbieżnego wykonania może już tak nie być. Przypadek poprawny T1: A=A+100 B=B-100 T2: A=A*1.04 B=B*1.04 Przypadek błędny: T1: A=A+100 B=B-100 T2: A=A*1.04 B=B*1.04

Transakcje Plan wykonania transakcji – jest to ustalenie harmonogramu (kolejności) wykonywania operacji odczytu/zapisu przy współbieżnej realizacji transakcji Plan szeregowy – umieszcza wykonywane transakcje w pewnym ciągu, najpierw operacje jednej transakcji, później operacje drugiej transakcji, itd. Plan szeregowalny – jest to plan równoważny planowi szeregowemu tzn. wykonuje te same operacje odczytu/zapisu i operuje na tych samych wartościach oraz prowadzi do tego samego wyniku co plan szeregowy, jednak transakcje mogą być wykonywane współbieżnie.

Transakcje Potencjalne problemy pojawiające się przy współbieżnym wykonywaniu transakcji: Odczyt danych niezatwierdzonych (tzw. brudny odczyt – dirty read) – pojawia się gdy transakcja T2 próbuje odczytać (zmienić) dane nie zatwierdzone przez współbieżnie działającą transakcję T1. T1: R1(A), W1(A) R1(B), W1(B), R T2: R2(A), W2(A), C Zgodnie z zasadą spójności transakcja przeprowadza bazę z jednego stanu spójnego w inny, ale w trakcie wykonania transakcji stan może być tymczasowo niespójny. W ten sposób inna transakcja, działająca współbieżnie może tę niespójny stan odczytać i uznać za poprawny. W przykładzie transakcja T2 odczytała wartość A, która nie została jeszcze zatwierdzona przez T1. Co więcej transakcja T1 na końcu działania próbuje wycofać wszystkie operacje (Rollback), jednak transakcja T2 wcześniej zatwierdziła stan wartości A w bazie (Commit), co uniemożliwia wycofanie operacji zapisu dokonanego przez transakcję T1.

Transakcje Niepowtarzalny odczyt (repeatable read) – dana transakcja T1 w trakcie swojego działania dwukrotnie odczytuje ten sam obiekt, jednak wartość przy drugim odczycie różni się od wartości odczytanej po raz pierwszy. Wynika to z tego, że współbieżnie działająca transakcja T2 zmieniła wartość obiektu w trakcie działania transakcji T1. Klasycznym przykładem tego przypadku jest rezerwacja np. pokoi hotelowych. Transakcja T1 podaje informacje o tym, że dany pokój jest wolny i przekazuje go klientowi do akceptacji. W tym samym czasie transakcja T2 robi to samo i drugi klient dokonuje rezerwacji tego samego pokoju. Przy próbie akceptacji rezerwacji przez klienta pierwszego (transakcje T1) wystąpi błąd bowiem pokój został w międzyczasie zarezerwowany przez klienta drugiego (transakcję T2). T1: R1(A) R1(A), W1(A), C T2: R2(A), W2(A), C

Transakcje Nadpisywanie niezatwierdzonych danych - występuje, gdy transakcja T1 zmienia obiekt A, jednak nie zatwierdza tych zmian, a następnie transakcja T2 również dokonuje zmian na obiekcie A i zatwierdza zmiany. W ten sposób zapisy dokonane przez transakcję T1 zostają utracone poprzez ich nadpisanie przez transakcję T2. T1: W1(A) W1(B),C T2: W2(A), W2(B), C Z uwagi na opisane powyżej problemy plan wykonania transakcji powinien być odtwarzalny tzn. w każdej chwili powinna być możliwość wycofania danej transakcji. Aby to to było możliwe w bazie nie mogą występować zjawiska odczytu danych niezatwierdzonych oraz nadpisywania niezatwierdzonych danych.

Transakcje Jedną z metod uzyskiwania planu odtwarzalnego i eliminowania problemów związanych z transakcjami jest stosowanie blokad. Zazwyczaj wyróżnia się dwa rodzaje blokad: Współdzielona typu S (Shared lock) – umożliwia współdzielony dostęp (odczyt, bez możliwości zapisu) do zasobu, np. kilka transakcji może odczytywać wiersze tej samej tabeli. Ten rodzaj blokady na jeden obiekt może założyć kilka transakcji naraz. Oznaczenie: S(A). Wyłączna typu X (eXclusive lock) – wyłączone prawo zmiany obiektu dla jednej transakcji. Wyłączna blokada obiektu może być przydzielona tylko dla jednej transakcji. Jeżeli na obiekcie założono blokadę typu X, to żadna inna blokada nie może być założona na tym obiekcie, do czasu usunięcia blokady X. Oznaczenie: X(A).

Transakcje Dwufazowy protokół ścisłego blokowania (Strict 2PL) – gwarantuje on realizację planów szeregowalnych i odtwarzalnych. Zasady protokołu ścisłego blokowania: Każda transkacja przed odczytem danych z obiektu musi uzyskać blokadę S (współdzieloną), a przed zapisem danych do obiektu blokadę X (wyłączną). Jeżeli transakcja otrzyma blokadę wyłączną X na danym obiekcie, to żadna inna transakcja nie może już założyć blokady na tym obiekcie do czasu zdjęcia blokady X. Jeżeli transakcja otrzyma blokadę współdzieloną S na danym obiekcie, to żadna inna transakcja nie może założyć blokady X na tym obiekcie do czasu zdjęcia blokady S. Jeżeli transakcja nie może w danej chwili założyć odpowiedniej blokady na obiekcie, to oczekuje w kolejce transakcji oczekujących. Gdy dana transakcja kończy się, wszystkie blokady z nią związane są zwalniane.

Transakcje Dwufazowy protokół ścisłego blokowania eliminuje anomalia związane z odczytem i zapisem omawiane wcześniej. Uzasadnienie: Odczyt danych niezatwierdzonych – niemożliwy, ponieważ przed jakimkolwiek zapisem ustalana jest blokada wyłączna X na obiekcie, a więc do czasu zatwierdzenia zmiany, żadna inna transakcja nie będzie mogła odczytywać danych z obiektu. Niepowtarzalny odczyt – niemożliwy, ponieważ przy pierwszym odczycie wartości obiektu transakcja zakłada blokadę S i wówczas żadna inna transakcja nie może zmienić wartości tego obiektu do czasu zdjęcia blokady S. Nie jest możliwe więc odczytanie innej wartości obiektu w czasie trwania jednej transakcji. Nadpisywanie niezatwierdzonych zmian – niemożliwe, ponieważ przed jakimkolwiek zapisem na obiekt nakładana jest blokada wyłączna X, które uniemożliwia zapis innym transakcjom do danego obiektu.

Transakcje Wadą protokołu dwufazowego jest możliwość wystąpienia zakleszczeń (deadlocks) czyli jednoczesnej blokady założonej na obiekt przez wiele transakcji, które wzajemnie oczekują od siebie zwolnienia transakcji, co jednak nie jest możliwe do zrealizowania. 1) Transakcja T1 zablokowała zasób A i żąda dostępu do zasobu B 2) Transakcja T2 zablokowała zasób B i żąda dostępu do zasobu A. 3) Ani T1, ani T2 nie mogą dalej kontynuować jakiejkolwiek akcji. Można stwierdzić, że system „zawiesił się”. Transakcja T1 A Transakcja T2 B

Transakcje Wykrywanie zakleszczeń przy użycie grafu oczekiwań: Dla każdej transakcji tworzymy wierzchołek. Tworzymy krawędź skierowaną Ti  Tj, jeżeli transakcja Ti czeka na zasób zablokowany w danej chwili przez transakcję Tj. Zakleszczenia mają miejsce gdy w grafie oczekiwań występują cykle. Po wykryciu zakleszczenia, jedna z transakcji tworząca cykl powinna zostać przerwana.