Transakcje - Try a different one.

Bazy danych
Transakcje
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
1
Czyta X
2
3
X=X+1
X=X+1
Zapisuje X
6
Wartość XA
Wartość XB
5
Czyta X
4
5
Proces B
Zapisuje X
5
5
6
5
6
6
6
6
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ść XA
1
Czyta X
5
2
X=X+1
6
Wartość XB
3
Czyta X
6
6
4
X=X+1
6
7
6
7
6
7
5
6
Zapisuje X
Zapisuje X
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.
2.
3.
4.
5.
6.
7.
Klient wczytuje kartę magnetyczną i jest rozpoznawany.
Klient określa sumę wypłaty.
Konto klienta jest sprawdzane.
Konto jest zmniejszane o sumę wypłaty.
Wysyłane jest zlecenie do kasy.
Bankomat odlicza sumę i koryguje stan gotówki w bankomacie.
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 pi(x) moŜe być wykonana, to planista zakłada
blokadę na daną x dla transakcji Ti 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]).