Spójność bazy danych

Spójność bazy danych

• stan bazy danych jest zgodny ze stanem

reprezentowanego przez nią fragmentu rzeczywistości,

• wszystkie ograniczenia integralnościowe w bazie danych są

spełnione.

Poziomy spójności w bazie danych:

Poziomy spójności w bazie danych:

• spójność polecenia – zbiór danych odczytanych przez

pojedyncze polecenie pochodzi z tego samego momentu w

czasie (momentu rozpoczęcia wykonania polecenia),

• spójność transakcji – zbiór danych, odczytywanych przez

wszystkie zapytania w pojedynczej transakcji, pochodzi z

tego samego momentu w czasie (momentu rozpoczęcia

transakcji).

Zagrożenia spójności

Zagrożenia spójności

:

• awarie, działania użytkowników,

• współbieżny dostęp do danych.

Spójność transakcji

Spójność transakcji

• Sytuacja, w której kilka transakcji

wykonuje równolegle operacje na

tych samych danych.

Anomalie współbieżnego dostępu:

Anomalie współbieżnego dostępu:

– brudny odczyt (ang. dirty read)
– utracona modyfikacja (ang. lost

update),

– niepowtarzalny odczyt (ang. non-

repeatable read),

– fantomy (ang. phantoms).

Współbieżność transakcji

Współbieżność transakcji

• odczyt niezatwierdzonych danych

(ang. read uncommitted)

• odczyt zatwierdzonych danych

(ang. read committed)

• powtarzalny odczyt (ang.

repeatable read),

• uszeregowalny (ang. serializable).

Poziomy izolacji transakcji

Poziomy izolacji transakcji

Poziomy izolacji transakcji

Poziomy izolacji transakcji

Poziom

Poziom

izolacji/

izolacji/

Anomalia

Anomalia

Dirty

read

Non-

repeatable

read

Phantoms

Read

Read

uncommitte

uncommitte

d

d

możliwa

możliwa

możliwa

Read

Read

committed

committed

brak

brak

możliwa

możliwa

możliwa

Repeatable

Repeatable

read

read

brak

brak

brak

brak

możliwa

Serializable

Serializable

brak

brak

brak

brak

brak

brak

Określenie poziomu izolacji transakcji:
– dla transakcji:

Określenie poziomu izolacji

Określenie poziomu izolacji

SET TRANSACTION ISOLATION LEVEL
{READ UNCOMMITTED | READ COMMITTED
| REPEATABLE READ | SERIALIZABLE};

dla sesji (SZBD Oracle):

ALTER SESSION SET ISOLATION_LEVEL =
{READ COMMITTED | SERIALIZABLE};

Określenie trybu dostępu transakcji

SET TRANSACTION {READ WRITE | READ ONLY};

Algorytmy:

• optymistyczne – wykorzystanie znaczników

czasowych,

• pesymistyczne – wykorzystanie blokad,

najczęściej stosowany algorytm: blokowanie

dwufazowe (2PL)

Blokada – przydzielenie zasobu do zadania

Rodzaje blokad:

• wyłączne – zasób może być przydzielony tylko

do jednego zadania,

• współdzielone – zasób może zostać

przydzielony jednocześnie wielu zadaniom.

Zarządzanie współbieżnością

Zarządzanie współbieżnością

Zadanie, któremu przydzielany jest zasób to

transakcja

Blokowany zasób:

– atrybut
– rekord
– strona dyskowa
– relacja
– baza danych

Zarządzanie współbieżnością

Zarządzanie współbieżnością

mniejsze ziarno
blokowania

większe ziarno
blokowania

wysoki
poziom
współbieżnośc
i

niski poziom
współbieżnośc
i

Blokady w systemie ORACLE

Blokady w systemie ORACLE

• Ziarno blokowania: rekord i relacja
• Rodzaje blokad:

– rekord – blokada wyłączna,
– relacja – blokada wyłączna lub współdzielona.

• Blokowanie jest realizowane automatycznie bez

udziału użytkownika.

• Operacje odczytu danych nie wymagają

założenia blokad

Odroczone ograniczenia

Odroczone ograniczenia

integralnościowe

integralnościowe

• Sprawdzane w momencie zatwierdzenia transakcji
• Definiowanie:

[ CONSTRAINT nazwa_ograniczenia ] ograniczenie
DEFERRABLE
INITIALLY { IMMEDIATE | DEFERRED }

• Określenie momentu sprawdzenia w bieżącej transakcji (tylko dla

ograniczeń zdefiniowanych jako odroczone):

