Zapewnienie spójności logicznej w bazie danych2



Pobieranie 38,9 Kb.
Data24.02.2019
Rozmiar38,9 Kb.


WYBRANE PROBLEMY ZARZĄDZANIA

RELACYJNĄ BAZĄ DANYCH


Laboratorium Baz Danych

Materiały pomocnicze

Autorzy:


Katarzyna Harężlak

Henryk Josiński







1 Zapewnienie spójności logicznej w bazie danych2




System zarządzania relacyjną bazą danych (SZRBD) realizuje elementarne operacje dostępu do jednego lub wielu rekordów tabel bazy danych. Operując na danych zmienia stan bazy rozumiany jako zbiór aktualnych wartości w poszczególnych kolumnach rekordów. Stan bazy jest nazywany zgodnym, jeśli ten zbiór wartości jest spójny logicznie, co oznacza, że są spełnione warunki integralności definiujące zależności między danymi (np. "wiek biologicznego ojca musi być większy od wieku syna").

Jednym z zadań systemu zarządzania jest utrzymywanie stanu zgodności bazy danych. Do ważniejszych środków realizacji tego celu zaliczane są transakcje. Transakcja jest jednostką przetwarzania złożoną z elementarnych operacji dostępu, która jest niepodzielna: może być wykonana tylko w całości lub wcale, ale nie może być wykonana częściowo. Oznacza to, że jeżeli transakcja nie kończy wszystkich przewidzianych przez nią akcji (z dowolnego powodu, np. wskutek błędu, awarii, niedostępności zasobów lub danych), wtedy wszystkie operacje, które dotychczas zostały przez transakcję wykonane, zostają anulowane. Ta własność transakcji nosi nazwę atomowości. Do innych własności zalicza się: spójność, izolację oraz trwałość skutków. Transakcja przeprowadza bazę danych z jednego stanu zgodnego w inny. W międzyczasie, podczas trwania transakcji, stan bazy może nie być zgodny, ale tylko w ramach tej transakcji (spójność). Ponadto transakcja nie uwzględnia efektów działania innych współbieżnych transakcji i nie ma żadnych skutków dla innych transakcji działających w tym samym czasie (izolacja). Po zakończeniu transakcji jej skutki są trwałe i nie mogą zostać odwrócone przez jakiekolwiek przypadkowe zdarzenie (trwałość skutków). Własność ta jest zapewniona dzięki istnieniu pliku nazywanego logiem, do którego SZRBD zapisuje informacje o przebiegu transakcji.

Przetwarzanie transakcji odbywa się w trzech fazach:

(1) blokowanie danych (uzyskanie prawa do operowania danymi), obliczenia i aktualizacje danych w pamięci operacyjnej,

(2) aktualizacja pliku log, osiągnięcie tzw. punktu wypełnienia, od którego zmiany dokonane przez transakcję uznaje się za trwałe; transakcję w tym stanie nazywa się wypełnioną,

(3) fizyczne wprowadzenie aktualizacji do bazy danych i odblokowanie danych dla innych transakcji.

Podczas wykonywania transakcji może wystąpić nieprzewidziane zdarzenie (awaria), przerywając wykonanie transakcji. Jeśli awaria nastąpiła w trakcie fazy (1), usuwane są wszystkie ślady wykonania tej transakcji, czyli następuje powrót do stanu sprzed zmian przez nią wprowadzonych zgodnie z własnością atomowości transakcji. Natomiast wystąpienie awarii po zakończeniu fazy (2) wymaga dokończenia transakcji, realizowanego przez powtórne wykonanie operacji do niej należących, zapisanych w pliku log.

