DDBMS - systemy przetwarzania transakcji
W tym rozdziale omówiono różne aspekty przetwarzania transakcji. Przeanalizujemy również zadania niskiego poziomu zawarte w transakcji, stany transakcji i właściwości transakcji. W ostatniej części przyjrzymy się harmonogramom i możliwości serializacji harmonogramów.
Transakcje
Transakcja to program zawierający zbiór operacji na bazie danych, wykonywanych jako logiczna jednostka przetwarzania danych. Operacje wykonywane w ramach transakcji obejmują jedną lub więcej operacji bazy danych, takich jak wstawianie, usuwanie, aktualizowanie lub pobieranie danych. Jest to atomowy proces, który albo jest całkowicie kompletny, albo nie jest wykonywany wcale. Transakcja obejmująca tylko pobranie danych bez aktualizacji danych nazywana jest transakcją tylko do odczytu.
Każdą operację wysokiego poziomu można podzielić na szereg zadań lub operacji niskiego poziomu. Na przykład operację aktualizacji danych można podzielić na trzy zadania -
read_item() - odczytuje dane z pamięci do pamięci głównej.
modify_item() - zmień wartość pozycji w pamięci głównej.
write_item() - zapisz zmodyfikowaną wartość z pamięci głównej do pamięci.
Dostęp do bazy danych jest ograniczony do operacji read_item () i write_item (). Podobnie, dla wszystkich transakcji, podstawowe operacje na bazie danych w formularzach do odczytu i zapisu.
Operacje transakcyjne
Operacje niskiego poziomu wykonywane w transakcji to -
begin_transaction - Znacznik określający początek realizacji transakcji.
read_item or write_item - Operacje na bazie danych, które mogą być przeplatane z operacjami pamięci głównej jako część transakcji.
end_transaction - Znacznik określający koniec transakcji.
commit - Sygnał wskazujący, że transakcja została pomyślnie zakończona w całości i nie zostanie cofnięta.
rollback- Sygnał wskazujący, że transakcja się nie powiodła, a zatem wszystkie tymczasowe zmiany w bazie danych są cofane. Zatwierdzonej transakcji nie można wycofać.
Stany transakcji
Transakcja może przejść przez podzbiór pięciu stanów, aktywnych, częściowo zatwierdzonych, zatwierdzonych, zakończonych niepowodzeniem i przerwanych.
Active- Stan początkowy, w który wchodzi transakcja, to stan aktywny. Transakcja pozostaje w tym stanie podczas wykonywania operacji odczytu, zapisu lub innych operacji.
Partially Committed - Transakcja wchodzi w ten stan po wykonaniu ostatniego zestawienia transakcji.
Committed - Transakcja przechodzi w ten stan po pomyślnym zakończeniu transakcji, a kontrole systemu wydały sygnał zatwierdzenia.
Failed - Transakcja przechodzi ze stanu częściowo zatwierdzonego lub stanu aktywnego do stanu niepowodzenia, gdy okaże się, że normalne wykonanie nie może już być kontynuowane lub testy systemu kończą się niepowodzeniem.
Aborted - jest to stan po wycofaniu transakcji po niepowodzeniu i przywróceniu bazy danych do stanu sprzed rozpoczęcia transakcji.
Poniższy diagram przejścia stanów przedstawia stany transakcji i operacje transakcyjne niskiego poziomu, które powodują zmianę stanów.
Pożądane właściwości transakcji
Każda transakcja musi zachować właściwości ACID, a mianowicie. Atomowość, spójność, izolacja i trwałość.
Atomicity- Ta właściwość stwierdza, że transakcja jest niepodzielną jednostką przetwarzania, to znaczy albo jest wykonywana w całości, albo w ogóle nie jest wykonywana. Nie powinna istnieć żadna częściowa aktualizacja.
Consistency- Transakcja powinna przenieść bazę danych z jednego spójnego stanu do innego spójnego stanu. Nie powinno to niekorzystnie wpływać na żadną pozycję danych w bazie danych.
Isolation- Transakcja powinna być wykonana tak, jakby była jedyną w systemie. Nie powinno być żadnych zakłóceń ze strony innych współbieżnych transakcji, które są jednocześnie uruchomione.
Durability - Jeżeli zatwierdzona transakcja powoduje zmianę, zmiana ta powinna być trwała w bazie danych i nie zostać utracona w przypadku jakiejkolwiek awarii.
Harmonogramy i konflikty
W systemie z wieloma jednoczesnymi transakcjami a scheduleto całkowita kolejność wykonywania operacji. Biorąc pod uwagę harmonogram S zawierający n transakcji, powiedzmy T1, T2, T3 ……… ..Tn; dla każdej transakcji Ti operacje w Ti muszą zostać przeprowadzone zgodnie z harmonogramem S.
Rodzaje harmonogramów
Istnieją dwa rodzaje harmonogramów -
Serial Schedules- W harmonogramie seryjnym w dowolnym momencie aktywna jest tylko jedna transakcja, tj. Nie ma nakładania się transakcji. Przedstawia to poniższy wykres -
Parallel Schedules- W harmonogramach równoległych jednocześnie aktywnych jest więcej niż jedna transakcja, tj. Transakcje zawierają operacje, które nakładają się w czasie. Przedstawia to poniższy wykres -
Konflikty w zestawieniach
W harmonogramie obejmującym wiele transakcji: a conflictwystępuje, gdy dwie aktywne transakcje wykonują niezgodne operacje. Mówi się, że dwie operacje są ze sobą w konflikcie, gdy wszystkie poniższe trzy warunki występują jednocześnie:
Te dwie operacje są częścią różnych transakcji.
Obie operacje mają dostęp do tego samego elementu danych.
Co najmniej jedna z operacji jest operacją write_item (), tj. Próbuje zmodyfikować element danych.
Możliwość serializacji
ZA serializable schedulez transakcji „n” jest harmonogramem równoległym, który jest odpowiednikiem harmonogramu seryjnego zawierającego te same transakcje „n”. Harmonogram z możliwością serializacji zawiera poprawność harmonogramu szeregowego przy jednoczesnym zapewnieniu lepszego wykorzystania procesora przez harmonogram równoległy.
Równoważność harmonogramów
Równoważność dwóch harmonogramów może być następujących typów -
Result equivalence - Dwa harmonogramy dające identyczne wyniki są uważane za równoważne wynikom.
View equivalence - Dwa harmonogramy, które wykonują podobne czynności w podobny sposób, są uważane za równoważne w widoku.
Conflict equivalence - O dwóch harmonogramach mówi się, że są równoważne w konflikcie, jeśli oba zawierają ten sam zestaw transakcji i mają tę samą kolejność sprzecznych par operacji.