Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona113/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   105   106   107   108   109   110   111   112   113

Odtwarzanie bazy danych


Odtwarzanie bazy danych (Recovery Data Base) to jest proces przywrócenia je do poprawnego stanu zgodnie z postulatem ASOT.

Baza danych wykorzystuje się dwa typy pamięci:



  • ulotną

  • trwałą.

Wyróżniają się następny typy awarii, które powodują konieczność odtwarzania danych:

  • uszkodzenia pamięci ulotnej;

  • uszkodzenia pamięci trwałej.

Odtwarzanie bazy danych przy uszkodzeniach pamięci ulotnej


Pamięć ulotna jest pamięć operacyjna, a pamięć trwała jest pamięć dyskowa. Pomiędzy tymi dwoma typami pamięci musi być gwarantowane odwzorowanie. Pamięć ulotna zawiera specjalne bufory I/O mające na celu zmniejszenie liczby kosztownych operacji dostępu do wolnej pamięci dyskowej. Bloki dyskowe najczęściej są sprowadzone do bufora i pamiętane tam jako strony w buforze. Informacje o tym, jakie bloki dyskowe znajdują się w buforze , są przechowywane w tablicy bufora (lookaside table). Te bloki mogą zawierać informacje o danych BD. Kiedy w buforze zabraknie miejsca jakaś strona będzie zrzucona na dysk zgodnie ze strategią LRU, według której na dysk zostaje strona najmniej używana.

Wszystkie strony w buforze zawierają rezultaty aktualizacji transakcji współbieżnych w bazie danych oraz zostają w buforze aż:



  • zostaną usunięte w wyniku zastosowania strategii LRU,

  • zostaną zapisane na dysku po zadanym czasie.

Mówią, że strona w buforze jest „brudna”, jeżeli zastała uaktualniona przez transakcję od czasu ostatniego zapisu na dysk. Brudne strony mogą pozostawać w buforze jeszcze długo po tym, jak uaktualniające je transakcje zostały zaakceptowane.

Przypuścimy, że wystąpił zanik napięcia. Jeżeli aktualizowane strony nie były zapisywane na dysk, to będzie stracona informacja o aktualizacjach.

Z kolei zapisywanie strony na dysk zaraz po jej aktualizacji powoduje małą wydajność SZBD. Wydajność SZBD w tym przypadku byłaby wyznaczona wydajnością dysku magnetycznego. Oprócz tego, natychmiastowe zapisywanie danych może doprowadzić do niespójności, jeśli okazałoby się później, że transakcja, która dokonała modyfikacji, nie została zaakceptowana. Transakcja zostanie więc odrzucona, ale zmiany przez nią wprowadzone pozostaną. SZBD musi zapewnić atomowość i trwałość transakcji oraz dostarczyć mechanizm wycofania transakcji (wycofania zmian przez nie zaakceptowaną transakcję).

Zasadą odtwarzania bazy danych jest przechowywanie zbytecznych danych, które odwzorowują konsekwentność operacji aktualizacji transakcji. Te dani są w dzienniku transakcji (pliku logu), który zawiera historię przetwarzania wszystkich transakcji od momentu ostatniego zapisywania dziennika na dysk.

Istnieją dwa warianty realizacji dziennika transakcji:


  1. Realizacja oddzielnego logu dla każdej transakcji

  2. Realizacja ogólnego logu dla wszystkich transakcji.

W pierwszym wariancie każda transakcja chroni historię zmian bazy danych przez operacji tej samej transakcji. Lokalne logi mogą być wykorzystywane dla indywidualnych wycofań oddzielnych transakcji. Oprócz logów lokalnych w tym wariancie jest potrzebny log ogólny dla wyznaczenia kolejności oraz parametrów czasowych wszystkich transakcji. Ten wariant pozwoli realizować szybkie wycofanie oddzielnych transakcji, ale potrzebuje jednoczesnego podtrzymywania wielu logów. Wariant drugi realizuje wykorzystywanie tylko jednego logu. Ten dziennik zawiera informacje pro wszystkie transakcje.

Przykład fragmentu dziennika jest pokazany w tabl.14.



Tabl.14.