Algorytm ten realizowany jest przez SZRBD automatycznie, jeśli awaria, która spowodowała przerwanie transakcji należy do grupy tzw. awarii lekkich (np. chwilowy brak prądu, reset komputera, zakleszczenie transakcji (konflikt w dostępie do zasobów)). Opisany sposób postępowania okazuje się niewystarczający w przypadku awarii powodujących zniszczenie plików danych w bazie – awarii ciężkich (np. uszkodzenie nośnika danych). Możliwość likwidacji skutków awarii tego rodzaju uzależniona jest, poza prowadzeniem zapisów w pliku log (na innym dysku niż pliki bazy), także regularnego sporządzania – przez właściciela bazy danych – kopii danych w stanie zgodnym, przechowywanej, podobnie jak plik log, na innym nośniku niż sama baza. Odtworzenia (odrestaurowania) uszkodzonej bazy danych dokonuje jej właściciel za pomocą narzędzi dostarczanych przez system. W procesie tym na kopii danych wykonywane są operacje zapisane w pliku log, należące do transakcji, które zakończyły się po sporządzeniu kopii.



3 Transakcje w systemie Ingres


W systemie Ingres domyślny zakres transakcji obejmuje całą sesję z bazą danych (tzn. wszystkie operacje wykonane od chwili nawiązania połączenia z bazą danych do chwili zamknięcia połączenia). Wskazane jest jednak, by transakcje były tak krótkie, jak to tylko jest możliwe. Istnieją dwa sposoby zmiany zakresu transakcji:

(1) użycie instrukcji COMMIT dla wypełnienia transakcji,

użycie instrukcji ROLLBACK dla anulowania transakcji,

(2) użycie instrukcji SET AUTOCOMMIT ON ustalającej zakres transakcji na pojedynczą operację na danych (ponowne rozszerzenie zakresu następuje po wykonaniu instrukcji SET AUTOCOMMIT OFF).

Opis przebiegu każdej transakcji umieszczany jest w pliku log wspólnym dla wszystkich baz danych i użytkowników. Duża liczba wykonywanych transakcji może więc spowodować jego przepełnienie. Konieczne jest zatem okresowe usuwanie z pliku log zapisów dotyczących zakończonych transakcji. Mogłoby to jednak uniemożliwić odrestaurowanie bazy w przypadku ciężkiej awarii. Z tego względu wprowadzono kronikowanie – przenoszenie zapisów dla wybranych tabel z pliku log do pliku dziennika (ang. journal) przez proces archiwizatora. O wyborze kronikowanych tabel decyduje właściciel bazy danych, posługując się instrukcją SET JOURNALING ON nazwa_tabeli. Ma on również możliwość przeglądania dziennika za pomocą zlecenia ALTERDB nazwa_bazy_danych.

Do odrestaurowania bazy po ciężkiej awarii potrzebna jest kopia bazy danych w stanie zgodnym. Sporządza się ją zleceniem CKPDB +j –d nazwa_bazy_danych, gdzie +j gwarantuje wykonanie kopii bazy w stanie zgodnym, którą można aktualizować za pomocą dziennika, –d powoduje usunięcie poprzedniej kopii. Właściciel bazy danych przystępując do odrestaurowania bazy wykonuje zlecenie ROLLFORWARDDB nazwa_bazy_danych. System wywołuje wówczas proces archiwizatora, którego zadaniem jest przeniesienie z pliku log do dziennika zapisów o kronikowanych transakcjach, które miały miejsce dla bazy danych od ostatniego uruchomienia archiwizatora. Następnie na kopii danych wykonywane są operacje zapisane w dzienniku, należące do transakcji, które zakończyły się dopiero po sporządzeniu kopii. W ten sposób odtwarza się bazę danych znajdującą się w ostatnim stanie zgodnym przed wystąpieniem awarii.

Skutki awarii lekkich system Ingres usuwa automatycznie zgodnie z algorytmem przytoczonym w poprzednim punkcie.

4 Kontrola współbieżnego dostępu do danych5


Utrzymywanie bazy danych w stanie zgodnym wymaga od SZRBD umiejętności zarządzania współbieżnym dostępem do danych. Oznacza to, że żaden z użytkowników bazy danych nie powinien odczytywać lub aktualizować rekordów, których zawartość jest właśnie zmieniana przez innego użytkownika. Zezwolenie na taką sytuację jest zgodą na udostępnianie nieaktualnych danych. System bazy danych musi więc sprawować kontrolę nad przebiegiem transakcji, stosując wielopoziomowy mechanizm blokad dostępu do danych. Blokowanie wszystkich rekordów dla każdego rodzaju operacji mogłoby być nieefektywne i sprowadzałoby się do szeregowego wykonania ciągu operacji. Wprowadzono więc pewne reguły określające zakres (poziom) oraz sposób blokowania danych, które zapewniają współbieżny dostęp do rekordów z utrzymaniem stanu zgodnego bazy danych.

