1. Transakcje w bazach danych
- poziomy izolacji, historie transakcji
i sposoby ich odtwarzania
Autorzy:
Przemysław Nadolski
Michał Łomnicki

2. Warunki ACID
• Atomicity – atomowość
• Consistency – spójność
• Isolation – izolacja
• Durability – trwałość
Izolacja + spójność => kontrola współbieŜności
Atomowość + trwałość => odtwarzanie (przywracanie)
Spójność musi być zapewniona przez programistę!
Własności transakcji tworzą czwórkę ACID.

3. Co to jest transakcja ?
• Transakcje to taki zbiór operacji na bazie
danych, które stanowią logiczną całość i
jako takie mogą być wykonane albo
wszystkie, albo nie moŜe być wykonana
Ŝadna z nich.
• Przykład:
- przelewy, operacje dyskowe, systemowe

4. Definicja transakcji
Sekwencja logicznie powiązanych operacji
na bazie danych pozostawiająca ją w
spójnym stanie
Sekwencja operacji SQL, która jest
atomowa i uwzględnia moŜliwość
przywrócenia stanu bazy danych.

5. Czy transakcje są potrzebne?
Transakcje nie są potrzebne, gdy
• Brak współbieŜnych operacji
• MoŜna zapewnić, Ŝe nieatomowe operacje (np. 2xInsert) wykonają się
bezbłędnie
W pozostałych przypadkach, aby utrzymać spójność danych naleŜy uŜywać
transakcji!
Transakcje redukują współbieŜność.

6. Cel zastosowań transakcji
Bezpieczne wykonanie aplikacji na
spójnych danych w obecności:
• Wielu uŜytkowników (synchronizacja)
• Błędów (odtwarzanie po defektach hardware-owych lub
software-owych), wykonywane są albo wszystkie
operacje albo Ŝadna
• Synchronizacja operacji rozproszonych na wiele
systemów

7. Transakcje - konflikty
• Lost update
T2 zapisuje wartość zmienioną przez T1 ignorując dokonane przez nią
modyfikacje
• Dirty read
T2 odczytuje wartość zmienioną przez T1, po czym T1 zostaje anulowana
• Fuzzy read
T1 odczytuje wartość x, T2 zmienia x, T1 ponownie odczytuje x
• Phantom read
T1 odczytuje zadane wartości, T2 dodaje nową krotkę, T1 ponownie
odczytuje wartości

8. Poziomy izolacji transakcji - SQL
• Standard SQL (SQL-92) definiuje cztery
poziomy izolacji transakcji:
– READ COMMITTED
– READ UNCOMMITTED
– REPEATABLE READ
– SERIALIZABLE

9. Poziomy izolacji transakcji – SQL c.d.
• READ UNCOMNITTED
Zezwala na czytanie niepotwierdzonych (uncomitted) danych.
• READ COMNITTED
Poziom domyślny, moŜna czytać tylko potwierdzone dane. Zapytania SELECT na tym
poziomie nigdy nie mają dostępu do danych niezatwierdzonych przez inne transakcje.
KaŜda nowa transakcja która chce zmodyfikować ten sam wiersz oczekuje na
zatwierdzenie lub odrzucenie poprzedniej.
• SERIALIZABLE
NajwyŜszy poziom izolacji. Blokuje dostęp do całej tabeli. Symuluje on szeregowe
wykonywanie transakcji. Zapytanie SELECT na tym poziomie nigdy nie ma dostępu do
danych zatwierdzonych, albo niezatwierdzonych, aplikacja wykonująca zapytanie
musi być na to przygotowana. Nawet jeśli inna transakcja zmieni dane podczas
wykonywania transakcji Serializable, SELECT zawsze zwróci ten sam wynik.
• REPEATABLE READ
Blokady są umieszczane na wszystkich danych uŜywanych w zapytaniu, co
uniemoŜliwia innym uŜytkownikom uaktualnienie tych danych, ale nowe wiersze-
fantomy mogą zostać wstawione do zbioru danych.

10. Poziomy izolacji transakcji
Dirty read Fuzzy read Phantom
read
READ MoŜliwy MoŜliwy MoŜliwy
UNCOMITTED
READ Nie MoŜliwy MoŜliwy
COMMITED występuje
REPEATABLE Nie Nie MoŜliwy
READ występuje występuje
SERIALIZABLE Nie Nie Nie
występuje występuje występuje

11. Poziomy izolacji transakcji
PostgreSQL Oracle
SQL Server
MySQL Microsoft SQL
READ
TAK TAK TAK
UNCOMITTED
Nie Nie
READ COMMITED występuje występuje
TAK
Nie Nie
REPEATABLE READ występuje występuje
TAK
SERIALIZABLE TAK TAK TAK

12. Transakcje w SQL
BEGIN TRANSACTION BEGIN TRANSACTION
Operacja 1 Operacja 1
Operacja 2 Operacja 2
. .
. .
Operacja N Operacja N
COMMIT ROLLBACK
Zmiany zostają zatwierdzone Zmiany zostają wycofane

13. Poziomy izolacji transakcji – SQL c.d.
Przykładowy kod transakcji:
BEGIN TRANSACTION LEVEL poziom_izolacji:
(…operacje)
COMMIT
lub
START TRANSACTION:
START TRANSACTION ISOLATION LEVEL poziom_izolacji:
(…operacje)
COMMIT

14. Blokady w bazach danych
Realizacja transakcji ogranicza współbieŜność i dostęp do
zasobów innym procesom. Rozmiar blokowanego ziarna
wpływa równieŜ na wydajności systemu. Problem
kompromisu bezpieczeństwa i wydajności.
Blokowany zasób (ziarno):
• Atrybut
• Rekord
• Strona dyskowa
• Relacja
• Baza danych

15. Blokady w bazach danych - Oracle
• Oracle korzysta z dwóch ziaren blokowania: blokady dla
rekordu i blokady dla całej relacji.
• Pojedynczy rekord moŜe zostać zablokowany
jednocześnie tylko przez jedną transakcję. Z kolei
relacja moŜe być zablokowana jednocześnie przez wiele
transakcji, mamy wówczas do czynienia ze współdzieloną
blokadą relacji
• Blokady zakładane są tylko przy operacjach INSERT,
UPDATE i DELETE
• Blokady realizowane są automatycznie bez udziału
uŜytkownika

16. Jawne Ŝądanie blokad na poziomie tabeli 1/2
MSSQL i Oracle udostępnia funkcje blokowania tabel:
• LOCK TABLE…IN SHARE MODE (TABLOCK)
Zablokowanie całej tabeli – pozwala innym na czytanie tabeli, ale uniemoŜliwia jej
uaktualnianie. Standardowo blokada jest utrzymywana aŜ do zakończenia wykonywa
nia wyraŜenia.
• LOCK TABLE…IN EXCLUSIVE MODE (TABLOCKX)
Blokada wyłączna – uniemoŜliwia innym odczytanie oraz uaktualnienie danej
tabeli utrzymuje się aŜ do zakończenia wykonywania polecenia lub transakcji.
• LOCK_TIMEOUT
Określenie liczby milisekund, jaką wyraŜenie będzie oczekiwać na zwolnienie blokady.

17. Jawne Ŝądanie blokad na poziomie tabeli 2/2
Polecenie blokady:
• SELECT … FROM … WHERE … FOR UPDATE [OF <lista
atrybotów] [NOWAIT];
- OF <lista_atrybutów> uŜywa się w przypadku, gdy zapytanie
odwołuje się do wielu relacji a zablokowane mają zostać rekordy
tylko wybranych relacji
- NOWAIT w przypadku niemoŜności zablokowania rekordów polecenie
jest przerywane i zwracany zostaje wypisany komunikat o
wystąpieniu błędu

18. Obsługa zakleszczeń
Zakleszczenie występuje wtedy, gdy jeden z procesów zablokuje
zasób potrzebny w drugim procesie, a drugi proces zablokuje zasób,
którego potrzebuje pierwszy proces. SQL Server automatycznie
wykrywa i rozwiązuje pojawiające się zakleszczenia. W przypadku
wykrycia takiej sytuacji, serwer wybiera jeden z procesów do
przerwania (szasuje „koszt” przerwania procesu). Otrzymuje kod błędu 1205.
W takiej sytuacji aplikacja musi ponownie wykonać daną operację.
Zakleszczeń moŜna zwykle uniknąć, stosując kilka prostych technik:
• Korzystać z tabel w takiej samej kolejności we wszystkich częściach
aplikacji.
• UŜywać zgrupowanych indeksów w przypadku kaŜdej tabeli w celu
wymuszenia jawnego uporządkowania wierszy.
• Dbać, aby transakcje były krótkie.

19. Transakcje rozproszone (globalne) 1/3
Mamy do czynienia z kilka bazami danych i relacjami między nimi.
Cecha atomowości w odniesieniu do transakcji rozproszonej oznacza,
Ŝe wszystkie transakcje lokalne, wchodzące w skład transakcji
rozproszonej muszę zostać zatwierdzone. Jeśli jedna transakcja
lokalna nie moŜe być wykonana, wówczas całą transakcję
rozproszoną naleŜy wycofać.
Problemy przy transakcjach rozproszonych:
- Uszkodzenie węzłów
- Problemy transferów i wymiany danych
- Potwierdzenie i anulowanie równolegle wykonywanych operacji
Transakcje takie obsługują w mniejszym lub większym stopniu bazy:
Oracle9i/10g,IBM DB2, MSQL Server 2000, SQL Sever 2005,Adaptive Server Anywhere

20. Transakcje rozproszone (globalne) 2/3
Głównym problemem jest zagwarantowanie atomowości transakcji
rozproszonej a standardowy mechanizm zatwierdzania transakcji nie
gwarantuje jej atomowości. W związku z tym, zatwierdzanie lub
wycofywanie transakcji rozproszonej, gwarantujące atomowość jest
realizowane za pomocą specjalizowanego mechanizmu, tzw.
protokołu zatwierdzania dwu-fazowego — 2PC (ang. two-phase
commit ).
Jak wspomniano, protokół 2PC moŜe być implementowany w jednym z
trzech wariantów:
- scentralizowanego 2PC,
- zdecentralizowanego 2PC,
- liniowego 2PC.

21. Transakcje rozproszone (globalne) 3/3
• Podstawową architekturę zarządzania transakcjami rozproszonymi przedstawiono na
slajdzie. KaŜda z trzech baz danych BD1, BD2, BD3 posiada swój własny moduł
lokalnego menadŜera transakcji (lokalny MT), identycznie jak w standardowej
scentralizowanej bazie danych. Ponadto, do zarządzania transakcjami rozproszonymi
jest niezbędny moduł globalnego menadŜera transakcji (globalny MT). Jego zadaniem
jest koordynowanie wykonania zarówno lokalnych jak i rozproszonych transakcji
zainicjowanych w jego węźle. Poszczególne węzły realizujące transakcję rozproszoną
komunikują się za pośrednictwem modułu komunikacji , istniejącego w kaŜdym
węźle.

22. Współbieżne wykonywanie transakcji
• Algorytmy blokowania
Uszeregowanie transakcji wynika z kolejności uzyskiwanych blokad.
Algorytm blokowania dwufazowego – 2PL
• Algorytmy znaczników czasowych
Uszeregowanie transakcji wynika z wartości znaczników czasowych
związanych z transakcjami.
• Algorytmy optymistyczne
Walidacja poprawności uszeregowania

23. Algorytmy blokowania
Z każdą daną można skojarzyć jedną blokadę.
Dana może znajdować się w jednym z trzech stanów:
• Niezablokowana
• Zablokowana do odczytu
• Zablokowana do zapisu
SZBD musi realizować 3 dodatkowe operacje na bazie danych:
• Blokowanie danej do odczytu
• Blokowanie danej do zapisu
• Odblokowanie danej
Operacje blokowania muszą poprzedzać wykonanie operacji odczytu
oraz zapisu danej

24. Stopień ziarnistości
Poziom danych, na jakim następuje zablokowanie dostępu:
• Baza danych
• Relacja
• Rekord
• Element rekordu
• Atrybut
• Fizyczna strona pamięci
Grube ziarna = duŜy poziom bezpieczeństwa, mała efektywność
Małe ziarna = duŜa efektywność, niski poziom bezpieczeństwa

25. Algorytm blokowania dwufazowego
• Operacja read(X) transakcji T musi być poprzedzona
R_lock(X, T) lub W_lock(X, T)
• Operacja write(X) transakcji T musi być poprzedzona
W_lock(X, T)
• Operacje unlock(X, T) wykonywane są po zakończeniu
wszystkich read i write

26. Algorytm blokowania dwufazowego
Istnieje wiele wariantów algorytmu 2PL, m.in.:
• Algorytm statyczny
Wszystkie blokady muszą być uzyskane przed rozpoczęciem
transakcji
• Algorytm restryktywny
Operacje unlock(X, T) są wykonywane po operacji commit lub
rollback

27. Odtwarzanie bazy danych
Na moduł odtwarzania danych składają się:
• Baza danych
• Bufor danych
• Plik (lub zestaw plików) logu (sekwencyjny, append-only)
• Bufor logu

28. Budowa dziennika transakcji
Na podstawie Microsoft SQL Server
• Log sequence number
• Operacja
• Transaction ID
• Informacja o modyfikacji (w postaci róŜnicy bitowej)

29. Przykład odtwarzania
CREATE DATABASE ehealt
CREATE TABLE doctors (…..)
INSERT INTO doctors (….)
….
ALTER DATABASE SET RECOVERY FULL
BACKUP DATABASE ehealth TO DISK = ‘Z:Backupsehealth.bak’
DELETE FROM Doctors -- !!!
BACKUP LOG ehealth TO DISK = ‘Z:Backupehealthlog.bak’
RESTORE DATABASE ehealth FROM DISK = ‘Z:Backupehealth.bak’ WITH NORECOVERY
RESTORE LOG ehealth FROM DISK = ‘Z:Backupehealthlog.bak’
WITH STOPAT = ’13-11-2008 8:30’, NORECOVERY
RESTORE DATABASE ehealth WITH RECOVERY

30. Odtwarzanie bazy danych
Stany bazy danych moŜe być przywrócony do:
• Określonego czasu
• Zdefiniowanego punktu przywracania
• Danego LSN (identyfikatora operacji)
Jeśli SZBD uruchamia się po awarii sprawdzane jest czy wszystkie
transakcje z logu są wprowadzone do bazy danych. MoŜe się zdarzyć,
Ŝe modyfikacja została dokonana tylko w buforze i nie została
zapisana na fizycznym nośniku. Dzięki Write-Ahead Log moŜemy
wprowadzić taką modyfikację nawet po awarii.

31. Transakcje w bazach danych
Dziękujemy.
Pytania?