Plan wykładu 2 BAZY DANYCH Wykład 5: Transakcje. Hurtownie danych. Transakcje Hurtownie danych Małgorzata Krętowska Wydział Informatyki Politechnika Białostocka Wprowadzenie Przykład Zmiany zachodzące w świecie rzeczywistym są zakodowane w aplikacji obsługującej bazę danych w postaci ciągu instrukcji, które powinny przekształcać bazę danych z jednego stanu spójnego w inny Problemy, na które może natknąć się aplikacja: Awarie systemu Współbieżny dostęp do danych Rozproszenie danych Aplikacja implementująca przelew kwoty N z konta A na konto B Problem 1 awaria systemu Po pobraniu kwoty N z konta A, i zapisaniu tej aktualizacji do bazy danych, wystąpiła awaria systemu. W wyniku awarii systemu wykonana została jedynie część operacji składających się na daną aplikację Problem 2 współbieżny dostęp do danych Operacje współbieżnie wykonywanych transakcji mogą naruszać spójność bazy lub generować niepoprawne wyniki Źródło: http://wazniak.mimuw.edu.pl/index.php?title=bazy_danych
Przykład cd Transakcje 6 Problem 3 - utrata danych w wyniku awarii Wyniki zakończonych aplikacji, buforowane w pamięci operacyjnej, mogą zostać utracone w wyniku awarii systemu Rozwiązanie tych problemów: transakcje Transakcja jest wykonywanym programem, który tworzy logiczną jednostkę przetwarzania w bazie danych. Transakcja składa się z jednej lub wielu operacji dostępu do bazy danych. Jednym ze sposobów określania zakresu transakcji jest wyróżnienie jawnych instrukcji begin i end transaction. Jeżeli operacje bazodanowe należące do transakcji nie aktualizują bazy danych, a tylko pobierają dane, o transakcji mówimy, że jest tylko do odczytu. 7 Pożądane właściwości transakcji (ACID) atomowość (atomicity) - cała transakcja powinna zostać przeprowadzona, albo żaden z jej elementów nie zostanie uwzględniony spójność (consistency) - np. miejsce w danym rejsie lotniczym nie może być przydzielone dwóm różnym pasażerom izolacja (isolation) - brak wpływu transakcji na siebie przy jednoczesnym ich przetwarzaniu trwałość (durability) - po zakończeniu transakcji jej wynik nie może zostać utracony Przykład Transakcja przelewu kwoty N z konta A na konto B
Przykład cd. Transakcja logiczna a transakcja fizyczna Problem utraconej aktualizacji Problem aktualizacji tymczasowej 11 T1 T2 12 T1 T2 X:=X-N; Zapisz_element (X); Odczytaj_element (Y); X:=X+M; X:=X-N; Zapisz_element (X); Zapisz_element (Y); X:=X+M; Zapisz_element(X); Y:=Y+N; Zapisz_element (Y); Zapisz_element(X); Transakcja T1 kończy się niepowodzeniem i musi zmienić wartość X z powrotem do jej oryginalnego stanu; w tym czasie T2 odczytuje jej tymczasową niepoprawną wartość
Problem błędnego podsumowania Odczyt niepowtarzalny 13 14 T1 X:=X-N; Zapisz_element (X); T2 Suma:=0; Odczytaj_element(A); suma:=suma+a;... Występuje wówczas, gdy transakcja T1 odczytuje element dwukrotnie, czy czym element ten zostaje zmieniony przez inną transakcję T2 między tymi dwoma odczytami Przykład: T1: R(X), R(X), W(X) Odczytaj_element (Y); Y:=Y+N; Zapisz_element (Y); suma:=suma+x; Odczytaj_element (Y); suma:=suma+y; T2: R(X), W(X) Czas -------> Gdzie: R(X) odczytaj_ element X, W(X) zapisz_element X 15 Operacje związane z transakcjami Diagram przejść stanów związanych w wykonaniem transakcji 16 Transakcja jest niepodzielną jednostką działań, które muszą być wykonane w całości lub w ogóle. Do celów odtwarzania system musi śledzić następujące operacje: ROZPOCZNIJ_TRANSAKCJĘ ODCZYTAJ lub ZAPISZ operacje odczytu i zapisu przeprowadzane na elementach bazy danych Rozpocznij transakcję Odczytaj zapisz Aktywna Zakończ transakcję Zatwierdzona częściowo zatwierdź Zatwierdzona ZAKOŃCZ_TRANSAKCJĘ należy zweryfikować czy zmiany wprowadzone przez transakcję mogą zostać zatwierdzone, czy transakcja ma być anulowana Anuluj Anuluj ZATWIERDŹ_TRANSAKCJĘ (COMMIT) oznaczenie udanego zakończenia transakcji awaria Zakończona WYCOFAJ (ROLLBACK) nieudane zakończenie transakcji
17 Dziennik systemowy (ang. log) W celu umożliwienia odtwarzania po awariach wpływających na transakcje system przechowuje dziennik, w którym śledzi wszystkie operacje związane z transakcjami, mające wpływ na wartości elementów bazy danych. Dziennik jest przechowywany na dysku i jest okresowo archiwizowany na taśmie, w celu zabezpieczenia go przed awariami. Rodzaje wpisów do dziennika (rekordy dziennika): [rozpocznij_transakcję,t] [zapisz_element, T,X, stara wartość, nowa wartość] [odczytaj_element, T,X] [zatwierdź, T] [anuluj,t] 18 Punkt zatwierdzenia transakcji Transakcja osiąga swój punkt zatwierdzenia, gdy wszystkie jej operacje zostaną z powodzeniem wykonane oraz ich wyniki zostaną zarejestrowane w dzienniku. Za punktem zatwierdzenia mówi się, ze transakcja została zatwierdzona, a jej działania za trwale zapisane w bazie Kolejną czynnością jest zapisanie do dziennika rekordu zatwierdzenia. Jeżeli nastąpi awaria wszystkie transakcje które rozpoczęły swoje działanie, a dla których nie ma wpisu w dzienniku należy wycofać. Harmonogramy (plany) transakcji Przykład 19 Gdy transakcje są wykonywane współbieżnie w technice przeplotu, kolejność wykonywania operacji związanych z różnymi transakcjami określa się mianem harmonogramu (historii, planu). Harmonogram S zbioru n transakcji T1, T2,.., Tn jest uporządkowaniem operacji transakcji podlegającym ograniczeniu, które określa, że dla każdej transakcji Ti należącej do harmonogramu S, operacje tej transakcji w S muszą występować w tej samej kolejności, w jakiej występują w Ti. 20 T1 X:=X-N; Zapisz_element (X); Odczytaj_element (Y); Y:=Y+N; Zapisz_element (Y); T2 X:=X+M; Zapisz_element(X); Sa: r1(x); r2(x); w1(x); r1(y); w2(x); w1(y) a: anulowanie; c zatwierdzanie transakcji
21 Możliwości odtwarzania harmonogramów Harmonogramy odtwarzalne dla których w momencie zatwierdzenia transakcji T już nigdy nie było konieczne jej wycofanie (lub inaczej: harmonogram, który umożliwia wycofanie każdej transakcji) Harmonogram S jest odtwarzalny, jeżeli żadna transakcja T w harmonogramie S nie jest zatwierdzona do momentu, aż wszystkie transakcje T, które zapisały element odczytywany przez transakcję T, zostaną zatwierdzone. S: r1(x), w1(x), r2(x), w2(x), c1, c2 (+) S: r1(x), w1(x), r2(x), w2(x), c2, c1 (-) Harmonogramy nieodtwarzalne nie spełniają powyższego wymogu, stąd nie powinno się pozwalać na ich występowanie (Przykłady: problem aktualizacji tymczasowej i problem utraconej aktualizacji) 22 Szeregowalność harmonogramów Pojęcie szeregowalności harmonogramów jest używane w celu identyfikowania, które harmonogramy są poprawne w przypadku, gdy wykonanie transakcji dopuszcza przeplot ich operacji. Harmonogram szeregowy harmonogram ustawiający wykonywanie transakcji w ciąg: najpierw akcje jednej transakcji, następnie akcje drugiej transakcji itd. Zakładając, że transakcje są niezależne, można założyć, że każdy harmonogram szeregowy jest poprawny Dwa harmonogramy są równoważne, jeżeli efekt realizacji obu harmonogramów jest taki sam dla każdego stanu bazy danych, tzn W1: Każda transakcja w obu planach odczytuje i zapisuje te same wartości W2: Po realizacji każdego z planów otrzymujemy ten sam stan bazy danych Przykład Plan szeregowalny 23 Zakładamy wartości początkowe x=90, y=90, n=3, m=2 Sa (szeregowy), wynik: x=89, y=93): T1:r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c T2: r(x), x=x+m, w(x),c Sb (szeregowy, wynik: x=89, y=93): T1: r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c T2: r(x), x=x+m, w(x),c Sc (nieszeregowy, wynik: x=92, y=93) T1:r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c T2: r(x), x=x+m, w(x),c Sd (nieszeregowy, wynik: x=89, y=93) T1:r(x), x:=x-n,w(x), r(y), y=y+n, w(y),c T2: r(x), x=x+m,w(x),c Plan (harmonogram) szeregowalny jest to plan, który jest równoważny pewnemu planowi szeregowemu (a przez to jest poprawny). Dzięki własnościom W1 i W2 plan szeregowalny zapewnia uzyskanie własności izolacji (W1) i spójności (W2). Plan szeregowalny nie daje gwarancji, że po wycofaniu transakcji nie trzeba będzie wycofywać akcji innych transakcji, co może być niewykonalne, gdy jedna z transakcji zostanie już zatwierdzona. Brak gwarancji spełnienia własności atomowości i trwałości.
25 Blokady Blokady (zamki) podstawowy mechanizm zapobiegający konfliktom przy współbieżnie wykonywanych transakcjach Rodzaje blokad: Współdzielona, typu S (ang. shared lock) daje transakcji współdzielony dostęp do zasobu (kilka transakcji może jednocześnie odczytywać wiersze z 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ć blokady drugiego rodzaju, tzn. wyłącznej Wyłączna, typu X (ang. exclusive lock) daje transakcji wyłączne prawo do zmian obiektu. Tylko jedna transakcja może mieć założoną wyłączną blokadę na obiekcie i w tym czasie nie może być na obiekcie założonej żadnej innej blokady, nawet współdzielonej. Istnieje metoda zakładania blokad gwarantująca powstanie i realizację planów wyłącznie szeregowalnych i odtwarzalnych protokół ścisłego blokowania dwufazowego. 26 Protokół ścisłego blokowania dwufazowego (Strict 2PL) Każda transakcja musi uzyskać blokadę S na obiekcie zanim odczyta ten obiekt oraz blokadę X na obiekcie przed zapisaniem go. Jeśli transakcja trzyma blokadę X na obiekcie, żadna inna transakcja nie ma prawa założyć żadnej blokady 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. Wszystkie blokady trzymane przez transakcję są zwalniane jednocześnie, w chwili, gdy transakcja kończy się 27 Protokół ścisłego blokowania dwufazowego (Strict 2PL) Można w nim wyróżnić dwie fazy: Transakcja zakłada blokady i dokonuje wymaganych odczytów i zapisów na obiektach, na których założyła blokadę Transakcja wykonuje COMMIT/ROLLBACK jednocześnie zwalniając wszystkie blokady Protokół Strict 2PL nie dopuszcza do anomalii utraconej aktualizacji, aktualizacji tymczasowej, błędnego podsumowania oraz niepowtarzalnego odczytu: 28 Protokół blokowania dwufazowego 2PL Zamiast punktu w protokole Strict 2PL: Wszystkie blokady trzymane przez transakcję są zwalniane jednocześnie, w chwili, gdy transakcja kończy się Występuje sformułowanie: Transakcja nie może założyć żadnej nowej blokady po zwolnieniu jakiejkolwiek blokady. Protokół 2PL prowadzi do planów szeregowalnych, ale nie gwarantuje planów odtwarzalnych. Przykład: T1: R(X) W(X) a T2: R(X) W(X) c
Zakleszczenia (deadlocks) Zakleszczenia 29 Zjawisko zakleszczenia występuje wówczas, kiedy dwie lub więcej transakcji wzajemnie blokują sobie potrzebne do kontynuowania swojego działania obiekty Zakleszczenie- jest to cykl transakcji oczekujących wzajemnie na zwolnienie blokady przez inną transakcję w cyklu. Sposoby radzenia sobie z zakleszczeniami: Zapobieganie Zapobieganie Wykrywania Ustalanie limitu oczekiwania na blokadę (metoda timeout) ustalenie priorytetu między transakcjami. Nie dopuszcza się aby transakcja z wyższym priorytetem czekała na transakcje z niższym priorytetem W przypadku zakleszczenia transakcja z niższym priorytetem zostaje wycofana przez system Wykrywanie zakleszczeń polega na analizie, która transakcja oczekuje na zwolnienie blokady przez która transakcję i sprawdzaniu, czy występuje cykl Utwórz graf oczekiwań na zwolnienie blokady (węzły transakcje, krawędź Ti do Tj jeśli transakcja Ti oczekuje na zwolnienie blokady przez Tj) Co jakiś czas sprawdzaj, czy w grafie jest cykl. Jeśli jest wycofaj jedną z transakcji w cyklu Przykład: T1:S(A), R(A) S(B) T2: X(B), W(B) T3: T4: S(C), R(C) X(C) Graf oczekiwań na zwolnienie blokady: X(A) X(B)