Ten wykład jest kontynuacją poprzedniego wykładu o transakcjach i jest poświęcony zabezpieczeniom realizowanym przez SZBD na wypadek różnego rodzaju awarii: serwera, dysku, komputera. Są one realizowane na poziomie transakcji użytkowników, to znaczy w chwili awarii wszystkie nie zatwierdzone transakcje są anulowane a efekt wszystkich zatwierdzonych transakcji jest trwały niezależnie od rodzaju awarii.
W dzienniku bazy danych są zapisywane informacje o operacjach wykonywanych na bazie danych przez transakcje oraz inne dodatkowe informacje o zachodzących w bazie danych zdarzeniach.
Każdy rekord dziennika ma przypisany sobie identyfikujący go
numer LSN (ang. log sequence number). Przykładowo, rekord dziennika opisujący zmianę w bazie danych
ma postać:
| <typ operacji, IDtransakcji, IDstrony, offset, długość, before-image, after-image, poprzedniLSN> |
Rys. 13.1 Rejestracja zmian na stronie
Oprócz zmiany danych, rekordy dziennika są tworzone także dla innych akcji takich jak: zatwierdzenie transakcji, wycofanie transakcji.
Są dwa rodzaje dzienników: dzienniki wycofań i dzienniki
powtórzeń. Dziennik
wycofań jest związany z wycofywaniem transakcji oraz z wielowersyjnością.
Dziennik powtórzeń jest związany z odtwarzaniem bazy danych po awarii serwera
lub nośnika danych. Ze względu na
inne spełniane funkcje oba dzienniki zwykle są zapisywane osobno: dziennik
wycofań razem z danymi w bazie danych, a dziennik powórzeń na innym nośniku
danych niż pliki z danymi. W niektórych systemach używa się tylko dziennika powtórzeń,
który, tak czy owak, zawiera w sobie informacje dziennika wycofań.
W celu umożliwienia wycofania transakcji SZBD zapisuje wszystkie zachodzące na
stronach dyskowych zmiany w specjalnym dzienniku wycofań (ang. undo
log) nazywanym w Oracle
segmentami wycofań (ang. undo segments). Dziennik
wycofań jest przechowywany razem z danymi w bazie danych. Gdy trzeba wycofać transakcję, system odczytuje w tył zapisy o zmianach wprowadzonych przez transakcję i przywraca poprzednie wartości
danych w bazie danych - jednocześnie kasując rekordy dziennika wycofań.
Dziennik wycofań może być podstawą realizacji wielowersyjności. Zamiast explicite utrzymywać stare wersje obiektów, można je rekonstruować z aktualnego stanu bazy i informacji wpisanych do dziennika wycofań.
W przypadku wykonywania zapytania jego wyniki powinny być spójne i odpowiadać chwili rozpoczęcia jego wykonywania. W trakcie realizacji zapytania, inne transakcje mogą zmieniać zawartość stron, które są potrzebne do wykonania zapytania (jeśli nie stosujemy blokad współdzielonych S przy wykonywaniu zapytania). W takiej sytuacji, w oparciu o dziennik wycofań należy obliczyć zawartość potrzebnej strony w chwili rozpoczynania realizacji zapytania i użyć tę zawartość do wyznaczenia wyniku zapytania.
Mianowicie, system utrzymuje licznik SCN nazywany systemowym numerem zmiany. Każda zatwierdzona transakcja zwiększa ten licznik o jeden. Wartość SCN może być uważana za identyfikator zatwierdzanej transakcji. Na każdej stronie z danymi jest zapisany numer SCN ostatniej transakcji, która ją zmieniła.
Algorytm wykonywania zapytania
Niech q_SCN będzie aktualnym numerem SCN w chwili rozpoczęcia wykonywania zapytania. W trakcie wykonywania zapytania są odczytywane strony z danymi. Dla każdej takiej strony z jej nagłówka jest odczytywana zapisana w niej wartość s_SCN będąca numerem transakcji, która ją ostatnio zmieniła.
W podobny sposób są wykonywane transakcje raportujące typu READ ONLY.
Dziennik rejestrujący wszystkie zmiany zachodzące w bazie danych jest nazywany dziennikiem powtórzeń (ang.
redo log). Jest on z założenia trzymany na innym nośniku danych niż pliki z danymi w bazie danych. Na ogół, dokonuje się stale jego archiwizacji przepisując go na taśmę.
Dane zmienione przez transakcję nie muszą zostać zapisane na dysk w chwili kończenia transakcji (COMMIT/ROLLBACK) ale mogą zostać zapisane:
przed jej zakończeniem (mówi się wtedy o zjawisku kradzieży ramek - ang. frame stealing);
albo później, po jej zakończeniu (mówi się wtedy o strategii nie używania siły - ang. no force)
– nie ma to znaczenia dla operacji COMMIT, ROLLBACK i możliwości odtworzenia danych w przypadku awarii. Po zapisie do dziennika powtórzeń nawet awaria serwera lub dysku z danymi nie spowoduje utraty danych bo można je odtworzyć.
Informacja o zatwierdzeniu transakcji razem z informacjami o dokonanych przez nią zmianach są najpierw zapisywane do dziennika powtórzeń przechowywanego na innym nośniku danych (dysku) niż pliki z danymi. Jest to częścią zasady nazywanej najpierw-zapis-do-dziennika w skrócie WAL – ang. write-ahead logging. Zasada WAL składa się z dwóch punktów:
(1) Najpierw do dziennika powtórzeń na dysku jest zapisywany rekord opisujący zmianę zawartości strony dopiero potem strona może być zapisana na dysku (zapewnia możliwość przywrócenia poprzedniej zawartości strony w przypadku awarii czyli zapewnia atomowość transakcji).
(2) Transakcja kończy się wtedy, gdy
wszystkie rekordy dziennika powtórzeń dotyczące jej akcji zostaną przepisane z pamięci wewnętrznej
na dysk a nie wtedy gdy dane zmienione przez transakcję zostaną zapisane na
dysk (po zatwierdzeniu nawet w przypadku awarii jest możliwość przywrócenia
danych czyli zapewnia trwałość transakcji).
Gdy nastąpi awaria dysku, rekordy dziennika powtórzeń (z części on-line na osobnym dysku lub części archiwizacyjnej na taśmie) zastosowane do kopii zabezpieczającej bazy danych pozwalają odtworzyć stan bazy danych i struktur danych w pamięci RAM w chwili awarii. Jest to proces nazywany odtwarzaniem do przodu.
Podobnie, w przypadku awarii serwera bazy danych analiza stron bazy danych i dziennika powtórzeń pozwala na odtworzenie stanu bazy danych w chwili awarii.
Ponieważ w dzienniku powtórzeń zapisane są również rekordy dziennika wycofań, jest możliwość wycofania nie zatwierdzonych transakcji, których działanie zostało przerwane w chwili awarii:
Jest to proces nazywany odtwarzaniem do tyłu. W rezultacie tych dwóch odtwarzań jest możliwość doprowadzenia stanu bazy danych do spójnego stanu.
Odtwarzanie po awarii serwera musi mieć określony punkt wyjściowy.
W trakcie normalnej pracy systemu w celu przyśpieszenia ewentualnego odtwarzania bazy danych po awarii serwera, jest realizowana operacja nazywana punktem kontrolnym ang. checkpoint, polegająca na przepisaniu wszystkich zmienionych stron w buforze RAM na dysk, również tych, których zmiany nie zostały jeszcze zatwierdzone. Oznacza to synchronizację aktualnych zawartości buforów pamięci RAM i dysku.
Ponadto, zapisywana jest do dziennika powtórzeń informacja o wszystkich transakcjach i stronach, aktualnie przetwarzanych w buforze pamięci RAM. Dla każdej transakcji jest podawany identyfikator rekordu dziennika powtórzeń rejestrującego ostatnią zmianę, jaka zaszła dla tej transakcji. W osobnym, bezpiecznym miejscu, zapisujemy identyfikator rekordu dziennika powtórzeń opisującego ostatni punkt kontrolny. Od niego rozpoczynamy odtwarzanie po awarii serwera. Dla każdej strony, która w tym momencie była w buforze w RAM, powtarzamy operacje zapisane w dzienniku powtórzeń. Operacja punktu kontrolnego powinna być wykonywana w regularnych odstępach czasu na bazie danych.
W
punkcie kontrolnym istotne jest zapisanie w dzienniku powtórzeń, jakie transakcje i jakie strony
znajdują się aktualnie w pamięci RAM. Można przyśpieszyć wykonywanie
punktu kontrolnego, co za tym idzie i działanie całego serwera bazy danych, przez nie
przepisywanie w tym momencie na dysk zmienionych zawartości buforów bazy
danych. W przypadku
konieczności odtworzenia po awarii serwera, system może odtworzyć stan każdej
strony w oparciu o rekordy dziennika powtórzeń wychodząc od ostatnio
zapisanej zawartości strony w bazie danych. Oznacza to, że wtedy odtwarzanie
trwa dłużej, ale za to punkty kontrolne, trwają krócej.
Punkt kontrolny tego rodzaju nosi nazwę niepełnego punktu
kontrolnego (ang.
fuzzy checkpoint).
Rezerwowa baza danych jest to dodatkowa instalacja bazy danych na osobnym komputerze utrzymywana stale w specjalnym trybie standby – z ciągle dokonywanym odtwarzaniem w oparciu o kopie zarchiwizowanego dziennika powtórzeń generowane przez główną, operacyjną bazę danych.
W przypadku awarii dysku lub katastrofy w rodzaju ataku terrorystycznego, trzęsienia ziemi, pożaru czy kradzieży, rezerwowa bazy danych przechodzi z trybu standby w tryb read write i przejmuje obowiązki głównej bazy danych.
Rezerwowa baza danych znajduje się zwykle w fizycznie oddalonym węźle, do którego stale są przesyłane kolejne części zarchiwizowanego dziennika powtórzeń.
Rezerwowej bazy danych można używać do raportowania – przechodząc w tryb read only – napływające pozycje zarchiwizowanego dziennika powtórzeń utrzymywane są w kolejce, dopóki nie wrócimy do trybu standby. Po przejściu bazy danych w tryb read write nie jest już możliwy jej powrót do trybu standby.
Zamiast rezerwowej bazy danych alternatywę stanowią:
Dla pełności obrazu trzeba jeszcze
wspomnieć, że aksjomat ACID trwałości może być zrealizowany przez użycie macierzy dysków RAID
(skrót od Redundant Array of Independent Disks) umożliwiającej redundantny zapis danych; gdy jeden dysk
ulegnie awarii - dane są pobierane z drugiego.
Wykład 13 przedstawił metody stosowane przez SZBD do zabezpieczeń przed utratą danych w sytuacji zaistnienia awarii.
dziennik wycofań - dziennik rejestrujący wszystkie zmiany zachodzące na stronach dyskowych umożliwiający wycofanie transakcji. Dziennik ten jest zapisywany razem z danymi. W Oracle dziennik ten nazywa się segmentami wycofań.
dziennik powtórzeń - dziennik rejestrujący wszystkie zmiany zachodzące na stronach dyskowych umożliwiający odtworzenie bazy danych po wystąpieniu awarii. Dziennik ten jest zapisywany w innym miejscu niż dane np. na innym dysku. Na ogół jest stale archiwizowany tworząc zarchiwizowany dziennik powtórzeń – przechowywany na nośniku pamięci masowej np. na taśmie magnetycznej. Umożliwia to cykliczne wykorzystywanie miejsca na zapis dziennika powtórzeń na dysku.
odtwarzanie - proces odtwarzania, odzyskiwania danych straconych w wyniku awarii serwera lub dysku z danymi.
punkt kontrolny - synchronizacja pamięci RAM i struktur bazy danych zapisanych na dyskach. Stanowi punkt startowy dla procesu odtwarzania po awarii serwera.
rezerwowa baza danych - dodatkowa instalacja bazy danych na osobnym komputerze utrzymywana stale w specjalnym trybie oczekiwania (standby) – z ciągle dokonywanym odtwarzaniem w oparciu o kopie zarchiwizowanego dziennika powtórzeń generowane przez główną, operacyjną bazę danych.
Brak zadań.