DBMS – Transakcja

Transakcję można zdefiniować jako grupę zadań. Pojedyncze zadanie jest minimalną jednostką przetwarzania, która nie może być dalej dzielona.

Przyjmijmy przykład prostej transakcji. Załóżmy, że pracownik banku przelewa 500 Rs z konta A na konto B. Ta bardzo prosta i mała transakcja obejmuje kilka zadań niskiego poziomu.

Konto A

Open_Account(A)Old_Balance = A.balanceNew_Balance = Old_Balance - 500A.balance = New_BalanceClose_Account(A)

Konto B

Open_Account(B)Old_Balance = B.balanceNew_Balance = Old_Balance + 500B.balance = New_BalanceClose_Account(B)

WłaściwościACID

Transakcja jest bardzo małą jednostką programu i może zawierać kilka zadań niskiego poziomu. Transakcja w systemie bazodanowym musi zachować Atomowość, Spójność, Izolację i Trwałość – powszechnie znane jako właściwości ACID – aby zapewnić dokładność, kompletność i integralność danych.

• Atomowość – Ta właściwość mówi, że transakcja musi być traktowana jako jednostka atomowa, to znaczy, że albo wszystkie jej operacje są wykonywane, albo żadna. W bazie danych nie może istnieć stan, w którym transakcja jest pozostawiona częściowo zakończona. Stany powinny być definiowane albo przed wykonaniem transakcji, albo po jej wykonaniu/zerwaniu/porażce.

• Skonsekwencja – Baza danych musi pozostawać w spójnym stanie po każdej transakcji. Żadna transakcja nie powinna mieć negatywnego wpływu na dane rezydujące w bazie. Jeśli baza danych była w spójnym stanie przed wykonaniem transakcji, musi pozostać spójna również po jej wykonaniu.

• Trwałość – Baza danych powinna być na tyle trwała, aby utrzymać wszystkie swoje ostatnie aktualizacje nawet w przypadku awarii lub restartu systemu. Jeśli transakcja zaktualizuje fragment danych w bazie danych i ją zatwierdzi, to baza danych będzie przechowywała zmodyfikowane dane. Jeśli transakcja zostanie wykonana, ale system ulegnie awarii zanim dane zostaną zapisane na dysku, dane te zostaną zaktualizowane po ponownym uruchomieniu systemu.

• Izolacja – W systemie baz danych, w którym więcej niż jedna transakcja jest wykonywana jednocześnie i równolegle, właściwość izolacji mówi, że wszystkie transakcje będą przeprowadzane i wykonywane tak, jakby była to jedyna transakcja w systemie. Żadna transakcja nie będzie miała wpływu na istnienie jakiejkolwiek innej transakcji.

Serializowalność

Gdy wiele transakcji jest wykonywanych przez system operacyjny w środowisku wieloprogramowym, istnieje możliwość, że instrukcje jednej transakcji są przeplatane z jakąś inną transakcją.

• Harmonogram – Chronologiczna sekwencja wykonania transakcji jest nazywana harmonogramem. Harmonogram może zawierać wiele transakcji, z których każda składa się z pewnej liczby instrukcji/zadań.

• Seryjny harmonogram – Jest to harmonogram, w którym transakcje są ustawione w taki sposób, że jedna z nich jest wykonywana jako pierwsza. Gdy pierwsza transakcja zakończy swój cykl, wówczas wykonywana jest następna. Transakcje są uporządkowane jeden po drugim. Ten typ harmonogramu nazywany jest harmonogramem szeregowym, ponieważ transakcje wykonywane są w sposób szeregowy.

W środowisku wielotransakcyjnym harmonogramy szeregowe traktowane są jako wzorzec. Sekwencja wykonania instrukcji w transakcji nie może być zmieniona, ale dwie transakcje mogą mieć swoje instrukcje wykonane w sposób losowy. Takie wykonanie nie wyrządza żadnej szkody, jeśli dwie transakcje są wzajemnie niezależne i pracują na różnych segmentach danych; ale w przypadku, gdy te dwie transakcje pracują na tych samych danych, wtedy wyniki mogą się różnić. Ten ciągle zmieniający się rezultat może doprowadzić bazę danych do niespójnego stanu.

Aby rozwiązać ten problem, pozwalamy na równoległe wykonywanie harmonogramu transakcji, jeśli jego transakcje są albo serializowalne, albo mają jakąś relację równoważności między sobą.

Równoważność harmonogramów

Równoważność harmonogramów może być następującego typu –

Równoważność rezultatów

Jeśli dwa harmonogramy dają ten sam rezultat po wykonaniu, mówi się, że są równoważne rezultatom. Mogą one dawać ten sam wynik dla niektórych wartości i różne wyniki dla innego zestawu wartości. Z tego powodu równoważność ta nie jest ogólnie uważana za znaczącą.

Równoważność widokowa

Dwa harmonogramy będą równoważne widokowo, jeśli transakcje w obu harmonogramach wykonują podobne akcje w podobny sposób.

Na przykład –

• Jeśli T odczytuje dane początkowe w S1, to odczytuje również dane początkowe w S2.

• Jeśli T odczytuje wartość zapisaną przez J w S1, to odczytuje również wartość zapisaną przez J w S2.

• Jeśli T wykonuje końcowy zapis na wartości danych w S1, to wykonuje również końcowy zapis na wartości danych w S2.

Równoważność konfliktów

Dwa harmonogramy będą konfliktowe, jeśli będą miały następujące właściwości –

• Oba należą do oddzielnych transakcji.
• Oba mają dostęp do tego samego elementu danych.
• Przynajmniej jeden z nich jest operacją „zapisu”.

Dwa harmonogramy posiadające wiele transakcji z kolidującymi operacjami są równoważne konfliktowo wtedy i tylko wtedy, gdy –

• Oba harmonogramy zawierają ten sam zestaw transakcji.
• Porządek kolidujących par operacji jest zachowany w obu harmonogramach.

Uwaga – Harmonogramy równoważne pod względem widoku są serializowalne pod względem widoku, a harmonogramy równoważne pod względem konfliktu są serializowalne pod względem konfliktu. Wszystkie harmonogramy serializowalne w konflikcie są również serializowalne w widoku.

Stany transakcji

Transakcja w bazie danych może być w jednym z następujących stanów –

• Aktywny – W tym stanie transakcja jest wykonywana. Jest to stan początkowy każdej transakcji.

• Częściowo zaangażowana – Kiedy transakcja wykonuje swoją ostatnią operację, mówi się, że jest w stanie częściowego zaangażowania.

• Nieudana – Transakcja jest w stanie nieudanej transakcji, jeśli którakolwiek z kontroli wykonywanych przez system odzyskiwania bazy danych nie powiedzie się. Nieudana transakcja nie może być dalej kontynuowana.

• Aborted – Jeśli którakolwiek z kontroli nie powiedzie się i transakcja osiągnęła stan niepowodzenia, wówczas menedżer odzyskiwania wycofuje wszystkie swoje operacje zapisu na bazie danych, aby przywrócić bazę danych do jej pierwotnego stanu, w którym znajdowała się przed wykonaniem transakcji. Transakcje w tym stanie nazywane są przerwanymi. Moduł odzyskiwania bazy danych może wybrać jedną z dwóch operacji po przerwaniu transakcji –

  • Re-start transakcji
  • Kill transakcji

• Zatwierdzona – Jeśli transakcja wykona wszystkie swoje operacje pomyślnie, mówi się, że jest zatwierdzona. Wszystkie jej efekty są teraz trwale utrwalone w systemie bazy danych.