Transakcje Wykład z bazy danych dla studentów matematyki 19 kwietnia 2015
Transakcje Jedno z podstawowych pojęć współczesnych systemów baz danych. Umożliwiaja współbieżny dostęp do baz danych dostarczajac mechanizmów synchronizacji. Integruja kilka operacji w jedna niepodzielna całość. Możliwe jest bezpieczne przerwanie transakcji w trakcie wykonania. Ułatwiaja odtwarzanie po awariach.
Transakcje Przykład: przelew 100 złp z konta bankowego jednego klienta (np. Kangurzycy) na konto innego klienta (np. Tygrysa). W SQL UPDATE Konta SET saldo = saldo - 100.00 WHERE klient = Kangurzyca ; UPDATE Konta SET saldo = saldo + 100.00 WHERE klient = Tygrys ; Co stanie się, jeśli po wykonaniu pierwszego polecenia nastapi awaria dysku?
Transakcje Podobny problem występuje nawet przy pojedynczej modyfikacji. Rozwiazanie: transakcyjny system baz danych. Gwarantuje zapisanie modyfikacji w sposób trwały przed zakończeniem transakcji.
Współbieżność Przykład: dwie osoby równocześnie pobieraja 500 złotych z tego samego konta używajac (różnych) bankomatów. System bazy danych powinien zadbać, żeby obie operacje zostały odnotowane, tzn. stan konta należy zmniejszyć dwukrotnie. Podobna sytuacja występuje w innych programach W wielu edytorach tekstu jeśli dwie osoby równocześnie modyfikuja ten sam dokument, utrwalone zostaja tylko zmiany jednej z nich. Rzadko obserwowane, bo obecnie pracuje się głównie na komputerach osobistych użytkownicy często jawnie przesyłaja sobie dokument. Ale mamy rozproszone systemy plików, np. NFS, więc jeśli obie osoby korzystaja z nich, moga edytować ten sam plik na serwerze plików.
Współbieżność Programiści pracujacy wspólnie nad ta sama aplikacja maja swoje rozwiazanie problemu: współbieżne systemy kontroli wersji (np. CVS, GIT). Programy źródłowe przechowuje się w repozytorium (rodzaj bazy danych). Dwie osoby moga pobrać do modyfikacji ten sam moduł z bazy danych. Podczas zwracania (zmodyfikowanego) modułu do bazy danych pierwsza osoba nie musi robić nic: poprawki sa po prostu akceptowane. Modyfikacje drugiej osoby sa porównywane z wersja w repozytorium: wszelkie stwierdzone konflikty musza być rozwiazane przez autora. Ten pomysł, choć dość sensowny, nie pasuje jednak do baz danych: zbyt wielu użytkowników pracujacych współbieżnie oraz zbyt krótkie transakcje.
Semantyka bazy danych Określa się zbiór legalnych stanów. Operacje modeluje się jako funkcje: operacja: Stan Stan
Semantyka bazy danych Operacje powinny przeprowadzać legalne stany w legalne stany. Jednak w czasie wykonywania powiazanego ciagu operacji przejściowo baza danych może przyjmować nielegalne stany. Takie ciagi obudowujemy transakcjami.
Transakcje Transakcja to ciag operacji do wspólnego niepodzielnego wykonania. Współbieżne wykonywanie transakcji wymaga zachowania własności ACID (Atomicity, Consistency, Isolation, Durability): niepodzielności: wszystko-lub-nic, transakcja nie może być wykonana częściowo; integralności: po zatwierdzeniu transakcji musza być spełnione wszystkie warunki poprawności nałożone na bazę danych; izolacji: efekt równoległego wykonania dwu lub więcej transakcji musi być szeregowalny; trwałości: po udanym zakończeniu transakcji jej efekty na stałe pozostaja w bazie danych.
Transakcje W trakcie wykonywania transakcja może być wycofana w dowolnym momencie. Wszelkie wprowadzone przez nia zmiany danych zostana wtedy zignorowane. Realizacja: tymczasowe wykonywanie transakcji. Zmiany danych sa tylko obliczane i zapisywane w specjalnym dzienniku transakcji. Po zakończeniu wykonywania transakcji następuje jej zatwierdzenie, w wyniku czego zmiany sa utrwalane w bazie danych.
Konflikty współbieżności Odwiedźmy bazę danych piwiarni i zajmijmy się tabela Sprzedaje(bar,piwo,cena). Przypuśćmy, żę w barze U Szwejka sprzedaje się tylko dwa gatunki piwa: Okocim po 2,50 zł i Żywiec po 3,50 zł. Dzielny redaktor gazety postanowił zbadać (używajac naszej bazy danych), jaka jest najwyższa i najniższa cena piwa U Szwejka. W tym samym czasie szef piwiarni zdecydował, że przestaje sprzedawać dotychczasowe piwa i przerzuci się na Heineken po 4,50 zł.
Konflikty współbieżności Pan redaktor wykonuje dwa następujace zapytania (po lewej stronie ich umowne nazwy) (max) (min) SELECT MAX(cena) FROM Sprzedaje WHERE bar = U Szwejka ; SELECT MIN(cena) FROM Sprzedaje WHERE bar = U Szwejka ;
Konflikty współbieżności A równocześnie szef piwiarni wykonał dwa inne polecenia SQL (del) (ins) DELETE FROM Sprzedaje WHERE bar = U Szwejka ; INSERT INTO Sprzedaje VALUES( U Szwejka, Heineken,4.50);
Przeplecione polecenia Przypuśćmy, że powyższe polecenia zostały wykonane w następujacej kolejności: max, del, ins, min. Popatrzmy na efekty: Ceny Operacja Wynik {2.50,3.50} max 3,50 {2.50,3.50} del {} ins {4.50} min 4,50 A więc ostatecznie MAX(...) < MIN(...)!
Przeplecione polecenia Aby tego uniknać, powinniśmy operacje poszczególnych osób pogrupować w transakcje. Wtedy obie operacje pana redaktora wykonaja się bezpośrednio po sobie, nie wiadomo tylko, czy przed, czy po zmianie repertuaru. Zwróćmy uwagę, że redaktor wykonywał tylko instrukcje SELECT, co przeczy obiegowej opinii Tylko operacje modyfikacji musza być umieszczane w transakcjach.
Problem wycofywania Szef piwiarni po wykonaniu (bez użycia transakcji) ciagu operacji (del)(ins) postanowił wycofać druga z nich (ROLLBACK) Jeśli redaktorowi udało się wstrzelić zapytanie między (ins) i ROLLBACK, zobaczy wartość (4,50), której nigdy nie było w bazie danych. Rozwiazaniem jest znowu użycie transakcji: Efekty transakcji nie sa widziane przez innych, dopóki transakcja nie zostanie zatwierdzona (COMMIT).
Transakcje Dla zapobiegania konfliktom używa się wewnętrznie blokowania dostępu do elementów danych używanych przez transakcję. Poziomy ziarnistości blokad: cała baza danych, pojedyncza relacja, blok wierszy, pojedynczy wiersz.
Rodzaje transakcji To co widzieliśmy to klasyczny obraz transakcji w kontekście baz danych. Istnieja także inne typy transakcji Bezpośrednie (direct); Konwersacyjne kilkakrotna wymiana informacji klient/serwer; Wiazane (chained) wymagaja przechowywania kontekstu; Zagnieżdżone Długotrwałe. Kolejkowane wykonywane z opóźnieniem, np. w celu grupowania kilku transakcji.
Transakcje w SQL Poczatek zwykle domyślny pierwsza operacja na bazie danych. W Postgresie podczas pracy interakcyjnej należy wywołać BEGIN [WORK] Zakończenie przez zatwierdzenie COMMIT; lub anulowanie (wycofanie) ROLLBACK; Uwaga: przy wystapieniu błędu (np. naruszenie ograniczeń) ma miejsce niejawne wycofanie transakcji.
Transakcje w SQL Domyślnie transakcje zezwalaja na zapis. Rezygnuje się z tego np. jeśli chcemy dokonać dłuższego skomplikowanego przeszukania spójnego stanu bazy danych. Transakcję należy wtedy poprzedzić deklaracja SET TRANSACTION LEVEL READ ONLY; W transakcji takiej nie moga wystapić operacje modyfikacji, ale za to nie sa widoczne zmiany dokonywane przez inne współbieżne transakcje. Domyślnie przyjmowany jest poziom READ WRITE, tak jak gdyby podano SET TRANSACTION LEVEL READ WRITE;
Poziomy izolacji transakcji Poziom izolacji dla transakcji ustalamy korzystajac z SET TRANSACTION ISOLATION LEVEL [READ COMMITTED SERIALIZABLE]; Poziom izolacji opisuje tylko, jak dana transakcja chce widzieć bazę danych (nie dotyczy bezpośrednio innych transakcji) Poziom izolacji SERIALIZABLE gwarantuje semantykę sekwencyjna (w zasadzie jedyna w pełni poprawna) dla transakcji (ACID) przez wycofywanie transakcji naruszajacych ja. Poziom READ COMMITTED jest łagodniejszy: dowolne modyfikacje z innych zatwierdzonych transakcji staja się natychmiast widoczne w bieżacej transakcji. Mówimy, że odczyt nie jest powtarzalny: kilka kolejnych wywołań tego samego zapytania w ramach pojedynczej transakcji może dać różne wyniki (bo inne zatwierdzone transakcje mogły zmodyfikować używane tabele).
Transakcje w SQL Standard dopuszcza również: REPEATABLE READ, gdy powtórzone zapytania w ramach transakcji daja zawsze te same wiersze co poprzednio, ale moga się pojawić dodatkowe wiersze: fantomy. READ UNCOMMITED, zezwalajacy na tzw. brudne odczyty (dirty reads): odczytanie danych zmodyfikowanych przez inna transakcję, która potem zostaje wycofana. W tym przypadku domyślnym poziomem transakcji jest READ ONLY, ponieważ READ WRITE jest na ogół zbyt ryzykowny.
Blokady w Oracle Jawne blokady można zakładać na cała tabelę LOCK TABLE tabela IN [SHARE EXCLUSIVE] MODE [NOWAIT]; SHARE oznacza blokadę dzielona (tylko przeciw zmianom). EXCLUSIVE to wyłaczna blokada dostępu (w celu dokonania zmian). NOWAIT chroni przed czekaniem, gdy nie można natychmiast założyć blokady. Zdjęcie blokad następuje przez wykonanie COMMIT lub ROLLBACK.
Blokady w Oracle Z punktu widzenia współbieżności lepiej jednak zakładać blokady na wybrane wiersze, np. gdy transakcja odczytuje pewne wiersze, a następnie dokonuje (zwykle w nich) zmian, można użyć SELECT... FOR UPDATE [NOWAIT]; Taka blokada też jest ważna do końca transakcji.
Realizacja transakcji Zarzadca transakcji, zarzadca dziennika i zarzadca blokad Każda modyfikacja jest najpierw zapisywana w dzienniku transakcji. Podczas odtwarzania po awarii (na podstawie ostatniego zachowanego zrzutu bazy danych) wykonuje się tylko operacje z zatwierdzonych transakcji.
Harmonogramy Harmonogram = ciag akcji z pewnego zbioru transakcji uporzadkowany w taki sposób, żeby zachować porzadek z poszczególnych transakcji. Harmonogram szeregowy (sekwencyjny): taki harmonogram, że całe transakcje sa w nim ustawione po kolei (tzw. serializacja transakcji). Dla harmonogramów szeregowych dozwolona jest dowolna permutacja transakcji, co powoduje brak unikalności finalnego stanu bazy danych. Prosty przykład: Transakcja T 1 mnoży zawartość pewnej komórki przez 3. Transakcja T 2 zwiększa zawartość tej samej komórki o 5. Dla zwiększenia przepustowości transakcje wykonuje się zwykle współbieżnie (z przeplotem operacji).
Szeregowalność Harmonogram szeregowalny to taki harmonogram, że jego stan końcowy jest taki sam, jak któregoś harmonogramu szeregowego. Uwaga: dla uproszczenia nie rozważamy transakcji przerwanych. Harmonogramy szeregowalne można otrzymać z szeregowych zamieniajac sasiednie akcje, dopóki nie spowoduje to konfliktu.
Zarzadzanie blokadami Zarzadca blokad dla transakcji. Dla SQL nezbędne blokady sa określane automatycznie. Interesujace pojęcie promowalnej blokady (upgrading lock): blokada dla odczytu które może być podniesiona później do blokady dla zapisu.
Znaczniki czasowe (timestamps) Inne podejście, dobre gdy dominuja operacje odczytu. Wszystkie elementy w bazie danych sa znakowane czasem ostatniej modyfikacji. Optymistyczne, przed modyfikacja sprawdza, czy posiadane dane sa wciaż aktualne (maja bieżacy znacznik). Jeśli nie, dane musza być ponownie pobrane i transakcja musi (być może częściowo) zostać powtórzona (lub wycofana).