[PL] Transakcje w bazach danych

Transcript

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 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
11. Poziomy izolacji transakcji PostgreSQL MySQL Oracle Microsoft SQL SQL Server READ UNCOMITTED TAK TAK TAK READ COMMITED Nie występuje Nie występuje TAK REPEATABLE READ Nie występuje Nie występuje TAK SERIALIZABLE TAK TAK TAK
12. 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
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:\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
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?