Transakcje w bazach danych

- poziomy izolacji, historie transakcji i sposoby ich odtwarzania

Autorzy:

Przemysław Nadolski

Michał Łomnicki

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.

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

Definicja transakcji

Sekwencja logicznie powiązanych operacjina 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.

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ść.

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

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 readT1 odczytuje zadane wartości, T2 dodaje nową krotkę, T1 ponownie odczytuje wartości

Poziomy izolacji transakcji - SQL

• Standard SQL (SQL-92) definiuje cztery poziomy izolacji transakcji:

– READ COMMITTED

– READ UNCOMMITTED

– REPEATABLE READ

– SERIALIZABLE

Poziomy izolacji transakcji – SQL c.d.

• READ UNCOMNITTEDZezwala na czytanie niepotwierdzonych (uncomitted) danych.

• READ COMNITTEDPoziom 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.

• SERIALIZABLENajwyŜ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 READBlokady 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.

Poziomy izolacji transakcji

Dirty read Fuzzy read Phantomread

READ UNCOMITTED

MoŜliwy MoŜliwy MoŜliwy

READ COMMITED

Nie występuje

MoŜliwy MoŜliwy

REPEATABLE READ

Nie występuje

Nie występuje

MoŜliwy

SERIALIZABLE Nie występuje

Nie występuje

Nie występuje

Poziomy izolacji transakcji

PostgreSQL

MySQL

OracleMicrosoft SQL

SQL Server

READ UNCOMITTED

TAK TAK TAK

READ COMMITEDNie

występujeNie

występujeTAK

REPEATABLE READNie

występujeNie

występujeTAK

SERIALIZABLE TAK TAK TAK

Transakcje w SQL

BEGIN TRANSACTION

Operacja 1

Operacja 2

.

.

Operacja N

COMMIT

Zmiany zostają zatwierdzone

BEGIN TRANSACTION

Operacja 1

Operacja 2

.

.

Operacja N

ROLLBACK

Zmiany zostają wycofane

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

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

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

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_TIMEOUTOkreślenie liczby milisekund, jaką wyraŜenie będzie oczekiwać na zwolnienie blokady.

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

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.

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

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-phasecommit ).

Jak wspomniano, protokół 2PC moŜe być implementowany w jednym z trzech wariantów:

- scentralizowanego 2PC,

- zdecentralizowanego 2PC,

- liniowego 2PC.

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.

Współbie żne wykonywanie transakcji

• Algorytmy blokowaniaUszeregowanie transakcji wynika z kolejności uzyskiwanych blokad.Algorytm blokowania dwufazowego – 2PL

• Algorytmy znaczników czasowychUszeregowanie transakcji wynika z wartości znaczników czasowych związanych z transakcjami.

• Algorytmy optymistyczneWalidacja poprawności uszeregowania

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 odczytuoraz zapisu danej

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

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

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

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

Budowa dziennika transakcji

Na podstawie Microsoft SQL Server

• Log sequence number

• Operacja

• Transaction ID

• Informacja o modyfikacji (w postaci róŜnicy bitowej)

Przykład odtwarzania

CREATE DATABASE ehealt

CREATE TABLE doctors (…..)

INSERT INTO doctors (….)

….

ALTER DATABASE SET RECOVERY FULL

BACKUP DATABASE ehealth TO DISK = ‘Z:\Backups\ehealth.bak’

DELETE FROM Doctors -- !!!

BACKUP LOG ehealth TO DISK = ‘Z:\Backup\ehealthlog.bak’

RESTORE DATABASE ehealth FROM DISK = ‘Z:\Backup\ehealth.bak’ WITH NORECOVERY

RESTORE LOG ehealth FROM DISK = ‘Z:\Backup\ehealthlog.bak’

WITH STOPAT = ’13-11-2008 8:30’, NORECOVERY

RESTORE DATABASE ehealth WITH RECOVERY

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 wszystkietransakcje 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.

Transakcje w bazach danych

Dziękujemy.

Pytania?