Transakcje bazodanowe, SQL i architektury

Transakcje bazodanowe są kluczowym elementem zapewniającym integralność i niezawodność danych w nowoczesnych systemach baz danych. Ten artykuł przedstawia kompleksową analizę transakcji bazodanowych, SQL i architektur, które są niezbędne do zarządzania i odzyskiwania danych, zwłaszcza w środowiskach rozproszonych. Omówimy podstawowe właściwości, sterowanie współbieżnością, rozwiązywanie problemów oraz praktyczne zastosowanie w SQL.

Czym są transakcje bazodanowe? Podstawowe informacje dla studentów

Transakcja w bazie danych to logicznie spójna sekwencja operacji, która przenosi bazę danych z jednego spójnego stanu do drugiego. Jest to podstawowa jednostka odzyskiwania po awariach i przetwarzania współbieżnego. Jeśli wszystkie operacje w transakcji zakończą się pomyślnie, zmiany zostaną trwale zapisane. W przeciwnym razie wszystkie wykonane zmiany zostaną wycofane, a baza danych pozostanie w pierwotnym stanie.

Kluczowe właściwości transakcji (ACID)

Dla zapewnienia niezawodności i integralności danych, transakcje kierują się czterema podstawowymi właściwościami, często określanymi akronimem ACID:

• Atomowość (Atomicity): Cała sekwencja operacji jest traktowana jako jedna logiczna jednostka. Albo cała transakcja zostanie wykonana, albo żadna jej część. W przypadku błędu wszystkie zmiany zostaną wycofane (ROLLBACK).
• Izolacja (Isolation): Zmiany wprowadzone przez transakcję nie mogą być widoczne dla innych transakcji, dopóki transakcja globalna nie zostanie pomyślnie zakończona (zatwierdzona). Izolacja zapobiega rozprzestrzenianiu się błędów z jednej transakcji na inne, a także wzajemnemu wpływowi współbieżnie działających transakcji. Efekt indukowanego wycofania jest określany jako kaskadowe wycofanie (cascading rollback) lub efekt domina.
• Trwałość (Durability): Gdy transakcja zostanie pomyślnie zatwierdzona (COMMIT), wprowadzone zmiany są trwale zapisywane w bazie danych i nie mogą zostać utracone nawet w przypadku awarii systemu.
• Szeregowalność (Serializability): Wynik współbieżnego przetwarzania transakcji musi być identyczny z wynikiem, jaki uzyskano by, gdyby transakcje były wykonywane szeregowo (jedna po drugiej) w pewnej kolejności. Jest to szczególnie ważne w rozproszonych bazach danych.

Architektury systemów baz danych i typy transakcji

W zależności od zakresu i lokalizacji danych, wyróżniamy różne typy transakcji i architektur.

Rozproszone systemy baz danych i transakcje globalne

Rozproszony system baz danych składa się z zestawu węzłów połączonych siecią, gdzie globalna baza danych jest podzielona na części składowe alokowane na różnych węzłach. Transakcja globalna jest inicjowana na jednym węźle i w razie potrzeby rozprzestrzenia się na inne węzły. Rozpada się na transakcje cząstkowe (lokalne), które wykonują cząstkowe zadania na odpowiednich węzłach. Te transakcje cząstkowe są zarządzane przez transakcję główną.

Moduły do zarządzania transakcjami w systemach rozproszonych

Każdy węzeł systemu rozproszonego zawiera kluczowe moduły:

• Moduł zarządzania transakcjami: Przetwarza żądania użytkownika, dzieli transakcje zgodnie z dystrybucją danych, agreguje wyniki z transakcji cząstkowych i przekazuje je użytkownikowi.
• Moduł zarządzania danymi: Odpowiada za odczyt i zapis wartości w lokalnej bazie danych oraz komunikację z modułem zarządzania transakcjami.

Transakcje lokalne vs. globalne

• Transakcja lokalna: Wymaga dostępu do danych tylko na jednym węźle i nie wymaga współpracy z innymi węzłami.
• Transakcja globalna: Przekracza zakres jednego węzła i wymaga koordynacji między wieloma węzłami, gdzie dzieli się na transakcje cząstkowe.

Dwufazowy protokół zatwierdzania (2PC): Zarządzanie transakcjami rozproszonymi

Dwufazowy protokół zatwierdzania (Two-Phase Commit Protocol) jest podstawowym mechanizmem zapewniającym atomowość transakcji globalnych w rozproszonych bazach danych. Celem jest, aby wszystkie transakcje cząstkowe zostały albo zatwierdzone, albo anulowane.

Faza 1: Faza głosowania (Vote Phase)

1. Transakcja główna (koordynator) wysyła zapytanie do wszystkich transakcji cząstkowych, czy są gotowe do zatwierdzenia.
2. Każda transakcja cząstkowa wykonuje wszystkie swoje operacje i tymczasowo zapisuje zmiany. Jeśli zakończy się pomyślnie, wysyła do koordynatora wiadomość RC (Ready to Commit). Wprowadzone zmiany nie są jeszcze udostępniane innym transakcjom.
3. Jeśli któraś transakcja cząstkowa zakończy się niepowodzeniem lub nie może osiągnąć punktu RC w danym przedziale czasowym (time out), wysyła wiadomość ABORT.

Faza 2: Faza zatwierdzania (Commit Phase)

1. Koordynator transakcji głównej zbiera wszystkie komunikaty RC od transakcji cząstkowych.
2. Jeśli WSZYSTKIE transakcje cząstkowe zgłosiły RC: Koordynator wydaje wszystkim transakcjom cząstkowym pozwolenie na GLOBALNE ZATWIERDZENIE. SZBD zajmuje się faktycznym zapisaniem zmian. Po tym kroku transakcje mogą udostępnić zmiany innym transakcjom.
3. Jeśli CO NAJMNIEJ JEDNA transakcja cząstkowa zgłosiła ABORT lub nastąpił time out: Koordynator wysyła ABORT do wszystkich transakcji cząstkowych. Cała transakcja globalna zostanie wycofana.

Rozwiązywanie problemów z awariami węzłów w 2PC

Awarie węzłów mogą wystąpić w różnych fazach protokołu. Oto kluczowe sytuacje i ich rozwiązania:

• Nie można zainicjować podtransakcji: Transakcja główna próbuje zainicjować podtransakcję na innym węźle. Jeśli to niemożliwe lub pierwotny węzeł zgłosi RC (czego nie powinien), transakcja główna wysyła ABORT do wszystkich zaangażowanych węzłów.
• Transakcja główna nie otrzymuje wiadomości RC: Transakcja główna nie wie, czy podtransakcja zakończyła się niepowodzeniem przed punktem RC, czy po nim. Wysyła wiadomość ABORT do wszystkich zaangażowanych podtransakcji.
• Węzeł lokalny nie jest w stanie poinformować o punkcie RC: Podobne rozwiązanie jak powyżej, transakcja główna wysyła ABORT.
• Transakcja główna otrzymała RC/ABORT, ale nie może wysłać wiadomości globalnej: Transakcja główna musi pozostać aktywna, dopóki nie dostarczy wiadomości. Jeśli wszystkie podtransakcje zgłosiły RC, oczekuje się na wznowienie transakcji głównej. Jeśli co najmniej jedna zgłosiła ABORT, pozostałe mogą wykonać lokalny abort.

Synchronizacja i sterowanie współbieżnością transakcji

Synchronizacja jest niezbędna do prawidłowego zarządzania współbieżnie działającymi transakcjami. Zapewnia, że operacje są wykonywane w takiej kolejności, aby wynik był zgodny z harmonogramem szeregowym.

Dwufazowy protokół blokowania (2PL)

Podstawą synchronizacji są protokoły blokowania. Dwufazowy protokół blokowania zapewnia, że każdy obiekt, do którego uzyskuje się dostęp, musi być najpierw zablokowany. Moduł blokowania sprawdza tabelę blokad pod kątem potencjalnych konfliktów. Blokady obowiązują do globalnego COMMIT lub ABORT.

• Centralne blokowanie: Jeden węzeł utrzymuje centralną tabelę blokad dla wszystkich zaangażowanych węzłów. Umożliwia to centralne wykrywanie zakleszczeń.
• Zdecentralizowane blokowanie: Każdy węzeł prowadzi własną tabelę blokad. Jest to mniej wymagające pod względem komunikacji, ale utrudnia wykrywanie globalnych zakleszczeń.

Zakleszczenie (Deadlock) i jego rozwiązywanie

Zakleszczenie występuje, gdy dwie lub więcej transakcji wzajemnie czekają na zwolnienie zasobów, które posiadają inne transakcje, i żadna z nich nie może kontynuować. Przykładem jest sytuacja, w której transakcja T1 posiada blokadę A i czeka na B, podczas gdy T2 posiada B i czeka na A.

Wykrywanie zakleszczeń

Zakleszczenia są wykrywane na podstawie grafów oczekiwania (wait-for graphs). Transakcje są węzłami grafu, a relacje „oczekiwania na” są krawędziami skierowanymi. Znalezienie cykli w grafie wskazuje na zakleszczenie.

• Impulsy do badania: Przekroczenie czasu oczekiwania, odrzucenie żądania blokady, okresowe badanie.

Unikanie zakleszczeń za pomocą znaczników czasu

Metody znaczników czasu zapobiegają zakleszczeniom poprzez przypisywanie znaczników czasu (TS) transakcjom. Wszystkie transakcje cząstkowe jednej transakcji globalnej posiadają znacznik czasu swojej transakcji głównej. Jeśli transakcja R żąda blokady na obiekcie posiadanym przez transakcję O, porównuje się ich znaczniki czasu:

• Metoda „Wait-Die”: if TS(R) < TS(O) then wait else die (Młodsza transakcja umiera i zostaje wycofana, jeśli próbuje zablokować obiekt starszej transakcji.)
• Metoda „Wound-Wait”: if TS(R) < TS(O) then wound else wait (Starsza transakcja „rani” młodszą transakcję, jeśli posiada żądaną blokadę, a młodsza transakcja zostaje wycofana.)

Wait: Oczekiwanie na zakończenie lub przerwanie transakcji O. Die / Wound: Przerwanie transakcji R i jej późniejsze wycofanie.

Transakcje w SQL

W języku SQL transakcja to sekwencja poleceń, która stanowi jednostkę odzyskiwania po awariach i przetwarzania współbieżnego. Pierwsze polecenie w SQL domyślnie rozpoczyna transakcję.

Kluczowe polecenia SQL do zarządzania transakcjami

• COMMIT: Normalne zakończenie transakcji. Wszystkie zmiany są trwale zapisywane w bazie danych. SQL> COMMIT
• ROLLBACK: Wycofanie transakcji. Wszystkie zmiany wprowadzone od początku transakcji (lub od ostatniego punktu zapisu) zostają anulowane, a baza danych wraca do poprzedniego stanu. SQL> ROLLBACK
• SAVEPOINT: Ustawia punkt, do którego transakcję można wycofać za pomocą ROLLBACK TO SAVEPOINT. SAVEPOINT nazwa_punktu; Wycofanie do punktu zapisu nie zwalnia plików LOG. Wycofanie bez określenia punktu zapisu zwalnia pliki LOG.

Odzyskiwanie po awariach: Jak działają dzienniki i algorytmy UNDO/REDO

Odzyskiwanie po awarii to proces przywracania spójnego stanu bazy danych po awarii. Celem jest wycofanie przerwanych transakcji, powtórzenie zatwierdzonych transakcji i automatyczne uruchomienie wycofanych transakcji.

Dzienniki (Log Files)

Dzienniki to kluczowe pliki, które przechowują informacje o przebiegu transakcji i służą do odzyskiwania. Każdy węzeł sieci ma swój dziennik zawierający rekordy opisujące całą historię transakcji (np. T, START; T, nazwa_atrybutu, stara_wartość, nowa_wartość; T, COMMIT).

Stany transakcji

Transakcja może znajdować się w kilku stanach:

