Piotr Gawrysiak pgawrysiak@supermedia.pl Bazy danych Wykład 5 Piotr Gawrysiak pgawrysiak@supermedia.pl.

Prezentacja na temat: "Piotr Gawrysiak pgawrysiak@supermedia.pl Bazy danych Wykład 5 Piotr Gawrysiak pgawrysiak@supermedia.pl."— Zapis prezentacji:

1 Piotr Gawrysiak pgawrysiak@supermedia.pl
Bazy danych Wykład 5 Piotr Gawrysiak

2 Więzy integralności (referential integrity)
Baza danych powinna zawsze być spójna Operacje – szczególnie wykonywane ręcznie – mogą prowadzić do wprowadzania błędnych danych Mogą także prowadzić do usuwania danych, które powinny w bazie pozostać Bazy relacyjne wyposażone są w mechanizmy „obronne” zapewniające zachowanie integralności: wartości kluczy głównych związki klucz obcy – klucz główny ograniczenia wartości atrybutów związki pomiędzy relacjami (assertions) aktywne elementy bazy danych – wyzwalacze (triggers)

3 Klucze główne i obce deklarowane w poleceniu CREATE TABLE
dwie możliwości: PRIMARY KEY – bezpośrednia definicja klucza UNIQUE – wymaganie, aby atrybut posiadał unikalne wartości tabela może posiadać wiele atrybutów typu UNIQUE ale tylko jeden klucz główny dla PRIMARY KEY także dwa rodzaje składni CREATE TABLE Student ( name CHAR(30) PRIMARY KEY, address CHAR(255) ); name CHAR(30), address CHAR(255) PRIMARY KEY (name) ); Klucz złożony – np. PRIMARY KEY (name, title)

4 PRIMARY KEY a UNIQUE w zasadzie to samo ale:
może być tylko jeden klucz głowny PRIMARY KEY PRIMARY KEY zabrania wstawienia wartości typu NULL zaś UNIQUE nie DBMS może automatycznie zakładać indeks na atrybut zdefiniowany jako PRIMARY KEY składnia podobna: CREATE TABLE Student ( name CHAR(30) UNIQUE, address CHAR(255) ); name CHAR(30), address CHAR(255) UNIQUE (name) );

5 Sprawdzanie więzów integralności dla kluczy
za każdym razem kiedy wprowadzana jest zmiana do tabeli trzeba sprawdzić wartości atrybutu klucza naruszenie integralności wystąpić może tylko przy zmianie danych lub dodaniu danych, nie przy usuwaniu wstawiając nową wartość DBMS musi wyszukać potencjalne inne wystąpienie tej wartości w kolumnie – aby to zrobić efektywnie niezbędny jest indeks w niektórych implementacjach SQL mamy: CREATE UNIQUE INDEX StudentName ON Student(name); w przypadku znalezienia wartości atrybutu należy przerwać wykonywanie operacji wstawiania lub modyfikacji danych

6 Klucze obce – foreign key constraints
SQL pozwala na zdefiniowanie wybranych atrybutów jako kluczy obcych (pochodzących z innych tabel) pod warunkiem, że: atrybut taki w tabeli źródłowej jest kluczem (czyli że zdefiniowany jest za pomocą PRIMARY KEY lub UNIQUE) wartości klucza obcego pojawią się w odp. kolumnie tabeli docelowej dwie możliwości: CREATE TABLE Student ( name CHAR(30) UNIQUE, address CHAR(255) wykladID INT REFERENCES Wyklad(ID) ); wykladID INT FOREIGN KEY (wykladID) REFERENCES Wyklad(ID) );

7 Sprawdzanie więzów integralności dla FK
Różne możliwości implementacji w DBMS: Odrzucanie modyfikacji (Reject Policy) : próba wstawienia nowej krotki do tabeli Student gdzie wartość WykladID nie jest żadną z wartości w kolumnie ID tabeli Wyklad i nie jest równy NULL uaktualnienie krotki w tabeli Student zmieniające atrybut WykladID na wartość nie występującą w w kolumnie ID tabeli Wyklad i nie równą NULL usunięcie krotki z tabeli Wyklad, której wartość atrybutu ID pojawia się w kolumnie WykladID tabeli Student uaktualnienie krotki z tabeli Wyklad tak, że zmianie ulega wartość atrybutu ID, która już istnieje w tabeli Student Powyższe operacje nie zostaną wykonane