Reguła 1

Poziom blokowania określany jest przez blokowaną jednostką danych, którą może być: pojedynczy rekord, zbiór rekordów mieszczących się na jednej stronie danych (jej wielkość zależy od systemu), tabela oraz baza danych.



Reguła 2

Dwie transakcje mogą korzystać z tej samej jednostki danych, jeśli obydwie wykonują operację odczytu.



Reguła 3

Żadna z transakcji nie powinna modyfikować wartości odczytywanej przez inną transakcję, zanim ta ostatnia nie osiągnie punktu wypełnienia.



Reguła 4

Żadna z transakcji nie powinna odczytywać wartości modyfikowanej przez inną transakcję, zanim ta ostatnia nie osiągnie punktu wypełnienia.

Na podstawie powyższych reguł wprowadzono następujące rodzaje blokad:

EXCLUSIVE – przydzielenie jednostki danych na wyłączność, co oznacza niedostępność tej jednostki dla innych transakcji do chwili zdjęcia blokady,

SHARED – umożliwienie współbieżnego dostępu do jednostki danych innym transakcjom, których wykonanie nie będzie sprzeczne z wyżej wymienionymi regułami,

NOLOCK – rezygnacja z blokowania jednostki danych.

Posługując się tymi trzema rodzajami blokad określa się tryb wykonywania operacji odczytu i zapisu (modyfikacji). W SZRBD istnieje domyślny tryb blokowania jednostki danych dla realizacji tych dwóch operacji (np. odczyt – SHARED, zapis – EXCLUSIVE), który może zostać zmieniony przez właściciela bazy danych. Decyzja ta pozwoli w określonych sytuacjach wpłynąć w oczekiwany sposób na efektywność działania systemu, ale musi zostać podjęta ze świadomością faktu, że może spowodować niespójność logiczną danych przechowywanych w bazie.

Konsekwencją stosowania blokad jest konieczność wstrzymywania wykonania transakcji żądającej dostępu do jednostki danych wykorzystywanej aktualnie przez inną transakcję, jeśli ich współbieżna realizacja prowadziłaby do sprzeczności z przytoczonymi regułami. Oczekiwanie na zwolnienie jednostki danych przebiega w różny sposób w zależności od systemu. Wstrzymywana transakcja może co określony czas sprawdzać dostępność danych i ewentualnie po kilku próbach zakończonych niepowodzeniem zrezygnować z planowanych operacji. Innym rozwiązaniem jest pozostawienie transakcji w stanie oczekiwania aż do przyznania jej żądanego dostępu do jednostki danych, co kontrolowane jest przez wydzielony moduł SZRBD. Użytkownik ma wtedy jednak możliwość określenia maksymalnego czasu oczekiwania, po którym wstrzymana transakcja zostanie wycofana.

Niepożądanym zjawiskiem mogącym wystąpić przy próbie współbieżnego dostępu do danych jest zakleszczenie (impas, ang. deadlock). Ma ono miejsce m.in. w sytuacji, kiedy transakcja T1 blokuje dostęp do jednostki danych A i żąda wyłącznego dostępu do jednostki danych B, zaś transakcja T2 blokuje dostęp do jednostki B i żąda wyłącznego dostępu do jednostki A. Zakleszczeniu można zapobiegać stosując strategie blokowania do niego nie dopuszczające. Zakładają one przy przewidywaniu wystąpienia impasu udział systemu, który w takiej sytuacji opóźnia wykonanie jednej z transakcji. Alternatywnym rozwiązaniem jest wykorzystywanie metod pozwalających zlikwidować zakleszczenie przez wycofanie jednej z transakcji, co pozwala na dokończenie drugiej.

6 Blokady w systemie Ingres