SET CONSTRAINTS { <lista_ograniczeń> | ALL }
{ DEFERRED | IMMEDIATE };

Odroczone ograniczenia

Odroczone ograniczenia

integralnościowe

integralnościowe

Przykład:

CREATE TABLE osoby(
id NUMBER(4) PRIMARY KEY
DEFERRABLE INITIALLY DEFERRED,
nazwisko VARCHAR2(100) NOT NULL);
INSERT INTO osoby VALUES(1, 'Nowacki');
INSERT INTO osoby VALUES(1, 'Kowalski');
SELECT * FROM osoby;
COMMIT;

P1.C1.KRAKOW.PL

W1.C1.WARSZAWA.

PL

P2.WROCLAW.PL

update konta@P1.C1.

update konta@P1.C1.

KRAKOW

KRAKOW

.PL .....;

.PL .....;

update

update

konta@W

konta@W

1

1

.C

.C

1

1

.WAR

.WAR

SZAWA

SZAWA

.PL .....;

.PL .....;

update

update

accounts@

accounts@

P2.WROCLAW.PL

P2.WROCLAW.PL

.....;

.....;

commit;

commit;

Transakcja, której polecenia INSERT, UPDATE, DELETE, SELECT

odwołują się do tabel znajdujących się co najmniej w dwóch
węzłach rozproszonej bazy danych

Transakcja rozproszona

Transakcja rozproszona

transakcja, której polecenia DML odwołują się

do tabel znajdujących się co najmniej w dwóch

węzłach rozproszonej bazy danych

Transakcja rozproszona

Transakcja rozproszona

reprezentowana jest przez zbiór transakcji

lokalnych, które są tworzone w każdej z baz

danych, do których odwołuje się transakcja

rozproszona

Koordynator globalny KG

(global

coordinator) – węzeł, z którego została

zainicjowana transakcja rozproszona

Zarządza całą transakcją tj. doprowadza ją w

całości do zatwierdzenia lub wycofania

Węzły uczestniczące w transakcji

Węzły uczestniczące w transakcji

rozproszonej

rozproszonej

Koordynator lokalny KL

(local coordinator) –

węzeł, który otrzymuje żądanie, przetwarza je i

wysyła kolejne żądania do innych podległych mu

węzłów

Nie koordynuje całej transakcji globalnej, a jedynie

te żądania, które zostały przez niego wysłane

Węzeł zatwierdzania WZ

(commit point site) –

węzeł, który jako pierwszy wykonuje

zatwierdzenie swojej transakcji lokalnej w ramach

całej transakcji rozproszonej

Węzły uczestniczące w transakcji

Węzły uczestniczące w transakcji

rozproszonej

rozproszonej

Przechowuje informacje o stanie transakcji rozproszonej,

które wykorzystuje się w czasie manualnego kończenia

transakcji po awarii systemu rozproszonego

Wybierany jest przez KG spośród wszystkich węzłów

biorących udział w transakcji rozproszonej – decyduje

najwyższa wartość parametru konfiguracyjnego instancji

bazy danych

COMMIT_POINT_STRENGTH

Uczestnik U

(mode) – węzeł do którego

kierowane jest żądanie transakcji rozproszonej

(sam węzeł nie wysyła żadnych żądań)

Protokół zatwierdzania dwufazowego

Protokół zatwierdzania dwufazowego

2PC

2PC

Protokół

Protokół

2PC

2PC

składa się z dwóch głównych faz

składa się z dwóch głównych faz

• przygotowania
• decyzji

Protokół ten może być implementowany jako

Protokół ten może być implementowany jako

:

-

scentralizowany 2PC

- zdecentralizowany 2PC
- liniowy 2PC

Protokół scentralizowany 2PC

Protokół scentralizowany 2PC

Koncepcja pracy protokołu 2PC jest następująca:

•

Koordynator globalny, pyta uczestników czy są gotowi do
zatwierdzenia swoich transakcji lokalnych.

•

Jeśli przynajmniej jeden uczestnik odpowiada
komunikatem ABORT (nie jest gotowy), lub nie odpowie w
zadanym czasie, wówczas koordynator globalny wysyła do
wszystkich uczestników komunikat wycofania transakcji.

•

Jeśli natomiast wszyscy uczestnicy zgłoszą gotowość do
zatwierdzenia swoich transakcji lokalnych, wówczas
koordynator globalny wysyła do nich komunikat żądający
zatwierdzenia transakcji.

Protokół scentralizowany 2PC