8 Sprawdzanie więzów integralności dla FK, cd.
Propagacja modyfikacji (Cascade Policy) : Zmiany w jednej z połączonych tabeli powodują automatyczne wprowadzenie odpowiednich zmian w drugiej tabeli usunięcie krotki z tabeli Wyklad o wartości atrybutu ID w1 spowoduje usunięcie wszystkich tych krotek z tabeli student gdzie WykladID=w1 zmiana wartości atrybutu ID w tabeli Wyklad z w1 na w2 spowoduje zamianę wszystkich wystąpień w1 na w2 w kolumnie WykladID tabeli Student

9 Sprawdzanie więzów integralności dla FK, cd.
Wstawianie wartości pustych (Set-Null Policy) : Zamiana usuniętych wartości klucza obcego na wartość NULL Można ustawić policy stosowaną dla poszczególnych związków poprzez polecenia ON DELETE i ON UPDATE wraz z SET NULL i CASCADE CREATE TABLE Student ( name CHAR(30) UNIQUE, address CHAR(255) wykladID INT REFERENCES Wyklad(ID) ON DELETE SET NULL ON UPDATE CASCADE); Usunięcie wykładu spowoduje wstawienie wartości NULL w odpowiednich krotkach w tabeli Student, zaś zmiana identyfikatora wykładu zostanie automatycznie uwzględniona w tabeli Student

10 Opóźnienie sprawdzania więzów integralności
Aby dodać nową grupę studentów, która ma uczęszczać na nowy wykład, trzeba zacząć od modyfikacji tabeli Wyklad – kolejność wykonania operacji, może być niewygodna. W przypadku circular reference to się w ogóle może nie dać zrobić. Więzy integralności powinny być zatem sprawdzane dopiero wtedy, gdy wszystkie operacje modyfikacji związane ze związkiem zostały zakończone: Wsparcie dla transakcji (możliwość zgrupowania kilku operacji w jeden niepodzielny blok), Możliwość wskazania wybranych więzów jako takich, których sprawdzenie można opóźnić. (NOT) DEFERABLE – (nie) można opóźnić sprawdzenie do zakończenia transakcji Jeśli DEFERABLE to dodatkowo: INITITALLY DEFERRED INITIALLY IMMEDIATE

11 Ograniczenia dla atrybutów
Możliwe jest specyfikowanie dodatkowych ograniczeń na wartości atrybutów relacji lub na wystąpienia całych krotek Ograniczenie wystąpienia wartości NULL WykladID INT REFERENCES Wyklad(ID) NOT NULL Ograniczenia wartości atrybutu – za pomocą słowa kluczowego CHECK (warunek) <- to może być dowolny warunek jaki wystąpić może w wyrażeniu WHERE np. numery wykładów muszą być co najmniej trzycyfrowe CHECK (WykladID >= 100) np. jakiś atrybut musi przyjmować tylko dwie wartości: plec CHAR(1) CHECK (plec IN (‘K’,‘M’))

12 Ograniczenia dla krotek
Ograniczenie wartości kilku atrybutów w danej krotce: np. CREATE TABLE Student ( name CHAR(30) PRIMARY KEY, address CHAR(255), gender CHAR(1), birthdate DATE, CHECK (gender = ‘F’ OR name NOT LIKE ‘Ms.%’) ); Prawa DeMorgana – NOT (x1 AND x2) = NOT x1 OR NOT x2

13 Modyfikowanie ograniczeń
Aby po utworzeniu modyfikować ograniczenia, musimy mieć możliwość nadania im nazw: np. name CHAR(30) CONSTRAINT NameIsKey PRIMARY KEY Plec CHAR(1) CONSTRAINT WlasciwaPlec CHECK(gender IN (‘K’,’M’)) CONSTRAINT RightTitle CHECK( gender = ‘F’ OR name NOT LIKE ‘Ms.%’) Usuwanie ograniczeń – jako modyfikacja tabeli ALTER TABLE Student DROP CONSTRAINT NameIsKey; ALTER TABLE Student DROP CONSTRAINT WlasciwaPlec;

14 Często w instrukcji wyszukiwania sprawdza się czy napis jest zgodny z pewnym ustalonym wzorcem, np. czy zaczyna się od ustalonej litery lub zawiera ustalone podsłowo. W opisach wzorca symbol % zastępuje dowolny napis. wzorzec porównanie LIKE ‘A%’ zaczyna się od A LIKE ‘%A%’ zawiera A LIKE ‘_A%’ zawiera A jako drugi znak LIKE ‘A%B%’ zaczyna się od A i zawiera B NOT LIKE ‘A%’ nie zaczyna się od A

