Transakcje Bazy danych 155
156 Bazy danych Przegląd zagadnień Transakcje czym sa i po co sie je stosuje Postulaty ACID Transakcje w SQL Stosowanie zamków oraz problemy z zakleszczania Stemple czasowe i ziarnistosc transacji Podsumowanie Laboratorium W tym wykładzie zapoznamy się z bardzo waŝnym pojęciem baz danych - transakcją. Transakcja słuŝy do zapewnienia spójności danych i ma wpływ na wydajność bazy. Obsługa transakcji nie jest rzeczą prostą i wymaga rozwiązywania wielu problemów. O niektórych z nich będziemy wspominać w czasie tego wykładu.
Bazy danych 157 Transakcje czym są i po co się je stosuje Transakcja jest ciągiem operacji wykonywanych na bazie, które to operacje są niepodzielne i muszą być wykonane w całości. Transakcja jest więc pewną jednostką logiczną operowania na bazie. Podlega ona kontroli i sterowaniu. KaŜda transakcja moŝe składać się z następujących operacji: czytanie danej x przez transakcje T, zapisanie danej x przez transakcję T, wycofanie transakcji T, zatwierdzenie transakcji T. Transakcje słuŝą do zapewnienia bazie spójności oraz umoŝliwić równoległe operacje na bazie danych. Jeśli wiele procesów działa jednocześnie na bazie danych, to moŝe łatwo dojść do utraty spójności danych, a co za tym idzie do błędów i otrzymywania nieprawdziwych zestawów danych. W tabeli 7.1 pokazano schemat działania dwóch procesów A i B działających na tych samych danych. Proces A i B odczytuje daną X z bazy, a następnie zwiększa jej wartość o jeden i zapisuje do bazy. Tabela7.1 Przykład procesów równoległych bez utraty spójności Czas Proces A Proces B Wartość X A Wartość X B 1 Czyta X 5 2 Czyta X 5 5 3 X=X+1 6 5 4 X=X+1 6 6 5 Zapisuje X 6 6 6 Zapisuje X 6 6 W tabeli 7.1 przedstawiono dwa procesy równoległe, które nie prowadzą do utraty spójności. Tabela7.2 Przykład procesów równoległych z utratą spójności Czas Proces A Proces B Wartość X A Wartość X B 1 Czyta X 5 2 X=X+1 6 3 Czyta X 6 6 4 X=X+1 6 7 5 Zapisuje X 6 7 6 Zapisuje X 6 7
158 Bazy danych W tabeli 7.2 przedstawiono natomiast dwa procesy równoległe, które prowadzą do utraty spójności. Transakcja zabezpiecza równieŝ przed częściowym wykonaniem zbioru operacji, które mogą być przerwane na przykład w wyniku awarii. Klasycznym przykładem jest operacja polegająca na wypłacaniu pieniędzy z bankomatu. W uproszczeniu operacje realizowane w czasie wypłaty pieniędzy z bankomatu są następujące: 1. Klient wczytuje kartę magnetyczną i jest rozpoznawany. 2. Klient określa sumę wypłaty. 3. Konto klienta jest sprawdzane. 4. Konto jest zmniejszane o sumę wypłaty. 5. Wysyłane jest zlecenie do kasy. 6. Bankomat odlicza sumę i koryguje stan gotówki w bankomacie. 7. Bankomat wypłaca klientowi pieniądze. Zaistnienie awarii w kroku 5 lub 6 moŝe prowadzić do niezbyt przyjemnej sytuacji dla posiadacza konta. Transakcje pozwalają na uniknięcie tego typu niespodzianek.
Bazy danych 159 Postulaty ACID Przyjmuje się, Ŝe kaŝda transakcja powinna spełniać cztery postulaty. Są to tak zwane postulaty AICD. Atomowość (ang. atomicity) - w ramach jednej transakcji wykonują się albo wszystkie operacje, albo Ŝadna. Spójność (ang. consistency) - o ile transakcja zastała bazę danych w spójnym stanie, po jej zakończeniu stan jest równieŝ spójny (w międzyczasie stan moŝe być chwilowo niespójny). Izolacja (ang. isolation) - transakcja nie wie nic o innych transakcjach i nie musi uwzględniać ich działania. Czynności wykonane przez daną transakcję są niewidoczne dla innych transakcji aŝ do jej zakończenia. Trwałość (ang. durability) - po zakończeniu transakcji jej skutki są na trwale zapamiętane (na dysku) i nie mogą być odwrócone przez zdarzenia losowe (np. wyłączenie prądu).
160 Bazy danych Transakcje w SQL W języku SQL kaŝda transakcja rozpoczyna się słowem BEGIN TRANSACTION, a kończy operacją COMMIT oznaczającą pomyślne zakończenie transakcji lub operacją ROLLBACK (lub ABORT) oznaczające odrzucenie (wycofanie) transakcji. Dowolne zdanie select, insert, update, delete, create rozpoczyna transakcję, o ile nie była ona juŝ przez tę transakcję rozpoczęta. Transakcja trwa aŝ do wydania komendy COMMIT (potwierdzającej) lub ROLLBACK (zrywającej, cofającej). Transakcja moŝe objąć dowolną liczbę zdań select, insert, update, delete, create i innych. Przykład transakcji z zastosowaniem komend ABORT i COMMIT przedstawia rysunek 7.3. Rys. 7.3 Przykład transakcji
Bazy danych 161 Stosowanie zamków oraz problemy z zakleszczaniem Zarządzanie transakcjami wymaga zastosowania specjalnego modułu (zwanego modułem planisty) oraz protokołu zarządzania transakcjami. W celu uniknięcia problemów ze współbieŝnym dostępem stosuje się mechanizmy blokady dostępu do danych (zamki). MoŜemy wyróŝnić dwa typy takich zamków: zamek typu X - załoŝenie zamka tego typu całkowicie blokuje dostęp do obiektu dla innych transakcji, zamek typu S - załoŝenie zamka tego typu powoduje, Ŝe inne transakcje mogą czytać dane, ale nie mogą ich modyfikować. Najczęściej stosowanym w bazach relacyjnych protokołem zarządzania transakcjami jest protokół blokowania dwufazowego 2PL (ang. two-phase locking). Reguły pracy protokołu 2PL są następujące: 1. Jeśli dana operacja p i (x) moŝe być wykonana, to planista zakłada blokadę na daną x dla transakcji T i i operację przekazuje do wykonania. Jeśli natomiast operacja ta nie moŝe być wykonana, to umieszcza ją w kolejce. 2. Zdjęcie załoŝonej blokady moŝe nastąpić dopiero wtedy, gdy operacja zostanie wykonana. 3. Jeśli nastąpiło zdjęcie jakiejkolwiek blokady załoŝonej dla transakcji T, to dla tej transakcji nie moŝna załoŝyć Ŝadnej innej blokady. Postępując zgodnie z tymi zasadami przebieg wykonania transakcji wymusza dwie fazy obsługi transakcji. W pierwszej fazie są zakładane blokady, a w drugiej następuje ich zdejmowanie. Faza druga jest znacznie szybsza od pierwszej. Rys. 7.4 Protokół 2PL Stosowanie zamków moŝe prowadzić do zjawiska zwanego zakleszczaniem. Polega ono na tym, Ŝe w wyniku załoŝenia zamków przez transakcje, czekają one na wykonanie aŝ do momentu zwolnienia zasobu, do którego dostęp potrzebują.
162 Bazy danych Weźmy pod uwagę dwie transakcje A i B. Transakcja A blokuje zasób X i Ŝąda dostępu do zasobu Y. Transakcja B blokuje zasób Y i Ŝąda dostępu do zasobu X. W wyniku tego dochodzi do zakleszczenia i Ŝadna z transakcji nie moŝe wykonywać swojej akcji. Inne przykłady zakleszczeń są pokazane na rysunkach 7.5 i 7.6. Rys. 7.5 Zakleszczenie trzech transakcji (pętla zakleszczenia) Rys. 7.6 Zakleszczenie dwóch transakcji Zakleszczenia są powaŝnym problemem i mają istotny wpływ na wydajność systemu. Walka z zakleszczeniami moŝe przebiegać według dwu metod. Metoda 1 Wykrywanie zakleszczeń i rozrywanie pętli zakleszczenia. Detekcja zakleszczenia wymaga skonstruowania grafu czekania (ang. wait-for graph) i tranzytywnego domknięcia tego grafu (złoŝoność gorsza niŝ n * n). Rozrywanie pętli zakleszczenia polega na wybraniu transakcji "ofiary" uczestniczącej w zakleszczeniu i następnie, jej zerwaniu i uruchomieniu od
Bazy danych 163 nowa. Wybór "ofiary" podlega róŝnym kryteriom - np. najmłodsza, najmniej pracochłonna, o niskim priorytecie, itd. Metoda 2 Niedopuszczanie do zakleszczeń. Istnieje wiele tego rodzaju metod, np. a) Wstępne Ŝądanie zasobów: przed uruchomieniem kaŝda transakcja określa potrzebne jej zasoby. Nie moŝe później nic więcej Ŝądać. Wada: zgrubne oszacowanie Ŝądanych zasobów prowadzi do zmniejszenia stopnia współbieŝności. b) Czekasz-umieraj (ang. wait-die): jeŝeli transakcja próbuje dostać się do zasobu, który jest zablokowany, to natychmiast jest zrywana i powtarzana od nowa. Metoda moŝe być nieskuteczna dla systemów interakcyjnych (uŝytkownik moŝe się denerwować koniecznością dwukrotnego wprowadzania tych samych danych) oraz prowadzi do spadku efektywności (sporo pracy idzie na marne).
164 Bazy danych Stemple czasowe oraz ziarnistość transakcji KaŜda transakcja w momencie startu dostaje unikalny stempel czasowy, na tyle precyzyjny, aby móc po stemplach rozróŝniać transakcje. śadna zmiana nie jest nanoszona do bazy danych, transakcja działa na swoich własnych kopiach, aŝ do potwierdzenia. KaŜdy obiekt bazy danych przechowuje 2 stemple czasowe: transakcji, która ostatnio brała obiekt do czytania i transakcja, która ostatnio brała obiekt do modyfikacji. W momencie potwierdzenia sprawdza się stemple transakcji oraz wszystkich pobranych przez nią obiektów. MoŜna dość łatwo wyprowadzić reguły zgodności, np. jeŝeli obiekt był aktualizowany i stempel na obiekcie do aktualizacji jest taki sam jak stempel transakcji, to OK, a inaczej zerwij i uruchom od nowa. JeŜeli obiekt był tylko czytany i stempel na obiekcie do aktualizacji jest starszy niŝ stempel transakcji, to OK; inaczej zerwij i uruchom od nowa. Z problemem zakładania zamków wiąŝe się równieŝ problem ziarnistości. Ziarnistość oznacza decyzję, co będzie niepodzielną jednostką na którą zakłada się blokady. Poziomy ziarnistości mogą dotyczyć: bazy danych, relacji, rekordu, elementu rekordu, pojedynczego atrybutu, fizycznej strony pamięci. Grube ziarna mogą zapewnić znaczny poziom bezpieczeństwa, jednak dają niewielki stopień współbieŝności procesów. Natomiast małe ziarna wiąŝą się z duŝymi nakładami na zakładanie zamków oraz ich obsługę. Postulat moŝliwości odtworzenia stanu systemu sprzed wywołani transakcji w wypadku jej awarii (wycofania) moŝliwy jest dzięki m.in. zastosowaniu osobnego dziennika transakcji. Mogą być w nim zapisywane wszystkie dane, na których pracuje transakcja lub teŝ tylko dane róŝnicowe. NaleŜy jednak pamiętać, Ŝe obsługa transakcji wiąŝe się z dodatkowymi nakładami i obciąŝeniem dla systemu.
Bazy danych 165 NajwaŜniejsze mechanizmy odtwarzania systemu po awarii zebrano w tabeli na rysunku 7.7. Rys. 7.7 Mechanizmy odtwarzania systemu po awarii
166 Bazy danych Podsumowanie Transakcje czym sa i po co sie je stosuje Postulaty ACID Transakcje w SQL Stosowanie zamków oraz problemy z zakleszczania Stemple czasowe i ziarnistosc transacji Mechanizm transakcji zapewnia bazie danych zachowanie spójności i umoŝliwia pracę równoległą dla wielu procesów. Jest to jednak mechanizm skomplikowany i absorbujący znaczne zasoby systemu. KaŜda transakcja moŝe zakończyć się zatwierdzeniem lub jej wycofaniem (w wypadku błędów lub awarii). Transakcje powinny spełniać postulat ACID, a protokół ich obsługi powinien być zgodny z protokołem 2PL.
Bazy danych 167 Laboratorium Głównym celem stosowania transakcji jest wykonywanie zestawu modyfikacji danych (zmian w rekordach, wstawień nowych rekordów lub usunięcia rekordów istniejących) w sposób atomowy - czyli kilka operacji jest wykonywanych jako całość lub Ŝadna z operacji nie zapisuje swoich wyników (jeśli w transakcji wystąpi błąd). W tym ćwiczeniu wykonasz transakcję, która nie powiedzie się na skutek błędu.
168 Bazy danych Krok 1 - Prezentacja danych z tabeli Zaloguj się do maszyny wirtualnej ZBD jako uŝytkownik Administrator z hasłem P@ssw0rd. Kliknij Start. Z grupy programów Microsoft SQL Server 2005 uruchom SQL Server Management Studio. W oknie logowania kliknij Connect. Kliknij w menu głównym programu Management Studio na File. Kliknij Open - File. Odszukaj plik C:\Labs\Lab07\Transaction.sql i kliknij Open. Zaznacz kod, który wyświetla fragment tabeli HumanResources.Department (patrz kod poniŝej). USE AdventureWorks GO SELECT * FROM HumanResources.Department WHERE DepartmentID IN (1,2) Wciśnij F5, aby uruchomić zaznaczony fragment kodu. PowyŜsza składnia zwraca pierwsze dwa rekordy z tabeli HumanResources.Department, które w następnym kroku będzie próbowała modyfikować transakcja. Wynik działania powyŝszej składni: DepartmentID Name GroupName ModifiedDate ------------ ----------- ------------------------ ----------------------- 1 Engineering Research and Development 1998-06-01 00:00:00.000 2 Tool Design Research and Development 1998-06-01 00:00:00.000 Krok 2 - Uruchomienie transakcji Zaznacz kod, który ilustruje próbę wykonania transakcji (patrz kod poniŝej). BEGIN TRANSACTION BEGIN TRY UPDATE HumanResources.Department SET Name = 'Engineering' WHERE DepartmentID = 2 UPDATE HumanResources.Department SET Name = 'Eng.' WHERE DepartmentID = 1 END TRY BEGIN CATCH SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_SEVERITY() AS ErrorSeverity, ERROR_STATE() as ErrorState, ERROR_PROCEDURE() as ErrorProcedure,
Bazy danych 169 ERROR_LINE() as ErrorLine, ERROR_MESSAGE() as ErrorMessage IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION END CATCH IF @@TRANCOUNT > 0 COMMIT TRANSACTION GO Wciśnij F5, aby uruchomić zaznaczony fragment kodu. PowyŜszy kod podejmuje próbę wykonania transakcji złoŝonej z dwóch operacji UPDATE. Próba wykonania pierwszej z nich spowoduje błąd, poniewaŝ wartości w kolumnie Name w tabeli HumanResources.Department muszą być unikalne, a składnia próbuje wstawić duplikat wartości 'Enineering', która juŝ istnieje w rekordzie pierwszym (DepartmentID = 1) tabeli. Przechwytywanie błędów odbywa się przy uŝyciu składni TRY...CATCH, którą poznałeś w poprzednim ćwiczeniu. Wynik działania powyŝszej składni (skróciliśmy komunikat błędu): ErrorNumber ErrorSeverity ErrorState ErrorProcedure ErrorLine ErrorMessage ----------- ------------- ----------- -------------- ----------- ----------------------------------- 2601 14 1 NULL 8 Cannot insert duplicate key row... Krok 3 - Weryfikacja wyników Zaznacz ponownie kod, który uruchamiałeś w kroku 1 ćwiczenia. Wciśnij F5, aby uruchomić zaznaczony fragment kodu. Wynik będzie identyczny, jak w kroku 1, a to znaczy, Ŝe transakcja została poprawnie wycofana. Istnieje takŝe inna metoda obsługi transakcji. Metoda ta bazuje na składniach XACT_ABORT i XACT_STATE, o których moŝesz poczytać w Books Online. Stosowanie transakcji, o ile sama składnia nie jest skomplikowana, nie jest bezproblemowe. Problemy związane są z jednoczesnym dostępem do zasobów wielu transakcji. Aby uniknąć ewentualnych problemów w pracy z transakcjami, poczytaj w Books Online o poziomach izolacji transakcji (w indeksie szukaj pod hasłem: isolation levels [SQL Server]).