Protokół scentralizowany 2PC

Topologia komunikacyjna

Faza przygotowania

Faza przygotowania

Koordynator globalny

Koordynator globalny

– zapisuje w lokalnym logu (na dysku)

informacji o rozpoczęciu zatwierdzania

– wysyła do uczestników komunikat PREPARE

(przygotowanie do zatwierdzania)

– przechodzi do stanu oczekiwania na

komunikaty od uczestników

Faza przygotowania

Faza przygotowania

Uczestnik:

Uczestnik:

– odbiera komunikatu PREPARE od KG

a) przygotowanie do zatwierdzenia

a) przygotowanie do zatwierdzenia

–

zapisanie do logu stanu transakcji i rekordu o gotowości
do zatwierdzania

–

wysłanie do KG komunikatu READY_COMMIT

b) przygotowanie do wycofania

b) przygotowanie do wycofania

–

zapisuje do logu stanu transakcji i rekordu o
wycofywaniu

–

wysyła do KG komunikatu ABORT

–

przechodzi do stanu oczekiwania na kolejny komunikat
od KG

Faza decyzji

Faza decyzji

Koordynator globalny

Koordynator globalny

a) jeżeli wszyscy uczestnicy odpowiedzieli

a) jeżeli wszyscy uczestnicy odpowiedzieli

READY_COMMIT

READY_COMMIT

• zapis do logu informacji o zatwierdzeniu
• wysłanie komunikatu GLOBAL_COMMIT do

uczestników

b) jeżeli przynajmniej jeden U odpowiedział ABORT

b) jeżeli przynajmniej jeden U odpowiedział ABORT

• zapis do logu informacji o wycofaniu
• wysłanie GLOBAL_ABORT do uczestników

oczekiwanie na potwierdzenia od uczestników

Faza decyzji

Faza decyzji

Uczestnik

• jeśli odebrany GLOBAL_COMMIT

–

zapis do logu informacji o zatwierdzeniu

–

zatwierdzenie transakcji lokalnej

–

zwolnienie blokad i zasobów systemowych

–

wysłanie potwierdzenia do KG

• jeśli odebrany GLOBAL_ABORT

–

zapis do logu informacji o wycofaniu

–

wycofanie transakcji lokalnej

–

zwolnienie blokad i zasobów systemowych

–

wysłanie potwierdzenia do KG

Faza decyzji

Faza decyzji

Koordynator globalny

– odbiór wszystkich potwierdzeń od

uczestników

– zapis do logu informacji o

zakończeniu transakcji

Zdecentralizowany 2PC

Topologia komunikacyjna

Topologia komunikacyjna

Zdecentralizowany 2PC

Cechy

Cechy

• większy ruch sieciowy (większa liczba

przesyłanych komunikatów)

• każdy węzeł zna decyzje pozostałych węzłów i

na tej podstawie sam

zatwierdza/wycofuje

faza decyzji nie jest konieczna

Zdecentralizowany 2PC

Cechy

Cechy

• większy ruch sieciowy (większa liczba

przesyłanych komunikatów)

• każdy węzeł zna decyzje pozostałych węzłów i

na tej podstawie sam

zatwierdza/wycofuje

faza decyzji nie jest konieczna

Liniowy 2PC

Koncepcja

Koncepcja

– węzły są uporządkowane liniowo
– każdy węzeł otrzymuje numer od 1 (KG) do n

(U)

– węzeł o numerze i komunikuje się tylko z

węzłami

sąsiednimi, tj. o numerach i-1, i+1

Liniowy 2PC

Koncepcja

Koncepcja

– węzły są uporządkowane liniowo
– każdy węzeł otrzymuje numer od 1 (KG) do n

(U)

– węzeł o numerze i komunikuje się tylko z

węzłami

sąsiednimi, tj. o numerach i-1, i+1

Liniowy 2PC

Liniowy 2PC

Faza przygotowania

Faza przygotowania

• komunikaty wysyłane od węzła 1 do n
• podejmuje decyzję, wysyła swoją decyzję z

komunikatem do węzła o numerze i+1

• węzeł o numerze i+1 podejmuje swoją decyzję i

załącza ją w komunikacie do węzła i+2, itd.

• ostatni węzeł w łańcuchu podejmuje decyzję o

zatwierdzeniu/wycofaniu na podstawie zawartości
komunikatu od węzła n-1

komunikat ten zawiera decyzje wszystkich

komunikat ten zawiera decyzje wszystkich

wcześniejszych węzłów

wcześniejszych węzłów

Liniowy 2PC