15 Dodawanie ograniczeń W podobny sposób, poprzez modyfikację tabeli:
ALTER TABLE Student ADD CONSTRAINT NameIsKey PRIMARY KEY (name); ALTER TABLE Student ADD CONSTRAINT WlasciwaPlec CHECK(plec IN (‘K’,’M’); Powtórnie nadane nazwy mogą być inne od pierwotnych, można także ich w ogóle nie użyć.

16 Niezmienniki (assertions)
Możliwe jest tworzenie funkcji sprawdzających nie związanych z żadną konkretną tabelą Ta funkcja powinna być zawsze prawdziwa CREATE ASSERTION <nazwa> CHECK (<warunek>) np. chcemy, aby liczba wszystkich studentów na wykładzie nie była nigdy większa od 10 CREATE ASSERTION LiczbaWykladow CHECK (10 >= ALL (SELECT COUNT(*) FROM Student GROUP BY WykladID ) ); Usuwanie niezmienników – DROP ASSERTION <nazwa>

17 Sprawdzenia więzów integralności
Rodzaj ograniczenia Gdzie deklarowany Kiedy sprawdzany CHECK – do atrybutów Element definicji atrybutu Przy wstawianiu do tabeli lub modyfikacji atrybutu CHECK – do krotek Element schematu relacji Przy wstawianiu do tabeli lub modyfikacji krotki Niezmienniki Odrębny element schematu bazy danych Przy jakiejkolwiek zmianie tabel

18 Wyzwalacze (triggers)
Akcje uruchamiane wtedy gdy zachodzi pewne zdarzenie w bazie danych W odróżnieniu od ograniczeń, trigger sprawdza pewien warunek i dopiero wtedy podejmowana jest decyzja o tym, czy wykonać związaną z nim akcję Możliwości: Akcja może być wykonana przed albo po zdarzeniu Akcja może odwoływać się do starych i nowych wartości atrybutów Zdarzenie można ograniczyć tylko do pewnego zbioru atrybutów Zdarzenie specyfikowane przez słowo kluczowe WHEN Możliwość wykonania akcji dla każdej modyfikowanej krotki albo dla wszystkich krotek na raz

19 Wyzwalacze (triggers) cd.
Tabela Prezes(nazwisko, adres, FirmaID, wartosc) Utwórzmy wyzwalacz, który będzie przeciwdziałał próbie modyfikacji obniżającej wartość CREATE TRIGGER WartoscWyzw AFTER UPDATE OF wartosc ON Prezes REFERENCING OLD ROW AS StaryWiersz NEW ROW AS NowyWiersz FOR EACH ROW WHEN (StaryWiersz.wartosc > NowyWiersz.wartosc) UPDATE Prezes SET wartosc = StaryWiersz.wartosc WHERE FirmaID = NowyWiersz.FirmaID

20 Wyzwalacze (triggers) cd.
Tabela Prezes(nazwisko, adres, FirmaID, wartosc) Utwórzmy wyzwalacz, który będzie zapewniał że średnia wartość wszystkich prezesów jest większa od 500 tyś. Np. dla UPDATE: CREATE TRIGGER SrWartoscWyzw AFTER UPDATE OF wartosc ON Prezes REFERENCING OLD TABLE AS StaraTabela NEW TABLE AS NowaTabela FOR EACH STATEMENT WHEN ( > (SELECT AVG(wartosc) FROM Prezes)) BEGIN DELETE FROM Prezes WHERE (nazwisko, adres, FirmaID, wartosc) IN NowaTabela; INSERT INTO Prezes (SELECT * FROM StaraTabela); END;

21 Wyzwalacze INSTEAD-OF
Nie wspierane przez np. SQL99 Pozwalają na wykonanie pewnej operacji zamiast (a nie przed lub po) inną operacją, która uruchomiła wyzwalacz Np. CREATE TRIGGER InsertTrigger INSTEAD OF INSTERT ON Student REFERENCING NEW ROW AS NowyWiersz FOR EACH ROW INSERT INTO itd.

22 Transakcje - współbieżność
Spójność bazy danych, spójność procesów działających na bazie danych. Jeżeli wiele procesów działa jednocześnie na bazie danych: Czas 1 2 3 4 5 6 Proces A Czyta X X :=X+1 Zapisuje X Proces B Czyta X X := X+1 Zapisuje X Wartość XA 5 6 Wartość XB 5 6 Jeżeli te dwa procesy działałyby niezależnie, wynik = 7. Działając równolegle i nie synchronizując swoich akcji jedna aktualizacja została zgubiona. Transakcje: umożliwienie zachowania spójności w takiej sytuacji bez potrzeby umawiania się.

23 Transakcje - przeciwdziałanie awariom
Załóżmy, że mamy system bankowy, w którym następują operacje na kontach klientów w sposób następujący: 1. Klient wczytuje kartę magnetyczną i jest rozpoznawany 2. Klient określa sumę wypłaty 3. Konto klienta jest sprawdzane 4. Konto jest zmniejszane o sumę wypłaty 5. Wysyłane jest zlecenie do kasy 6. Kasjerka odlicza sumę wypłaty od stanu kasy 7. Kasjerka wypłaca klientowi pieniądze Pytanie: co się stanie, jeżeli pomiędzy operacją 4 i 5 wyłączą zasilanie? Transakcje: uniknięcie sytuacji związanych z dowolnymi awariami sprzętu, błędów w oprogramowaniu, itp.

24 Transakcje - ACID Transakcje vs procedury: Transakcja angażuje bieżące zasoby systemu takie jak czas i dane. Wywołanie procedury może być transakcją, ale może ona też składać się z wielu wywołań procedur i jedno wywołanie może generować wiele transakcji. Transakcje mogą obejść się w ogóle bez procedur. Własności transakcji: ACID Atomowość (atomicity) - w ramach jednej transakcji wykonują się albo wszystkie operacje, albo żadna Spójność (consistency) - o ile transakcja zastała bazę danych w spójnym stanie, po jej zakończeniu stan jest również spójny. (W międzyczasie stan może być chwilowo niespójny) Izolacja (isolation) - transakcja nie wie nic o innych transakcjach i nie musi uwzględniać ich działania. Czynności wykonane przez daną transakcję są niewidoczne dla innych transakcji aż do jej zakończenia. Trwałość (durability) - po zakończeniu transakcji jej skutki są na trwale zapamiętane (na dysku) i nie mogą być odwrócone przez zdarzenia losowe (np. wyłączenie prądu) A C I D

25 Atomowość transakcji Transakcja może dokonać swojego zatwierdzenia (commit) po zakończeniu wszystkich swoich akcji lub dokonać wycofania (abort) (ewentualnie zostać wycofana przez SZBD) po wykonaniu wszystkich lub części swoich akcji. Atomowość (niepodzielność) – transakcja albo wykonuje wszystkie swoje akcje tak jakby w jednym kroku albo nie wykonuje żadnych swoich akcji. SZBD zapisuje wszystkie wykonywane akcje w dzienniku (logu) tak aby w razie potrzeby móc skasować wszystkie akcje wycofywanych transakcji.

26 Przykład transakcji Zacznij transakcję (begin transaction);
Zidentyfikuj klienta; Jeżeli nie da się zidentyfikować to zerwij (abort); Wczytaj zlecenie wypłaty; Sprawdź konto klienta; Jeżeli konto < zlecenia to komunikat o przekroczeniu konta; zerwij (abort); Wyślij zlecenie do kasy; Jeżeli upłynął czas większy od 5 minut to cofnij zlecenie do kasy; zerwij transakcję (abort); Jeżeli kasjer potwierdził dokonanie wypłaty to potwierdź transakcję (commit) a inaczej Transakcja, która zaczęła się w systemie jest identyfikowana jako specjalny byt; jest jej nadawany unikalny numer (identyfikator). abort - kasowanie transakcji i wszelkich skutków które ona poczyniła commit - wprowadzenie skutków transakcji na dysk i skasowanie transakcji Takie programy mogą być proste lub dowolnie skomplikowane. Z tego względu miara liczba transakcji/sekundę jest często mało wiarygodna.

27 Transakcje - współbieżność
Współbieżne wykonywanie programów użytkowników jest istotne dla szybkości działania aplikacji bazodanowych. Dostęp do danych na dysku jest częsty i względnie wolny, więc procesor może współbieżnie wykonywać kilka programów. Transakcja jest abstrakcyjną reprezentacją programu użytkownika: ciągiem odczytów i zapisów. Współbieżność uzyskuje się przez przeplecenie odczytów i zapisów różnych transakcji. Efekt powinien być taki jakby transakcje były wykonywane niezależnie od siebie.

28 Przykład T1: BEGIN A=A+100, B=B-100 END
Intuicyjnie transakcja T1 dokonuje transferu $100 z konta B na konto A. Transakcja T2 dopisuje do obu kont 6% odsetki. Poprawna realizacja obu transakcji powinna być równoważna albo szeregowemu wykonaniu T1 potem T2 albo szeregowemu wykonaniu T2 potem T1. W przykładzie w obu przypadkach efekt jest taki sam. Efekt jednak nie musi być taki sam – więc efekt wykonania kilku transakcji może być niedeterministyczny.

29 Realizacja transakcji
Poprawny przeplot akcji obu transakcji: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Niepoprawny plan: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Co do operacji dyskowych: T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B)

