Dlaczego niezatwierdzone transakcje muszą być cofane w kolejności wstecznej?

Mam dziennik bazy danych, w którym niektóre transakcje wygrywają (są zatwierdzane przed awarią), a niektóre tracą (jeszcze nie zatwierdzone). W klasie nauczyliśmy się, że działania przegranych muszą zostać cofnięte.

Czy jest jakiś powód, aby robić to wstecz? Czy ktoś może podać prosty przykład dziennika, w którym cofanie w przód dawałoby błędne wyniki?

Oryginalne transakcje:

1. Wstaw rekord .$r$
2. Zaktualizuj niektóre pola z r .$f$$r$

Cofnij do przodu:

1. Usuń rekord .$r$
2. Odwróć aktualizację do - och, czekaj, r już nie istnieje! To powoduje błąd.$r$$r$

Aby dodać do odpowiedzi DylanSp, próba aktualizacji pola w nieistniejącym rekordzie zakończy się niepowodzeniem, ale wynikiem będzie nadal oczekiwany wynik: rekord r nie istnieje.

Rozważ jednak sytuację, w której usunięcie rekordu faktycznie się nie powiedzie:

1. Wstaw zamówienie O.
2. Wstaw wiersz zamówienia L.

Załóżmy, nie nierealnie, że każda linia zamówienia musi być powiązana z zamówieniem.

Cofanie transakcji, zaczynając od usunięcia Zamówienia, zakończy się niepowodzeniem, ponieważ naruszałoby to naszą zasadę biznesową.

Więc później

1. Usuń zamówienie O. (FAIL)
2. Usuń Ordeline L. (SUKCES)

Możemy skończyć z istniejącym Zamówieniem (bez Linii Zamówień).

Oczywiście w tym przypadku moglibyśmy użyć kaskadowego usuwania, ale oznaczałoby to, że krok 2 nie powiedzie się (bez wpływu). Co gorsza, wdrażanie kaskadowego usuwania zleceń może być niepożądane.

Przejdźmy przez analogię: powiedz, że idziesz na obiad.

1. Załóż skarpetki.
2. Załóż buty.
3. Wstań.
4. Idź do drzwi.

Potem dostaniesz telefon. Plany obiadowe anulowane.

1. Zdejmij skarpetki.
2. Zdejmij buty.
3. Usiądź.
4. Odejdź od drzwi.

Coś tam idzie nie tak. Możesz się potknąć i zranić. Lub bardziej prawdopodobne, zdasz sobie sprawę, że niektórych działań nie można cofnąć, dopóki późniejsze działania nie zostaną cofnięte w pierwszej kolejności.

Cofanie ostatniej rzeczy, którą robiłeś, powoduje powrót do miejsca, w którym się znajdowałeś, kiedy nastąpił następny krok. Następnie cofnij ten krok i powtórz, cofając się, dopóki nic nie zostanie. Z drugiej strony cofanie pierwszego kroku może nie być możliwe, biorąc pod uwagę stany następujące po nim.

z matematycznego punktu widzenia: czynności mogą się nie zamieniać, więc zawsze, gdy ma znaczenie to, który krok zrobisz pierwszy lub drugi, kolejność cofania kroków będzie miała znaczenie.

Jest to słuszne, ponieważ transakcje są budowane jeden na drugim, a wynik transakcji w dużej mierze zależy od sytuacji przed jej popełnieniem.

Spójrzmy na transakcje finansowe:

(na początku, zanim transakcje będą ami winne 100 USD)

1. a jest mi winien 100 USD (obecnie całkowity dług 200)
2. aotrzymuje 10% zniżki na to, co jest mi winien. (teraz całkowity dług 180)

Powiedzmy, że chcę anulować dwie transakcje.

Jeśli anulujemy pierwszy, otrzymamy:

1. niższe zadłużenie 100 (teraz mają dług 80)
2. anuluj 10% zniżki (teraz masz dług 80 / 0,9 = 88)

To źle, musimy wrócić do długu w wysokości 100. To będzie słuszne, jeśli anulujemy transakcje w odwrotnej kolejności.

1. anuluj rabat - teraz dług wynosi 200
2. obniż 100 długów - teraz dług wynosi 100

Załóżmy, że istnieje tabela T z tylko jedną kolumną.

Załóżmy, że „dziennik cofania” to plik bazy danych zawierający niezatwierdzone transakcje i że „dziennik ponawiania” to plik bazy danych zawierający zarówno niezatwierdzone, jak i zatwierdzone transakcje, które nie zostały jeszcze zastosowane do plików danych.

At 8:00 A.M., Transaction 100 inserts rows with values 101, 102 and 103 into table T. At 8:10 A.M., Transaction 100 is committed and the commit for transaction 100 completes. At 8:15 A.M., Transaction 200 updates row 101 to 201, 102 to 202 and 103 to 203. At 8:20 A.M., Transaction 200 has not been committed and remains in the undo log of the database. At 8:25 A.M., Transaction 300 increments each row by 50, changing row 201 to 251, 202 to 252, and 203 to 253. At 8:30 A.M., Transaction 300 has not been committed and remains in the undo log of the database. At 8:35 A.M., The instance providing access to the database crashes.

              The committed values in T are still 101, 102 and 103.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, if they are written into the "redo
              log" of the database, there is a need to "roll back"
              the transactions AFTER the "redo log" is applied.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, they are in the "undo log"
              of the database.

              The undo log of the database is used BOTH to (1) roll
              back a transaction that is deliberately rolled 
              back in the memory structure of the database instance, 
              and also (2) during the instance recovery at 8:40 A.M.

              The undo log has not yet been applied.

At 8:42 A.M., The undo log is applied in the reverse order: Uncommitted transaction 300 is undone, and Uncommitted transaction 200 is undone.

Dlaczego ZARÓWNO zatwierdzone i niezaangażowane transakcje są zapisywane w pliku dziennika ponawiania? Powodem tego jest odzyskanie punktu w czasie.

Oznacza to, że zawartość pliku „redo log” NIE jest zgodna z transakcjami. Z tego powodu, ilekroć dziennik ponawiania jest używany do zastosowania zatwierdzonych transakcji do plików danych, „Cofnij dziennik” MUSI SIĘ RÓWNIEŻ używać do wycofania niezatwierdzonych transakcji.

Dlaczego transakcje w „dzienniku cofania” są wycofywane w odwrotnej kolejności? Transakcja 300 dodała 50 do istniejącej wartości każdej kolumny każdego wiersza. Dlatego jeśli transakcja 200 zostanie wycofana jako pierwsza, wartości zmienią się z 251, 252 i 253 na 201, 202 i 203. Jeśli transakcja 300 zostanie następnie wycofana jako ostatnia, wartości wyniosą 151, 152 i 153 - które nie pasują oryginalne zatwierdzone wartości.

BIBLIOGRAFIA:

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1670195800346464273

To nie jest z natury prawda. Wycofanie może po prostu ponownie zastosować bloki, które były buforowane w dzienniku cofania, aby stan końcowy był taki sam jak stan początkowy. Ponieważ dziennik został napisany w kolejności przekazywania, postanowiłem, że moje wycofanie będzie obowiązywać również w kolejności przekazywania. Kolejność nie ma znaczenia, ponieważ wycofanie będzie ponawiać, dopóki plik dziennika nie zostanie oznaczony jako rozliczony.