Liniowy 2PC

Faza decyzji

Faza decyzji

• komunikaty wysyłane od węzła n do 1
• węzeł i podejmuje decyzję o

zatwierdzeniu/wycofaniu
i załącza ją w komunikacie do węzła i-1

• komunikat trafiający do KG zawiera decyzje

wszystkich węzłów

Graf wywołań transakcji

BANK1

koordynator globalny
COMMIT_POINT STRENGTH=15

BANK3

BANK2

koordynator lokalny

COMMIT_POINT_STRENGTH=2

0

update

rachunki@bank2 ....

update rachunki@bank3

węzeł zatwierdzania

COMMIT_POINT_STRENGTH=10

0

delete from

rachunki@bank4

...

update rachunki...

insert
innsurachunki@bank5 ...

BANK5

BANK4

uczestnik

COMMIT POINT

STRENGTH=1

uczestnik

COMMIT POINT

STRENGTH=1

Protokół zatwierdzania

Protokół zatwierdzania

Fazy realizacji

1.przygotowanie (prepare)
2.zatwierdzanie (commit)
3.zakończenie (forget)

2PC - faza przygotowania (KG)

1. KG wybiera węzeł zatwierdzania
2. KG wysyła do uczestników żądanie

przygotowania do zatwierdzania (uwaga:
komunikat ten nie jest wysyłany do WZ)

3. Uczestnik przygotowuje się i wysyła komunikat

PREPARED do KG

4. KG odbiera komunikaty od uczestników

2PC - faza przygotowania (U)

1. Odbiór komunikatu od KG żądającego

przygotowania do zatwierdzania

2. Zapis do plików dziennika powtórzeń
3. Wysłanie komunikatu PREPARE do podległych

uczestnikowi węzłów

4. Odbiór komunikatów od węzłów podległych
5. Wysłanie komunikatu do koordynatora

globalnego

2PC - faza przygotowania (U)

1. W przypadku braku modyfikacji danych ->

wysłanie do koordynatora globalnego komunikatu
READ-ONLY

2. Jeśli inne zdalne węzły podległe danemu węzłowi

uczestnika zgłosiły gotowość i sam uczestnik jest
gotów -> wysłanie komunikatu PREPARED do
koordynatora globalnego

w przeciwnym przypadku

w przeciwnym przypadku

1. wycofanie lokalnej transakcji
2. wysłanie ABORT

Wymiana komunikatów fazy

Wymiana komunikatów fazy

przygotowania

przygotowania

BANK1

koordynator globalny

BANK3

BANK2

koordynator

lokalny

1. Wybór WZ

1. Wybór WZ

2. prepare

2. prepare

węzeł

zatwierdzani

a

BANK5

BANK4

uczestnik

uczestnik

5. prepared

5. prepared

3. prepare

3. prepare

3. prepare

3. prepare

4. prepared

4. prepared

4. prepared

4. prepared

2PC – faza zatwierdzania (zatwierdzenie)

1. KG odbiera potwierdzenia od uczestników

–

PREPARED

–

READ-ONLY (brak modyfikacji)

–

ABORT (niemożliwość przygotowania do
zatwierdzania)

2. Jeśli wszyscy odpowiedzieli PREPARED -> KG wysyła

żądanie zatwierdzenia transakcji do węzła
zatwierdzania

3. WZ zatwierdza transakcję i wysyła komunikat do KG
4. KG wysyła żądanie zatwierdzenia do pozostałych

węzłów

2PC – faza zatwierdzania (uczestnik)

1. Odbiór od koordynatora globalnego

komunikatu żądającego zatwierdzenia
transakcji

2. Zatwierdzenie lokalnej transakcji
3. Zwolnienie blokad
4. Zapis informacji o zatwierdzeniu w pliku

dziennika powtórzeń

Wymiana komunikatów fazy

Wymiana komunikatów fazy

zatwierdzania

zatwierdzania

BANK1

koordynator globalny

BANK3

BANK2

koordynator

lokalny

1. commit

1. commit

3. commit

3. commit

węzeł

zatwierdzani

a

BANK5

BANK4

uczestnik

uczestnik

2.

2.

committed

committed

4. commit

4. commit

4. commit

4. commit

5.

5.

committed

committed

5. commmitted

5. commmitted

6.

6.

commmitted

commmitted

2PC – faza zakończenia

1. Usunięcie z systemu informacji o zakończonej

transakcji rozproszonej

2. Zwolnienie wszystkich niezwolnionych jeszcze

zasobów systemowych