30 Anomalie związane z transakcjami
Odczyt niezatwierdzonych danych (ang. dirty read) - transakcja odczytuje dane, które zmieniła druga transakcja ale ich nie zatwierdziła. Niepowtarzalny odczyt - w ramach tej samej transakcji, widać zmiany wprowadzane przez zatwierdzone transakcje. Fantom - wiersz, którego nie było w tabeli na początku wykonywania transakcji, a który został wprowadzony przez zatwierdzoną transakcję w trakcie wykonywania transakcji.

31 Anomalie przeplotu Odczyt niezatwierdzonych danych (konflikt WR):
Niepowtarzalny odczyt (konflikt RW): T1: R(A), W(A), R(B), W(B), Abort T2: R(A), W(A), C T1: R(A), R(A), W(A), C T2: R(A), W(A), C Nadpisanie niezatwierdzonych danych (konflikt WW): T1: W(A), W(B), C T2: W(A), W(B), C

32 Kryterium poprawności transakcji
Współbieżne wykonanie transakcji jest poprawne wtedy i tylko wtedy jeżeli jego efekt jest dokładnie taki sam jak efekt wykonania tych transakcji pojedynczo po kolei. Ta własność nosi nazwę szeregowalności (serializability) Plan wykonania transakcji: - Transakcje rozbija się na mniejsze fragmenty zwane operacjami. - Plan ustala jak po kolei mają być wykonywane operacje z poszczególnych transakcji. Plan szeregowy: Najpierw akcje jednej transakcji, następnie akcje drugiej transakcji. Równoważne plany: Efekt realizacji obu planów taki sam dla każdego stanu bazy danych. Plan szeregowalny: Plan, który jest równoważny pewnemu planowi szeregowemu (realizacja transakcji przez SZBD ma własność izolacji) . Jeśli każda transakcja zachowuje spójność bazy danych, każdy plan szeregowalny także zachowuje spójność bazy danych (realizacja transakcji przez SZBD ma własność spójności) .