• Aktywny (A): Od początku wykonywania transakcji.
• Częściowo zatwierdzony (PC): Po wykonaniu ostatniej operacji transakcji.
• Błędny (F): Nie można kontynuować normalnego przebiegu transakcji.
• Anulowany (AB): Po zakończeniu operacji ROLLBACK.
• Zatwierdzony (C): Po pomyślnym wykonaniu COMMIT.

Punkty kontrolne (Checkpoints)

Punkty kontrolne to punkty tc, w których zawartość buforów jest wysyłana na dysk, a do dziennika zapisywany jest rekord kontrolny. Zawiera on listę wszystkich transakcji, które były aktywne w czasie tc (rozpoczęły się, ale nie zostały zatwierdzone).

Algorytm UNDO / REDO do odzyskiwania

Ten algorytm opiera się na natychmiastowych aktualizacjach bazy danych, gdzie baza danych jest aktualizowana przed osiągnięciem stanu PC. Do odzyskiwania wykorzystuje się dziennik, w którym każda zmiana musi być zarejestrowana przed aktualizacją bazy danych.

Procedura algorytmu:

1. Tworzone są dwie listy: UNDO i REDO. UNDO zawiera transakcje z punktu kontrolnego, REDO jest pusta.
2. Dziennik jest przeszukiwany od tc do przodu.
3. Po znalezieniu START T transakcja T jest dodawana do listy UNDO.
4. Po znalezieniu COMMIT T T jest przenoszona z listy UNDO do REDO.
5. Na końcu dziennika listy UNDO (transakcje niezatwierdzone) i REDO (transakcje zatwierdzone, które należy powtórzyć) są kompletne.

Odzyskiwanie:

• Lista UNDO: Przetwarzanie wstecz w dzienniku (wycofanie niezatwierdzonych zmian).
• Lista REDO: Przetwarzanie w przód (powtórzenie zatwierdzonych zmian).

Strategia odroczonej realizacji zmian (algorytm REDO)

Alternatywą jest strategia odroczonej realizacji zmian, w której zawartość buforów jest zapisywana na dysku dopiero po globalnym zatwierdzeniu transakcji. Jeśli transakcja nie osiągnie globalnego zatwierdzenia, zmiany na dysku nie zostaną zrealizowane. Do dziennika zapisywane są tylko nowe wartości atrybutów dla przetwarzania w przód. To podejście wykorzystuje tzw. algorytm REDO.

Często zadawane pytania (FAQ) dotyczące transakcji bazodanowych

Jaka jest różnica między COMMIT a ROLLBACK w SQL?

COMMIT trwale zapisuje wszystkie zmiany wprowadzone przez transakcję do bazy danych i ją kończy. Baza danych przechodzi w ten sposób do nowego spójnego stanu. Natomiast ROLLBACK anuluje wszystkie zmiany wprowadzone przez transakcję od jej początku (lub ostatniego SAVEPOINTu) i przywraca bazę danych do pierwotnego stanu sprzed transakcji. Żadne zmiany nie zostają w ten sposób zapisane.

Dlaczego właściwości ACID transakcji są ważne?

Właściwości ACID (Atomowość, Izolacja, Trwałość, Szeregowalność) są kluczowe dla zapewnienia niezawodności, integralności i spójności danych w systemach baz danych. Bez nich baza danych byłaby podatna na błędy, utratę danych, niespójne stany i problemy podczas przetwarzania współbieżnego, co prowadziłoby do niewiarygodnych informacji i nieprawidłowego działania aplikacji.

Czym jest zakleszczenie i jak baza danych się przed nim broni?

Zakleszczenie (deadlock) występuje, gdy dwie lub więcej transakcji wzajemnie czekają na zwolnienie zasobów, które posiadają inne transakcje, i żadna z nich nie może kontynuować. Baza danych broni się przed zakleszczeniami za pomocą mechanizmów wykrywania (np. grafy oczekiwania do wykrywania cykli) oraz metod prewencyjnych. Metody prewencyjne często obejmują znaczniki czasu (np. algorytmy „Wait-Die” lub „Wound-Wait”), które określają, która transakcja ma czekać, a która ma zostać zakończona, aby zapobiec zakleszczeniu.