W systemie Ingres stosowane są trzy poziomy blokad: zbiór rekordów mieszczących się w całości na jednej stronie danych o rozmiarze 2048 kB, tabela oraz baza danych. Jako domyślny przyjmuje się poziom strony danych, lecz ze względu na zasięg operacji i strukturę danych może wystąpić potrzeba zablokowania większej liczby stron. Maksymalna liczba równocześnie blokowanych przez daną transakcję stron tej samej tabeli wynosi 10. W przypadku jej przekroczenia następuje automatycznie zmiana poziomu blokowania (eskalacja blokad) z poziomu strony danych na poziom tabeli. Blokowanie całej bazy danych stosowane jest tylko przez SZRBD w procesie zarządzania, np. przy wykonywaniu kopii bazy w stanie zgodnym lub w trakcie odrestaurowania bazy.

Poza określeniem poziomu blokad należy również wskazać rodzaj stosowanej blokady: EXCLUSIVE, SHARED lub NOLOCK. Dla operacji modyfikacji danych zawsze stosowana jest blokada EXCLUSIVE, natomiast dla operacji odczytu domyślnie przyjmuje się blokadę SHARED. Blokady są zakładane tuż po rozpoczęciu transakcji, a zdejmowane w chwili jej zakończenia.

System Ingres dopuszcza zmianę domyślnych parametrów blokad za pomocą instrukcji SET LOCKMODE o następującej składni:

SET LOCKMODE SESSION | ON nazwa_tabeli | nazwa_indeksu

WHERE [LEVEL = PAGE | TABLE | SESSION | SYSTEM]

[, READLOCK = NOLOCK | SHARED | EXCLUSIVE | SESSION | SYSTEM]

[, MAXLOCKS = n | SESSION | SYSTEM]

[, TIMEOUT = n | SESSION | SYSTEM];

W pierwszym wierszu określa się zasięg obowiązywania ustawianych parametrów, gdzie:

SESSION oznacza aktualną sesję z bazą danych,

ON nazwa_tabeli | nazwa_indeksu dotyczy wskazanej tabeli lub indeksu.

Pojawiające się w pozostałych frazach słowa kluczowe SESSION oraz SYSTEM reprezentują wartości odpowiednich parametrów obowiązujące w bieżącej sesji lub w całym systemie.

Fraza LEVEL służy do wyboru poziomu blokad.

Fraza READLOCK wykorzystywana jest do zmiany rodzaju blokady przy operacji odczytu.

Fraza MAXLOCKS pozwala na zmianę progu eskalacji blokad (n oznacza liczbę stron).

Problem obsługi oczekiwania na zwolnienie jednostki danych rozwiązano przez pozostawienie transakcji w stanie oczekiwania aż do przyznania jej żądanego dostępu. Stąd fraza TIMEOUT służy do określenia maksymalnego czasu oczekiwania transakcji na dostęp do danych (n oznacza liczbę sekund).

System Ingres dopuszcza występowanie zakleszczeń, likwidując je przez wycofanie jednej z transakcji, które spowodowały impas.

W systemie Ingres istnieje również możliwość korzystania z różnych poziomów izolacji dla operacji odczytu, które stosuje się w celu uzyskania kompromisu pomiędzy spójnością danych i współbieżnością realizacji transakcji. Wśród poziomów tych wyróżnia się:


  1. Read Uncomitted (RU) – brak blokad dla operacji odczytu, dający możliwość równoczesnego korzystania z tych danych innym transakcjom.

  2. Read Committed (R) – zwalnianie blokad zakładanych na rekordy natychmiast po ich odczycie.

  3. Repeatable Read (RR) – zwolnienie blokad rekordów pobranych do odczytu, ale nigdy nie odczytanych. Umożliwia to równoczesne wprowadzanie danych realizowane przez inną transakcję.

  4. Serializable (S) – utrzymanie blokad założonych przy odczycie do zakończenia transakcji. Niemożliwe w ten sposób staje się dokonywanie jakichkolwiek modyfikacji na blokowanych danych, łącznie z dodawaniem nowych rekordów.

Poziom izolacji ustala się w poleceniem:

SET SESSION READ ONLY | READ WRITE,

ISOLATION LEVEL SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED

lub:

SET TRANSACTION SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED










©operacji.org 2017
wyślij wiadomość

    Strona główna