33 Zapewnienie szeregowalności
blokady (zamki) – ograniczające działanie innych transakcji na zablokowanym obiekcie mechanizm wielowersyjności - umożliwiający odczytywanie danych zmienianych równocześnie przez inne transakcje w takiej postaci w jakiej istniały w chwili rozpoczynania się danej transakcji (przy czym dana transakcja widzi zmiany dokonane od tego czasu przez samą siebie).

34 Blokady Blokada (lock): jedna z transakcji rezerwuje sobie dostęp do obiektu. Inne transakcje nie mają dostępu lub mają dostęp ograniczony. X Wyłączna (exclusive lock): transakcja zablokowuje jakikolwiek dostęp do obiektu dla innych transakcji. Tylko jedna transakcja może mieć założoną wyłączną blokadę na obiekcie i w tym czasie nie może być założonej żadnej innej blokady nawet współdzielonej. Dzielona (shared lock): inne transakcje mogą czytać, ale nie mogą modyfikować. Kilka transakcji może jednocześnie pracować na tej samej tabeli. Jeśli transakcja zakłada współdzieloną blokadę, inne transakcje też mogą założyć współdzieloną blokadę, ale nie mogą założyć wyłącznej blokady. S Szeregowalność jest zachowana, jeżeli cała transakcja ma dwie fazy: rosnącą i skracającą. potwierdzenie (commit) Protokół 2PL (two-phase locking) koniec start zakładanie (nie ma zwalniania) zwalnianie (nie ma zakładania) czas