Num_Rec

Id_tr

Time

Operacja

Object

Old_ m

New_ m

PPtr

NPtr

1

T1

10:12

Start










0

2

2

T1

10:13

Update

Staff SL21

20

30

1

8

3

T2

10:14

Start










0

4

4

T2

10:16

Insert

Staff SG37




12

3

5

5

T2

10:17

Delete

Staff SA9

90




4

6

6

T2

10:17

Update

Dzial Dz16

12

13

5

9

7

T3

10:18

Start










0

11

8

T1

10:18

Commit










2

0

9

T2

10:19

Commit
















10

T3

10:20

Insert

Dzial Dz19




40

7

11

11

T3

10:21

Commit










10

0

Przeznaczenie atrybutów kolumn tabl. 14 jest następujące:



  • „Num_Rec” - identyfikator rekordu logu;

  • „Id_tr” – identyfikator transakcji;

  • „Time” – znacznik czasowy operacji transakcji;

  • „Operacja” – typ operacji transakcji;

  • „ Object” – identyfikator obiektu danych, który był wykorzystywany przez operację transakcji;

  • „ Old_ m” – kopia obiektu danych do realizacji operacji transakcji;

  • „New_ m” - kopia obiektu danych po realizacji operacji transakcji;

  • „PPtr” – wskaźnik na poprzedni rekord w logu, który zawiera operację tej samej transakcji;

  • „NPtr” - wskaźnik na następny rekord w logu, który zawiera operację tej samej transakcji.

Plik logu jest rozmieszczony w buforu pamięci ulotnej. Rekordy buforu logu mogą być wykorzystywane dla wycofania oddzielnych transakcji przez instrukcje ROLLBACK. Natomiast w przypadkach awarii pamięci ulotnej mogą być stracone wszystkie rekordy logu. W celu odtwarzania bazy danych w tych przypadkach, trzeba mieć kopię logu na dysku oraz ta kopia musi być uzgodniona ze stanem bazy danych. Istnieje protokół WAL(Write Ahead Log), który reglamentuje kolejność zapisywania bufora logu na dysk. W skróci go można określić stwierdzeniem: „zanim zapiszesz coś na dysk najpierw zapisz na dysk bufor logu”. Innymi słowy przed zapisywaniem obiektu bazy danych na dysk, najpierw trzeba zapisać log. Sama baza danych może nie zawierać wszystkich zmian, które odwzorowuje log, ale te zmiany można wprowadzić przez uruchomianie wyznaczonych transakcji w logu. Bufor logu jest zapisywany na dysk w dwóch przypadkach:

  • przy akceptacji jakikolwiek transakcji przez operację COMMIT;

  • przy zdarzeniu licznika czasu (timer).

W przypadku awarii pamięci ulotnej menedżer odtwarzania bazy danych musi analizować stan transakcji w logu, która zapisywała rekordy do bazy w moment awarii. Jeżeli transakcja wykonała operację akceptacji (commit) , to menedżer odtwarzania bazy danych musi powtórzyć wszystkie je operacje z początku – wykonać operację REDO. REDO polega na wczytaniu do buforu strony z danymi bazy danych, potworzeniu jej aktualizacji i zapisywaniu tej strony na dysk. Nowa wartość zapisywanego rekordu do bazy jest pobierana z rekordu logu.

Kiedy ta transakcja nie była zaakceptowana, to menedżer odtwarzania bazy danych musi wycofać wszystkie je rezultaty – od końca do początku – wykonać operację UNDO. UNDO polega na wczytaniu do buforu danej strony z danymi bazy danych, „odkręceniu” jej aktualizacji i zapisywaniu strony na dysk. Poprzednia wartość danych jest pobrana z rekordu logu.



