Microsoft PowerPoint - W5_bd_pd [tryb zgodno\234ci]
Transkrypt
Microsoft PowerPoint - W5_bd_pd [tryb zgodno\234ci]
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 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 Przykład 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 Transakcje Przykład cd 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 Pożądane właściwości transakcji (ACID) 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. Przykład 7 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 Transakcja przelewu kwoty N z konta A na konto B Transakcja logiczna a transakcja fizyczna Przykład cd. Problem utraconej aktualizacji 11 Problem aktualizacji tymczasowej 12 T1 T2 T1 Odczytaj_element (X); X:=X-N; Zapisz_element (X); Odczytaj_element (X); X:=X-N; Odczytaj_element (X); X:=X+M; Zapisz_element(X); Odczytaj_element (X); X:=X+M; Zapisz_element (X); Odczytaj_element (Y); Zapisz_element (Y); Zapisz_element(X); Y:=Y+N; Zapisz_element (Y); T2 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 13 Odczyt niepowtarzalny 14 T1 Odczytaj_element (X); X:=X-N; Zapisz_element (X); 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) T2: R(X), W(X) T2 Suma:=0; Odczytaj_element(A); suma:=suma+A; ... Odczytaj_element (X); suma:=suma+X; Odczytaj_element (Y); suma:=suma+Y; Czas -------> Odczytaj_element (Y); Y:=Y+N; Zapisz_element (Y); Gdzie: R(X) – odczytaj_ element X, W(X) – zapisz_element X Diagram przejść stanów związanych w wykonaniem transakcji Operacje związane z transakcjami 15 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 ZAKOŃCZ_TRANSAKCJĘ – należy zweryfikować czy zmiany wprowadzone przez transakcję mogą zostać zatwierdzone, czy transakcja ma być anulowana ZATWIERDŹ_TRANSAKCJĘ (COMMIT)– oznaczenie udanego zakończenia transakcji WYCOFAJ (ROLLBACK)– nieudane zakończenie transakcji Odczytaj zapisz Rozpocznij transakcję Zakończ transakcję Aktywna Anuluj zatwierdź Zatwierdzona częściowo Zatwierdzona Anuluj awaria Zakończona Dziennik systemowy (ang. log) 17 Punkt zatwierdzenia transakcji 18 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): 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ć. [rozpocznij_transakcję,T] [zapisz_element, T,X, stara wartość, nowa wartość] [odczytaj_element, T,X] [zatwierdź, T] [anuluj,T] Harmonogramy (plany) transakcji 19 Przykład 20 T1 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. T2 Odczytaj_element (X); X:=X-N; Odczytaj_element (X); X:=X+M; Zapisz_element (X); Odczytaj_element (Y); Y:=Y+N; Zapisz_element (Y); Zapisz_element(X); Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y) a: anulowanie; c – zatwierdzanie transakcji Możliwości odtwarzania harmonogramów 21 Szeregowalność harmonogramów 22 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 (-) 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 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) 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: T2: r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c r(x), x=x+m, w(x),c Sc (nieszeregowy, wynik: x=92, y=93) T1:r(x), x:=x-n; T2: w(x), r(y), r(x), x=x+m, y=y+n, w(y),c w(x),c Sd (nieszeregowy, wynik: x=89, y=93) T1:r(x), x:=x-n,w(x), T2: r(y), y=y+n, w(y),c 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. Protokół ścisłego blokowania dwufazowego (Strict 2PL) Blokady 25 26 Blokady (zamki) – podstawowy mechanizm zapobiegający konfliktom przy współbieżnie wykonywanych transakcjach 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ę 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. Protokół ścisłego blokowania dwufazowego (Strict 2PL) Protokół blokowania dwufazowego 2PL 28 27 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: 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) T2: a 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: 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) Zapobieganie Co jakiś czas sprawdzaj, czy w grafie jest cykl. Jeśli jest wycofaj jedną z transakcji w cyklu Wykrywania Przykład: Ustalanie limitu oczekiwania na blokadę (metoda timeout) T1:S(A), R(A) • S(B) T2: X(B), W(B) Zapobieganie 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 X(C) T3: S(C), R(C) X(A) T4: X(B) Graf oczekiwań na zwolnienie blokady: