Rozproszony DBMS - awaria i zatwierdzenie

System zarządzania bazą danych jest podatny na wiele awarii. W tym rozdziale przeanalizujemy typy błędów i protokoły zatwierdzania. W systemie rozproszonych baz danych awarie można ogólnie podzielić na miękkie awarie, twarde awarie i awarie sieci.

Miękka awaria

Awaria miękka to typ awarii, która powoduje utratę pamięci ulotnej komputera, a nie pamięci trwałej. Tutaj informacje przechowywane w pamięci nietrwałej, takie jak pamięć główna, bufory, pamięci podręczne lub rejestry, są tracone. Są również znane jako awaria systemu. Różne rodzaje miękkich awarii są następujące:

Awaria systemu operacyjnego.
Awaria głównej pamięci.
Niepowodzenie transakcji lub aborcja.
System wygenerował błąd, taki jak przepełnienie liczby całkowitej lub błąd dzielenia przez zero.
Awaria oprogramowania wspomagającego.
Brak energii.

Ciężka awaria

Twarda awaria to typ awarii, która powoduje utratę danych w pamięci trwałej lub nieulotnej, takiej jak dysk. Awaria dysku może spowodować uszkodzenie danych w niektórych blokach dyskowych lub uszkodzenie całego dysku. Przyczyny poważnej awarii to:

Brak energii.
Usterki w mediach.
Błąd odczytu i zapisu.
Uszkodzenie informacji na dysku.
Awaria głowicy odczytu / zapisu dysku.

Odzyskiwanie po awarii dysku może być krótkie, jeśli w rezerwie znajduje się nowy, sformatowany i gotowy do użycia dysk. W przeciwnym razie czas trwania obejmuje czas potrzebny na uzyskanie zamówienia, zakup dysku i przygotowanie go.

Awaria sieci

Awarie sieci są powszechne w rozproszonych lub sieciowych bazach danych. Obejmuje to błędy wywołane w systemie baz danych ze względu na rozproszony charakter danych i przesyłanie danych w sieci. Przyczyny awarii sieci są następujące -

Błąd łącza komunikacyjnego.
Przeciążenie sieci.
Uszkodzenie informacji podczas przesyłania.
Błędy witryny.
Partycjonowanie sieci.

Protokoły zatwierdzania

Każdy system baz danych powinien gwarantować zachowanie pożądanych właściwości transakcji nawet po awarii. Jeżeli podczas wykonywania transakcji wystąpi awaria, może się zdarzyć, że wszystkie zmiany wprowadzone przez transakcję nie zostaną zatwierdzone. To powoduje, że baza danych jest niespójna. Protokoły zatwierdzania zapobiegają temu scenariuszowi przy użyciu cofania transakcji (wycofywanie) lub ponawiania transakcji (przywracanie).

Punkt zatwierdzenia

Moment, w którym podejmowana jest decyzja o zatwierdzeniu lub przerwaniu transakcji, nazywany jest punktem zatwierdzenia. Poniżej przedstawiono właściwości punktu zatwierdzenia.

Jest to moment, w którym baza danych jest spójna.
W tym momencie modyfikacje wprowadzone przez bazę danych można zobaczyć w innych transakcjach. Wszystkie transakcje mogą mieć spójny widok bazy danych.
W tym momencie wszystkie operacje transakcji zostały pomyślnie wykonane, a ich efekty zostały zapisane w dzienniku transakcji.
W tym momencie transakcję można w razie potrzeby bezpiecznie cofnąć.
W tym momencie transakcja zwalnia wszystkie posiadane przez nią blokady.

Cofnij transakcję

Proces cofania wszystkich zmian wprowadzonych w bazie danych przez transakcję nazywa się cofnięciem transakcji lub wycofaniem transakcji. Jest to najczęściej stosowane w przypadku miękkich awarii.

Ponów transakcję

Proces ponownego zastosowania zmian wprowadzonych do bazy danych przez transakcję nazywa się ponowieniem transakcji lub wycofaniem transakcji. Dotyczy to głównie odzyskiwania po poważnej awarii.

Dziennik transakcji

Dziennik transakcji to plik sekwencyjny, który śledzi operacje transakcyjne na elementach bazy danych. Ponieważ dziennik ma charakter sekwencyjny, jest przetwarzany sekwencyjnie od początku lub od końca.

Cele dziennika transakcji -

Obsługa protokołów zatwierdzania do zatwierdzania lub obsługi transakcji.
Aby wspomóc odzyskiwanie bazy danych po awarii.

Dziennik transakcji jest zwykle przechowywany na dysku, więc nie ma na niego wpływu miękkie awarie. Ponadto dziennik jest okresowo zapisywany w kopii zapasowej w magazynie archiwalnym, takim jak taśma magnetyczna, aby chronić go również przed awariami dysków.

Listy w dziennikach transakcji

Dziennik transakcji przechowuje pięć typów list w zależności od statusu transakcji. Lista ta pomaga menedżerowi ds. Odzyskiwania w ustaleniu statusu transakcji. Stan i odpowiednie listy są następujące -

Transakcja, która ma rekord rozpoczęcia transakcji i rekord zatwierdzenia transakcji, jest transakcją zatwierdzoną - utrzymywaną na liście zatwierdzeń.
Transakcja, która ma rekord rozpoczęcia transakcji i rekord nieudanej transakcji, ale nie rekord przerwania transakcji, jest transakcją zakończoną niepowodzeniem - utrzymywaną na liście nieudanych transakcji.
Transakcja, która ma rekord rozpoczęcia transakcji i rekord przerwania transakcji, jest transakcją przerwaną - utrzymywaną na liście przerwanych.
Transakcja, która ma rekord rozpoczęcia transakcji i rekord transakcji przed zatwierdzeniem, jest transakcją przed zatwierdzeniem, tj. Transakcją, w której wszystkie operacje zostały wykonane, ale nie zostały zatwierdzone - utrzymywana na liście przed zatwierdzeniem.
Transakcja, która ma rekord rozpoczęcia transakcji, ale nie ma zapisów przed zatwierdzeniem, zatwierdzeniem, przerwaniem lub niepowodzeniem, jest transakcją aktywną - utrzymywaną na liście aktywnej.

Natychmiastowa aktualizacja i odroczona aktualizacja

Natychmiastowa aktualizacja i odroczona aktualizacja to dwie metody obsługi dzienników transakcji.

W immediate updatetryb, kiedy transakcja jest wykonywana, aktualizacje dokonywane przez transakcję są zapisywane bezpośrednio na dysku. Stare wartości i wartości aktualizacji są zapisywane w dzienniku przed zapisaniem w bazie danych na dysku. Po zatwierdzeniu zmiany wprowadzone na dysku stają się trwałe. Podczas wycofywania zmiany wprowadzone przez transakcję w bazie danych są odrzucane, a stare wartości są przywracane do bazy danych ze starych wartości zapisanych w dzienniku.

W deferred updatetryb, gdy transakcja jest wykonywana, aktualizacje wprowadzone do bazy danych przez transakcję są rejestrowane w pliku dziennika. Po zatwierdzeniu zmiany w dzienniku są zapisywane na dysku. Podczas wycofywania zmiany w dzienniku są odrzucane i żadne zmiany nie są stosowane w bazie danych.