35 Two phase locking Protokół ścisłego blokowania dwufazowego (Strict 2PL): Każda transakcja musi uzyskać blokadę S (współdzieloną) na obiekcie zanim odczyta ten obiekt oraz blokadę X (wyłączną) na obiekcie przed zapisaniem go. Jeśli transakcja trzyma blokadę X na obiekcie, żadna inna transakcja nie ma prawa założyć żadnej blokady (ani S ani X) na tym obiekcie. Jeśli transakcja trzyma blokadę S na obiekcie, żadna inna transakcja nie ma prawa założyć blokady X na tym obiekcie. Gdy transakcja nie może założyć blokady na obiekcie, może ustawić się w kolejce oczekujących transakcji stowarzyszonej z tym obiektem. Blokady trzymane przez transakcję są zwalniane gdy transakcja się kończy. Protokół Strict 2PL gwarantuje realizację wyłącznie planów szeregowalnych.

36 Zakleszczenie Koncepcja zamków zawiera możliwość wystąpienia zakleszczenia. Transakcja A zablokowała zasób X i żąda dostępu do zasobu Y Transakcja B zablokowała zasób Y i żąda dostępu do zasobu X. Ani A, ani B nie mogą dalej kontynuować jakiejkolwiek akcji. „System zawiesił się” Możliwe są bardziej skomplikowane sytuacje związane z zakleszczeniem: Zakleszczyły się dwie transakcje, pozostałe działają normalnie: W pętli zakleszczenia są 3 transakcje: Transakcja A Transakcja B Transakcja C Transakcja A Transakcja B Transakcja C

37 Walka z zakleszczeniem
Bardzo poważny problem, mający skutki zarówno dla wydajności systemu jak i spójności działania (szczególnie w systemach czasu rzeczywistego). 1. Wykrywanie zakleszczeń i rozrywanie pętli zakleszczenia. Detekcja zakleszczenia wymaga skonstruowania grafu czekania (wait-for graph) i tranzytywnego domknięcia tego grafu (złożoność gorsza niż n * n). Rozrywanie pętli zakleszczenia polega na wybraniu transakcji “ofiary” uczestniczącej w zakleszczeniu i następnie, jej zerwaniu i uruchomieniu od nowa. Wybór “ofiary” podlega różnym kryteriom - np. najmłodsza, najmniej pracochłonna, o niskim priorytecie, itd. 2. Nie dopuszczanie do zakleszczeń. Istnieje wiele tego rodzaju metod, np. a) Wstępne żądanie zasobów (preclaiming): przed uruchomieniem każda transakcja określa potrzebne jej zasoby. Nie może później nic więcej żądać. Wada: zgrubne oszacowanie żądanych zasobów prowadzi do zmniejszenia stopnia współbieżności. b) Czekasz-umieraj (wait-die): jeżeli transakcja próbuje dostać się do zasobu, który jest zablokowany, to natychmiast jest zrywana i powtarzana od nowa. Metoda może być nieskuteczna dla systemów interakcyjnych (użytkownik może się denerwować koniecznością dwukrotnego wprowadzania tych samych danych) oraz prowadzi do spadku efektywności (sporo pracy idzie na marne).

38 Wykrywanie zakleszczeń
Utwórz graf oczekiwań na blokadę: Węzłami są transakcje. Istnieje krawędź od Ti do Tj jeśli Ti oczekuje na zwolnienie blokady przez Tj. Co jakiś czas sprawdzaj czy jest cykl. Transakcja A Transakcja B Transakcja C

39 Zapobieganie zakleszczeniom
Przypisz priorytety na podstawie znaczników czasowych. Przypuśćmy, że transakcja Ti chce założyć blokadę, którą utrzymuje transakcja Tj. Dwie strategie: “Wait-Die”: Jeśli Ti ma wyższy priorytet, Ti czeka na Tj; wpp. Ti zostaje wycofana. “Wound-wait”: Jeśli Ti ma wyższy priorytet, Tj zostaje wycofana; wpp. Ti czeka. Przy restartowaniu transakcji, ma ona swój początkowy znacznik czasowy zapewniający jej wyższy priorytet od transakcji, które rozpoczęły się później od niej. Gwarantuje to wykonanie tej transakcji prędzej lub później (“nie zagłodzenie jej”) .

40 Przykład T1 T2 T1 T2 T4 T3 T3 T3 T1: S(A), R(A), S(B)
T2: X(B),W(B) X(C) T3: S(C), R(C) X(A) T4: X(B) T1 T2 T1 T2 T4 T3 T3 T3

41 Blokady wielopoziomowe
Obiekty bazodanowe są zagnieżdżone. Blokada na podobiekcie implikuje pewną blokadę na nad-obiekcie (i na odwrót). Rekord Tabela Strona Baza danych zawiera Grube ziarna (baza danych, relacja) - mały stopień współbieżności Miałkie ziarna (np. element krotki) - duża pracochłonność zakładania zamków, duże zapotrzebowanie na dodatkową, pamięć na zamki, przeciążenie sieci

42 Zmienna ziarnistość Pomysł (Gray, 1977) polega na tym, aby obiekty do blokowania organizować hierarchicznie i blokować w nich tyle, ile trzeba. Pomysł bardzo dobry dla obiektowych baz danych. A blokuje do aktualizacji cały obiekt B blokuje do aktualizacji kawałek obiektu A blokuje A blokuje do czytania cały obiekt B blokuje do czytania kawałek obiektu

43 Optymistyczne blokowanie
Faza 1: Transakcja wczytuje potrzebne dane do swoich lokalnych buforów i na nich dokonuje zmian bez zakładania żadnych blokad. Faza 2: Transakcja sprawdza czy dokonane przez nią odczyty i zapisy nie pozostają w konflikcie z odczytami i zapisami zatwierdzonych już transakcji. Jeśli nie, następuje przepisanie zmian z lokalnych buforów do globalnych i zatwierdzenie transakcji. Jeśli tak, następuje restartowanie jeszcze raz tej samej transakcji. Tylko w czasie realizacji Fazy 2 jest konieczność założenia blokad X na zmieniane obiekty. Wielowersyjność: Procesy zapisujące tworzą nową kopię obiektu podczas gdy procesy odczytujące korzystają ciągle ze starej wersji:

44 Komendy w SQL do przetwarzania transakcji
Dowolne zdanie select, insert, update, delete, create rozpoczyna transakcję, o ile nie była ona już przez tę transakcję rozpoczęta. Transakcja trwa aż do do wydania komendy COMMIT (potwierdzającej), ABORT lub ROLLBACK (zrywającej, cofającej). Transakcja może objąć dowolną liczbę zdań select, insert, update, delete, create i innych. Komenda SAVEPOINT <nazwa> oznacza zapamiętanie stanu pod określoną nazwą. ABORT TO <nazwa> oznacza odtworzenie stanu. SQL posiada także “isolations levels” (poziomy izolacji). Np. byłoby prawie niemożliwe zrobienie raportu operacji na koniec dnia, jeżeli system byłby w ciągłym ruchu, ponieważ zawsze jakieś dane byłyby zablokowane. Osłabienie izolacji jest więc czasami konieczne, ale powinno to być traktowane wyjątkowo, ze specjalnym statusem, ze specjalnymi środkami bezpieczeństwa.

45 Isolation levels Czy transakcje widzą zmiany dokonywane przez inne współbieżnie działające transakcje? NIE Serializable TAK Repeatable Reads Read Committed Read Uncommitted Fantomy Niepowtarzalny odczyt Niezatw-ierdzonyodczyt Poziom izolacji

46 Ustawianie poziomu izolacji w SQL
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; COMMIT; SET TRANSACTION ISOLATION LEVEL READ COMMITED;

47 Dziennik wycofań W celu umożliwienia wycofania transakcji SZBD zapisuje wszystkie wykonywane przez nią zmiany w specjalnym dzienniku wycofań (ang. undo log). Gdy trzeba wycofać transakcję system odczytuje w tył zapisy o zmianach wprowadzonych przez transakcję i przywraca poprzednie wartości danych. W przypadku stosowania wielowersyjności: Efekt wykonania zapytania powinien być spójny i odpowiadać chwili rozpoczęcia jego wykonywania. Już w chwili zakończenia wykonywania instrukcji stan bazy danych może być inny (jeśli nie stosujemy blokad współdzielonych przy wykonywaniu zapytania). SCN - systemowy numer zmiany. Każda zatwierdzona transakcja zwiększa ten licznik o jeden. SCN może być uważany za identyfikator zatwierdzanej transakcji. Na każdej stronie jest zapisany SCN ostatniej transakcji, która ją zmieniła.

48 Algorytm wykonywania zapytania
Niech q_SCN będzie aktualnym SCN w chwili rozpoczęcia wykonywania zapytania. W trakcie wykonywania zapytania są odczytywane strony danych. Dla każdej takiej strony z nagłówka jest odczytywany zapisany w nim s_SCN (numer transakcji, która ją ostatnio zmieniła). Jeśli s_SCN <= q_SCN, wtedy można zawartość strony użyć w obliczeniach. Jeśli s_SCN > q_SCN, wtedy w oparciu o segmenty wycofań należy obliczyć zawartość strony w chwili q_SCN i użyć tę zawartość do wykonania zapytania.

49 Typy awarii i reakcje na awarie
Zerwanie transakcji: z różnych powodów, wewnętrznych (np. czekaj-umieraj) lub zewnętrznych. Transakcja może być powtarzana automatycznie lub (jeżeli to niemożliwe) stracona. Program wywołujący transakcje powinien przewidywać sytuację, że transakcja może być zerwana, wykryć to i ewentualnie powtórzyć. Awaria systemu, ze stratą zawartości pamięci operacyjnej Awaria nośników pamięci, ze stratą zawartości dysku. Absolutna niezawodność absolutna złożoność, nieskończony koszt Rozsądna niezawodność mały wpływ na wydajność. Transakcje rozsądnie podwyższają niezawodność, nie prowadząc do nadmiernych obciążeń czasu wykonania ani dodatkowego zapotrzebowania na pamięć.

50 Odtwarzanie po awarii - środki, terminy
Cykliczne przegrywanie zawartości bazy danych lub jej najważniejszych fragmentów na inny nośnik (najczęściej taśmę magnetyczną). Cykl: co 30 min (banki), na koniec dnia (instytucje), co tydzień (uniwersytety), itp. Back up Odtwarzanie (pół-automatyczne lub automatyczne) stanu bazy danych po awarii na podstawie ostatniego backup-u i ew. logu. Recovery Rejestracja wszystkich operacji zachodzących na bazie danych wraz ze zmienianymi obiektami, z dokładnością do transakcji, które to robią Log Cofanie operacji w bazie danych na podstawie logu, np. po zerwaniu transakcji Rollback Migawkowe zdjęcie stanu przetwarzania (trwałych i nietrwałych obiektów, stanu sterowania, itd.) stosowane w niektórych systemach celem powrotu do poprzedniego stanu, o ile programista/użytkownik tego sobie zażyczył. Stosowane dla wykonania operacji undo. Checkpoint Zdublowanie informacji na fizycznie i geograficznie oddzielonych nośnikach, celem zwiększenia niezawodności i zmniejszenia kosztów transmisji. Replication

51 Dziennik powtórzeń i odtwarzanie
Dziennik rejestrujący wszystkie zmiany zachodzące w bazie danych - 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ę. Zmiana danych na stronie i informacja o zatwierdzeniu są najpierw zapisywane do dziennika powtórzeń, dopiero potem uwzględniane w pliku danych na dysku (zasada WAL – write-ahead logging). Po zapisie do dziennika powtórzeń nawet awaria serwera lub dysku z danymi nie spowoduje utraty danych bo można je odtworzyć (własność trwałości) .

52 Dziennik powtórzeń i odtwarzanie
Gdy nastąpi awaria dysku, pozycje dziennika powtórzeń (z części on-line na dysku lub części archiwizacyjnej na taśmie) zastosowane do kopii zabezpieczającej pozwalają odtworzyć stan bazy danych w chwili awarii. Jest to proces nazywany odtwarzaniem do przodu. W przypadku awarii serwera bazy danych analiza samego dziennika powtórzeń pozwala na odtworzenie stanu bazy danych w chwili awarii. Ponieważ w dzienniku zapisane są również pozycje segmentów wycofań, jest możliwość wycofania nie zatwierdzonych transakcji, których działanie zostało przerwane w chwili awarii na przykład przy transferze pieniędzy - z jednego konta pieniądze zostają zdjęte, w tej chwili następuje awaria, na drugie konto pieniądze już nie zostają przelane 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.

53 Rezerwowa baza danych (stand-by)
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 trzesięnia 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 zwykle znajduje się w fizycznie oddalonym węźle, do którego stale są przesyłane kolejne części zarchiwizowanego dziennika powtórzeń.