DBMS - Odzyskiwanie danych
Odzyskiwanie po awarii
DBMS to bardzo złożony system, w którym w każdej sekundzie wykonywane są setki transakcji. Trwałość i solidność DBMS zależy od jego złożonej architektury oraz podstawowego sprzętu i oprogramowania systemowego. Jeśli zawiedzie lub ulegnie awarii podczas transakcji, oczekuje się, że system zastosuje jakiś algorytm lub techniki w celu odzyskania utraconych danych.
Klasyfikacja awarii
Aby zobaczyć, gdzie wystąpił problem, uogólniamy awarię na różne kategorie w następujący sposób:
Niepowodzenie transakcji
Transakcja musi zostać przerwana, gdy nie można jej wykonać lub gdy osiągnie punkt, z którego nie może iść dalej. Nazywa się to niepowodzeniem transakcji, gdy tylko kilka transakcji lub procesów jest uszkodzonych.
Przyczyną niepowodzenia transakcji mogą być:
Logical errors - Gdy transakcja nie może zostać zakończona, ponieważ zawiera błąd kodu lub błąd wewnętrzny.
System errors- Gdy system bazy danych sam kończy aktywną transakcję, ponieważ DBMS nie jest w stanie jej wykonać lub musi się zatrzymać z powodu jakiegoś stanu systemu. Na przykład w przypadku zakleszczenia lub niedostępności zasobów system przerywa aktywną transakcję.
Awaria systemu
Istnieją problemy - zewnętrzne w stosunku do systemu - które mogą spowodować nagłe zatrzymanie systemu i awarię systemu. Na przykład przerwy w zasilaniu mogą spowodować awarię sprzętu lub oprogramowania.
Przykładami mogą być błędy systemu operacyjnego.
Awaria dysku
We wczesnych dniach ewolucji technologii był to częsty problem, w którym dyski twarde lub dyski do przechowywania danych często ulegały awarii.
Awarie dysków obejmują tworzenie uszkodzonych sektorów, niedostępność dysku, awarię głowicy dysku lub inną awarię, która niszczy całość lub część pamięci dyskowej.
Struktura przechowywania
Opisaliśmy już system przechowywania. Krótko mówiąc, strukturę przechowywania można podzielić na dwie kategorie -
Volatile storage- Jak sama nazwa wskazuje, ulotna pamięć nie może przetrwać awarii systemu. Urządzenia pamięci ulotnej są umieszczone bardzo blisko procesora; zwykle są osadzone w samym chipsecie. Na przykład pamięć główna i pamięć podręczna są przykładami pamięci ulotnej. Są szybkie, ale mogą przechowywać tylko niewielką ilość informacji.
Non-volatile storage- Te wspomnienia są stworzone, aby przetrwać awarie systemu. Mają ogromną pojemność do przechowywania danych, ale wolniej są dostępne. Przykładami mogą być dyski twarde, taśmy magnetyczne, pamięć flash i nieulotna (podtrzymywana bateryjnie) pamięć RAM.
Odzyskiwanie i atomowość
Kiedy system ulega awarii, może mieć kilka wykonywanych transakcji i otwierać różne pliki w celu zmodyfikowania elementów danych. Transakcje składają się z różnych operacji, które mają charakter atomowy. Ale zgodnie z właściwościami ACID DBMS, należy zachować atomowość transakcji jako całości, to znaczy albo wszystkie operacje są wykonywane, albo żadne.
Kiedy DBMS odzyskuje działanie po awarii, powinien zachować następujące elementy -
Powinien sprawdzać stany wszystkich transakcji, które były wykonywane.
Transakcja może być w trakcie jakiejś operacji; DBMS musi w tym przypadku zapewnić atomowość transakcji.
Powinien sprawdzić, czy transakcja może zostać zakończona teraz, czy też należy ją wycofać.
Żadne transakcje nie będą mogły pozostawić DBMS w niespójnym stanie.
Istnieją dwa rodzaje technik, które mogą pomóc DBMS w odzyskiwaniu i utrzymywaniu niepodzielnej transakcji -
Utrzymywanie dzienników każdej transakcji i zapisywanie ich w stabilnym magazynie przed faktyczną modyfikacją bazy danych.
Utrzymywanie stronicowania w tle, w którym zmiany są dokonywane w pamięci ulotnej, a później aktualna baza danych jest aktualizowana.
Odzyskiwanie na podstawie dziennika
Dziennik to sekwencja rekordów, w której przechowywane są zapisy czynności wykonywanych przez transakcję. Ważne jest, aby dzienniki były zapisywane przed właściwą modyfikacją i przechowywane na stabilnym nośniku, który jest bezpieczny w przypadku awarii.
Odzyskiwanie na podstawie dziennika działa w następujący sposób -
Plik dziennika jest przechowywany na stabilnym nośniku.
Gdy transakcja wchodzi do systemu i rozpoczyna wykonywanie, zapisuje o niej dziennik.
<Tn, Start>
Gdy transakcja modyfikuje pozycję X, zapisuje dzienniki w następujący sposób -
<Tn, X, V1, V2>
Czyta, że T n zmieniło wartość X, z V 1 na V 2 .
- Po zakończeniu transakcji loguje się -
<Tn, commit>
Bazę danych można modyfikować na dwa sposoby -
Deferred database modification - Wszystkie dzienniki są zapisywane w stabilnej pamięci, a baza danych jest aktualizowana po zatwierdzeniu transakcji.
Immediate database modification- Każdy dziennik jest zgodny z rzeczywistą modyfikacją bazy danych. Oznacza to, że baza danych jest modyfikowana natychmiast po każdej operacji.
Odzyskiwanie z jednoczesnymi transakcjami
Gdy równolegle wykonywanych jest więcej niż jedna transakcja, dzienniki są przeplatane. W czasie odzyskiwania system odzyskiwania danych może mieć trudności z odtworzeniem wszystkich dzienników, a następnie rozpoczęciem odzyskiwania. Aby złagodzić tę sytuację, większość nowoczesnych DBMS używa koncepcji „punktów kontrolnych”.
Punkt kontrolny
Prowadzenie i utrzymywanie logów w czasie rzeczywistym oraz w rzeczywistym środowisku może wypełnić całą przestrzeń pamięci dostępną w systemie. W miarę upływu czasu plik dziennika może stać się zbyt duży, aby w ogóle go obsługiwać. Checkpoint to mechanizm, w którym wszystkie poprzednie logi są usuwane z systemu i trwale przechowywane na dysku. Punkt kontrolny deklaruje punkt, przed którym DBMS był w spójnym stanie, a wszystkie transakcje zostały zatwierdzone.
Poprawa
Gdy system z równoległymi transakcjami ulega awarii i odzyskuje działanie, zachowuje się w następujący sposób -
System odzyskiwania odczytuje dzienniki wstecz od końca do ostatniego punktu kontrolnego.
Utrzymuje dwie listy, listę cofania i listę ponawiania.
Jeśli system odzyskiwania widzi dziennik z <T n , Start> i <T n , Commit> lub po prostu <T n , Commit>, umieszcza transakcję na liście powtórzeń.
Jeśli system odzyskiwania widzi dziennik z <T n , Start>, ale nie znaleziono dziennika zatwierdzania ani przerwania, umieszcza transakcję na liście cofania.
Wszystkie transakcje na liście cofnięć są następnie cofane, a ich dzienniki są usuwane. Wszystkie transakcje na liście powtórzeń i ich poprzednie dzienniki są usuwane, a następnie wykonywane ponownie przed zapisaniem ich dzienników.