· L- acid disodium salt 2760-2014 2.1 C4H4Na20ÿH20 2.2 CH2—COONa 2.3 196.06 2013 3.1 3.2 13
ACID - Transakcje
-
Upload
michal-lomnicki -
Category
Technology
-
view
2.470 -
download
0
description
Transcript of ACID - Transakcje
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?