Na fig.46 jest pokazany przykład wykorzystywania logu dla odtwarzania bazy danych. Stan bazy danych moment tlpc (time of last physical consistency) jest zapisany na dysku. W moment tf (time failure) wystąpiła awaria. Dla odtwarzania bazy danych trzeba odczytać wszystkie strony pamięci trwałej, które odwzorowują stan bazy danych na moment tlpc, do bufora pamięci operacyjnej oraz odczytać plik logu. W logu są historie transakcji :T1 – T5. Dla odtwarzania bazy danych trzeba realizować następne czynności:

  • Transakcja T1 była zatwierdzona do momentu tlpc, je rezultaty są w pamięci trwałej bazy danych, dlatego operacji odtwarzania dla tej transakcji nie są potrzebne.

  • Część rezultatów transakcji T2 są w pamięci trwałej. Żeby dostarczać postulat atomowości (ASOT) trzeba powtórzyć wszystkie operacji T2 z początku (wykonać operację REDO).

  • Część rezultatów transakcji T3 są w pamięci trwałej, ale ta transakcja nie została zatwierdzona. Dla transakcji T3 trzeba odkręcić je operacji od końca do samego początku (wykonać operację UNDO).

  • Rezultaty transakcji T4 są nieobecne w pamięci trwałej. Dla transakcji T4 trzeba wykonać operację REDO, bo do momentu awarii została już zatwierdzona.

  • Dla transakcji T5 nie trzeba żądnych czynności odtwarzania, bo rezultaty tej transakcji są nieobecne w pamięci trwałej.





Odtwarzanie bazy danych przy uszkodzeniach pamięci trwałej


Dla odtwarzania bazy danych przy uszkodzeniach dysków trzeba mieć zarchiwowane kopie bazy danych oraz dziennik transakcji od momentu ostatniej archiwacji. Odtwarzanie poczyna się z kopiowania danych z je kopii. Potem dla wszystkich transakcji, które są zaakceptowane realizuje się operacja REDO.

Dla archiwacji bazy danych musi być wyznaczony termin przez administratora bazy danych. Ten termin może być wyznaczony automatyczne po przepełnieniu dziennika transakcji.


Pytania kontrolne po kursu „Obiektowe Bazy danych”.





  1. Ograniczenia relacyjnych baz danych. Reprezentacja nierelacyjnych baz danych.

  2. Zasady obiektowości – abstrakcja, hermetyzacja, modularność, hierarchia. Obiekty. Relacji między obiektami. Klasy. Związki między klasami.

  3. Standardy obiektowych baz danych. Standard obiektowych baz danych ODMG 2.0. Język definiowania obiektów ODL.

  4. Obiektowo relacyjne bazy danych. Język SQL-3. Architektura ORSZBD PostgreSQL.

  5. Standardy systemów rozproszonych. Standard OMG CORBA.

  6. Cele tworzenia UML. Definicja modelu. Ogólne cechy UML. Model pojęczowy UML.

  7. Diagramy klas UML. Modelowanie dziedziny problemu. Diagram klas modelu projektowania. Model MVC (Model View Controller).

  8. Diagramy przypadków użycia. Scenariusze przypadków użycia. Diagramy interakcji.

  9. Diagramy stanów. Diagramy czynności. Diagramy komponentów, wdrożenia.

  10. Wzorce do wyznaczenia odpowiedzialności obiektów.

  11. Wzorce architektury aplikacji WWW. Wzorzec architektury Thin Web Client. Wzorzec architektury Thick Web Client. Rozszerzenie języka UML dla modelowania aplikacji WWW. Modelowanie aplikacji ASP w UML

  12. Modelowanie aplikacji JSP w UML.

  13. Modelowanie komponentów Enterprise JavaBeans (EJB).

  14. Zarządzanie transakcjami w obiektowo relacyjnych bazach danych. Cechy transakcji. Anomalne historii przetwarzania transakcji.

  15. Przetwarzanie transakcji na różnych poziomach izolacji.

  16. Szeregowalność transakcji. Zarządzanie transakcjami w języku SQL.

  17. Metody sterowania współbieżnością transakcji. Metody blokowania danych. Algorytm blokowania dwufazowego. Zakleszczenie transakcji. Metody znaczników czasowych.

  18. Odtwarzanie baz danych. Odtwarzanie przy uszkodzeniach pamięci ulotnej. Odtwarzanie przy uszkodzeniach pamięci trwałej.




1   ...   105   106   107   108   109   110   111   112   113


©operacji.org 2017
wyślij wiadomość

    Strona główna