Egzamin

Rozproszone Systemy Transakcyjne

24.06.2003
1. (10pkt) Dane są trzy stanowiska S1, S2, S3. Załóżmy, że stanowisko S1 jest
koordynatorem procesu akceptacji transakcji rozproszonej T, natomiast S2 i S3 są
uczestnikami procesu akceptacji.
• Załóżmy, że proces akceptacji transakcji T jest realizowany zgodnie z algorytmem
2PC. W jakim przypadku wystąpi efekt zablokowania procesu akceptacji transakcji T?
Podaj przykładowy scenariusz, który może doprowadzić do zablokowania akceptacji
transakcji T (sekwencja komunikatów i zdarzeń).
• Pokaż, w jaki sposób algorytm akceptacji 3PC pozwoli na zakończenie transakcji T, w
sytuacji, w której algorytm 2PC prowadzi do zablokowania akceptacji transakcji.
Podaj przykładowy scenariusz protokołu zakończenia (sekwencja komunikatów i
zdarzeń).

Odpowiedź:
Blokowanie w 2PC
Przyjmijmy sekwencję komunikatów:
1) koordynator S1 rozsyła komunikat <prepare>
2) S2 i S3 odsyłają <ready> i wchodzą w stan pre-commited
3) koordynator podejmuje decyzję commit, ale przed awarią zdążył wysłać commit tylko
do S2
4) awaria – pada koordynator S1 oraz stacja S2
BLOKADA – S3 nie ma możliwości sprawdzenia jaką decyzję podjął koordynator, ani
czy stacja S2 wykonała commit, czy abort, czy jeszcze nic – S3 MUSI CZEKAĆ, aż S2
się podniesie
Rozwiązanie w 3PC
1) koordynator S1 rozsyła <prepare>
2) odbiera od wszystkiech (S2 i S3) <yes>
3) próbuje rozesłać <pre-commit>
4) awaria – pada koordynator oraz S2
Stacja S3 po zorientowaniu się, że tylko ona przetrwała awarię może samodzielnie podjąć
decyzję o zatwierdzeniu/wycofaniu transakcji:
• Jeśli S3 otrzymała komunikat <pre-commit>, to wie, że wszystkie stacje są gotowe do
commit (zagłosowały <yes>) więc można podjąć decyzję o commice, gdy stacja S2
się podniesie będzie mogła dowiedzieć się o commicie i dokończyć transakcję – ale
nie ma blokowania - S3 nie musi czekać na S2.
• Jeśli S3 nie otrzymała <pre-commit> może podjąć decyzję abort, ma pewność, że nikt
nie wykonał commita, ponieważ S3 nie wysłała <ACK>, gdy S2 się podniesie będzie
mogła wycofać u siebie transakcję.

2. (10pkt) System rozproszony składa się z dwóch lokalnych baz danych D1={a, b} i
D2={c, d, e}.
(A) Dana jest realizacja rozproszona S={s1, s2} transakcji globalnych T1 i T2 i
transakcji lokalnej T3 następującej postaci:

s1: r1(a) w1(b) r2(b) w2(a)

s2: r3(c) w1(c) w2(d) r3(d)

Czy powyższa realizacja jest globalnie konfliktowo-uszeregowalna? Jeżeli nie, to

czy realizacja S jest quasi-uszeregowalna? Uzasadnij odpowiedź.

Odpowiedź:
T1 T2

T3
Nie, realizacja nie jest globalnie konfliktowo-uszeregowalna – jest cykl w
globalnym grafie uszeregowania
Tak, realizacja jest quasi-uszeregowalna – na obu stanowiskach operacje T1 są w
całości wykonywane przed T2

(B) Dana jest realizacja rozproszona S’={s1’, s2’} transakcji globalnych T1 i T2 i

transakcji lokalnej T3 następującej postaci:

s1’: r1(a) w1(b) r2(b) w2(a)

s2’: r3(c) w1(c) w1(d) r3(d)

Czy powyższa realizacja jest globalnie konfliktowo-uszeregowalna? Jeżeli nie, to

czy realizacja S jest quasi-uszeregowalna? Uzasadnij odpowiedź.

Odpowiedź:
T1 T2

T3
Tak, realizacja jest globalnie konfliktowo-uszeregowalna – brak cyku w
globalnym grafie uszeregowania
Tak, realizacja jest quasi-uszeregowalna – ponieważ jest konfliktowo-
uszeregowalna

(C) Dana jest realizacja rozproszona S’’={s1’’, s2’’} transakcji globalnych T1 i T2

i transakcji lokalnej T3 następującej postaci:

s1’’: r1(a) w1(b) r2(b) w2(a)

s2’’: r2(c) w3(c) w3(d) r1(d)

Czy powyższa realizacja jest globalnie konfliktowo-uszeregowalna? Jeżeli nie, to

czy realizacja S jest quasi-uszeregowalna? Uzasadnij odpowiedź.

Odpowiedź:
T1 T2

T3
 Nie, realizacja nie jest globalnie konfliktowo-uszeregowalna – jest cykl w
globalnym grafie uszeregowania
Ten moment jest najbardziej kontrowersyjny, po dyskusji z prof. Morzym
ustalono: Tak, realizacja jest quasi-uszeregowalna – istnieje taka realizacja
konfliktowo równoważna realizacji s2’’, że na obu stanowiskach operacje T1 są w
całości wykonywane przed T2.
Przykład takiej realizacji:
w3(d) r1(d) r2(c) w3(c)

3. (10pkt) Dany jest następujący graf WFG (waits-for graph) dla transakcji
rozproszonych T1 do T6 na serwerach A, B i C.

Serwer A
T1 T2 T3

T1 T5 T5 T3

T6 T6 T4

Serwer C Serwer B

Załóżmy, że transakcja T1, na serwerze A, zażądała założenia niekompatybilnej blokady

danej, która jest aktualnie blokowana przez transakcję T2. (żądanie to zaznaczono na
rysunku grubą kreską). Zasymuluj działanie algorytmu Path Pushing odkrywania
rozproszonego zakleszczenia w tym momencie i podaj wynikową sekwencję
komunikatów. Na którym ze stanowisk nastąpi wykrycie zakleszczenia?

Odpowiedź:
Zgodnie z algorytmem każdy serwer mający ścieżkę oczekiwań od transakcji Ti do
transakcji Tj (do Ti krawędzie wchodzą, z Tj wychodzą) wysyła wzdłuż wychodzących z
serwera krawędzi całą znaną mu ścieżkę oczekiwań , jeżeli Ti<Tj.
Po otrzymaniu takiej ścieżki, serwer „dokleja” ją do ścieżki, którą już miał i tak
powiększoną ścieżkę ponownie wysyła wzdłuż wychodzących z niego krawędzi jeśli
Ti<Tj.

Sekwencja komunikatów:
Serwer A wysyła wzdłuż wychodzącej z niego krawędzi (czyli do serwera B) całą znaną
sobie ścieżkę oczekiwań, gdyż T1<T3.
Komunikat od serwera A do B wygląda następująco:

T1 T2 T3
W tym samym czasie serwer B, dla którego również spełniony jest warunek Ti<Tj , gdyż
T3<T5 i T3<T6 wysyła komunikat do serwera C. W chwili wysłania komunikatu do
serwera C serwer B nie dysponuje jeszcze informacją otrzymaną od serwera A. Serwer B
wysyła do serwera C komunikat w postaci:

T3 T4 T5

T6

W tym samym czasie serwer C nie wysyła żadnego komunikatu do serwera A, gdyż na
serwerze C nie jest spełniony warunek Ti<Tj (T5>T1).

W następnym etapie serwer B odbiera komunikat od serwera A, a serwer C od serwera B.

Odebranie komunikatu powoduje doklejenie otrzymanej ścieżki do ścieżki posiadanej już
przez serwer i wysłanie nowej ścieżki wzdłuż krawędzi wychodzącej z serwera jeśli tylko
spełniony jest warunek, że Ti<Tj .
Warunek Ti<Tj spełniony jest tylko na serwerze B (T1<T5 i T1<T6), na serwerze C
warunek nie jest spełniony, gdyż T3>T1.Zatem tylko serwer B przesyła dalej (do
serweraC ) komunikat z całą (sklejoną) ścieżką:

T1 T2 T3 T4 T5

T6

Po otrzymaniu i doklejeniu do swojego grafu tego komunikatu od B serwer C widzi cykl:

T2 T3 T4 T5

T6

T1

Na serwerze C następuje wykrycie zakleszczenia.

4. (10pkt) Dany jest następujący graf zapytania:

Supply

SNUM=SNUM DPNUM=DPNUM

Supplier Dept
 Przyjmij następujący profil bazy danych.

Supplier
Card=200, site=1
SNUM Name
Size 4 20
Val 200 200

Supply
Card=5000, site=2
SNUM DPNUM
Size 4 2
Val 1000 100

Dept
Card=20, site=3
DPNUM Name
Size 2 3
Val 20 5

Założenia:
• Wszystkie wartości SNUM relacji Supplier należą do zbioru SNUM relacji Supply
• Wszystkie wartości DPNUM relacji Dept należą do zbioru DPNUM relacji Supply
• C0=0, C1=1, i.e. C(X)=X

Zadanie:
• Zaproponuj sekwencję operacji półpołączenia, która maksymalnie, Twoim zdaniem,
zredukuje relacje uczestniczące w zapytaniu
• Na jakim stanowisku należy wykonać ostateczną operację połączenia zredukowanych
relacji. Uzasadnij odpowiedź.

Odpowiedź:
Należy zastosować algorytm o nazwie SDD1(?), którego nie ma na slajdach. Algorytm
w każdym kroku analizuje wszystkie możliwe operacje półpołączenia i wybiera tę, która daje
największy zysk. Algorytm działa tak długo jak którykolwiek zysk > koszt. Zysk i koszt
oblicza się następująco - przykład dla relacji R i S, które są na różnych site-ach i dla
semijoina R’ = R SJA=B S:
Zysk mówi o tym, o ile zmniejszyła się relacja R, gdy zrobiono semijoina R’ = R SJA=B S,
czyli zysk = size(R)*card(R) - size(R’)*card(R’) bajtów. Pytanie jak obliczyć card(R’).
Zgodnie ze slajdem 18 z Query Optimization oblicza się najpierw współczynnik
p = val(B[S]/val(dom[A]) !!!! (Uwaga - BŁĄD NA SLAJDZIE), a następnie
card(R’) = p * card(R). Ponieważ size(R) = size(R’) ostateczny wzór na zysk jest następujący:
zysk = (1-p) * card(R) * size(R) bajtów
Wartość val(dom[A]) to liczba różnych wartości dziedziny atrybutu A (a więc również
B), czyli np. jeżeli atrybuty A i B są nazwami miast, to val(dom[A]) jest liczbą wszystkich
miast jakie występują lub mogą wystąpić w relacjach R i S. Chodzi o to, że pewne miasta
mogą występować wyłącznie w relacji R, a inne wyłącznie w relacji S, czyli
val(dom[A])>=max(val(A),val(B))
 Koszt jest związany z koniecznością przesłania wszystkich wartości atrybutu
połączeniowego B od site-a z relacją S do site-a z relacją R, czyli koszt = val(B)*size(B)
bajtów

a) Zaczynamy i liczymy koszty i zyski dla wszystkich możliwych semijoinów:

Operacja Koszt (w Zysk (w bajtach) p
bajtach)
Supply SJDPNUM=DPNUM Dept 2*20 = 40 4/5*5000*6=24000 1/5
Dept SJDPNUM=DPNUM Supply 2*100 = 200 0 1
Supply SJSNUM=SNUM Supplier 4*200 = 800 4/5*5000*6 = 24000 1/5
Supplier SJSNUM=SNUM Supply 4*1000 = 4000 0 1

Przykładowo wytłumaczenie dla pierwszego wiersza:

Żeby wykonać semijoina trzeba wysłać z site-a 3 (ten z relacją Dept) 20 różnych wartości
atrybutu DPNUM, każda z nich ma 2 bajty, razem koszt = 40 bajtów.
Obliczenie wartości p = val(DPNUM[Dept])/val(dom[DPNUM]) = 20 / 100 = 1/5
To jest kluczowe miejsce !!!. Dlaczego mogliśmy uznać że liczba różnych wartości
w dziedzinie DPNUM = 100? Ponieważ drugie założenie zadania mówi, że wszystkie
wartości DPNUM relacji Dept należą do zbioru DPNUM relacji Supply, czyli, że w relacji
Dept nie ma ani jednej wartości Dept, której by nie było w Supply. Możemy więc przyjąć, że
val(dom[DPNUM]) = 100, bo tyle jest różnych wartości tego atrybutu w Supply i Dept razem
wziętych.
Zysk jest obliczony z użyciem współczynnika p, w relacji Supply’ powstałej w wyniku
semijoina będzie 1000 rekordów (p*5000), a więc naszym zyskiem jest 4000 rekordów *
rozmiar jednej krotki, czyli 4000 * 6 = 24000 bajty.

Wybieram pierwszy wiersz jako najbardziej korzystny. W zasadzie to nie wiem, czy
należy wybierać semijoina o największym zysku, czy największej różnicy między zyskiem,
a kosztem, ale że dwa semijoin-y mają równy zysk, a jeden ma mniejszy koszt, to tego
wybieram.
„Parametry” powstałej relacji Supply’ są następujące:
Supply’
Card=1000, site=2
SNUM DPNUM
Size 4 2
Val 666 20
Wartości Size przy semijoinie sie nie zmieniają (patrz slajd 19).
Wartości Val zmieniają się zgodnie ze slajdem 19:
- jeżeli atrybut należał do semijoina to liczba różnych wartości jest uzyskiwana przez
pomnożenie przez p, czyli val(DPNUM[Supply’]) = p * val(DPNUM[Supply]) =1/5*100= 20
- jeżeli atrybut nie należy do semijoina to liczba różnych wartości jest uzyskiwana przez
formułę Yao (slajd 9), w naszym przypadku dla atrybutu SNUM z parametrami
następującymi n = card(Supply) = 5000, m = val(SNUM[Supply]) = 1000,
r = card(Supply’) = 1000
 r, je¿eli r < m / 2

val(SNUM[Supply’]) = (r + m) / 3, je¿eli m / 2 ≤ r ≤ 2m
 m, je¿eli r ≥ 2m

W naszym przypadku zachodzi przypadek środkowy czyli
val(SNUM[Supply’]) = (1000 + 1000) / 3 = 666
 b) Następny etap półpołączeń
Operacja Koszt (w Zysk (w bajtach) p
bajtach)
Dept SJDPNUM=DPNUM Supply’ 2*20 = 40 0 1
Supply’ SJSNUM=SNUM Supplier 4*200 = 800 4/5*5000*6 = 24000 1/5
Supplier SJSNUM=SNUM Supply’ 4*666 = 2666 2/3 * 200 * 24 = 3200 2/3

Wymaga komentarza wartość p w drugim i trzecim wierszu:

Kluczem do zrozumienia kruczka Morzego jest to, że val(dom[SNUM]) jest nadal równe
1000. Po zmniejszeniu liczby różnych wartości atrybutu SNUM w relacji Supply do 666 nie
mamy już pewności, że wszystkie wartości SNUM z Supplier należą do zbioru SNUM z
Supply’ (tak jakby to wynikało z założenia). Mogą się zdarzyć takie wartości SNUM w
Supplier, które już nie występują w Supply’. Innymi słowy zbiory wartości atrybutu SNUM
relacji Supply’ i Supplier mają część wspólną, ale mają też takie wartości SNUM, które
występują tylko w jednej relacji. Założenie zadania, że SNUM[Supplier] ⊂ SNUM[Supply]
nie jest prawdziwe w przypadku zredukowanej relacji Supply, czyli
SNUM[Supplier] ⊄ SNUM[Supply’]. Mogło się zdarzyć, że redukcja relacji Supply do
Supply’ wycięła takie wartości SNUM, które występowały w relacji Supplier. Na chłopski
rozum wartość p powinna być mniejsza od 1 zarówno wierszu 2 i 3, bo wysłanie listy
wartości SNUM z Supply’ do Supplier i z Supply’ do Supplier w obu przypadkach mogłoby
prowadzić do redukcji. Liczba różnych wartości atrybutu SNUM w obu relacjach nadal
wynosi więc 1000.
Na razie najkorzystniejszą operacją półpołączenia jest operacja w wierszu 2.

„Parametry” powstałej relacji Supply’’ są następujące:

Supply’’
Card=200, site=2
SNUM DPNUM
Size 4 2
Val 133 20

c) Następny etap
Operacja Koszt (w Zysk (w bajtach) p
bajtach)
Dept SJDPNUM=DPNUM Supply’’ 2*20 = 40 0 1
Supplier SJSNUM=SNUM Supply’’ 4*133 = 533 2/3 * 200 * 24 = 3200 2/3

Znowu komentarza wymaga wartość p = 2/3. Wartość val(dom[SNUM]) = 200. Dzieje się
tak dlatego, że po półpołączeniu Supply’’ = Supply’ SJSNUM=SNUM Supplier mamy pewność,
że w relacji Supply’’ nie ma już innych wartości atrybutu SNUM oprócz takich, które
występują również w Supplier. Zbiór wartość SNUM[Supply’’] ⊂ SNUM[Supplier], czyli
dziedzina wartości atrybutu Supplier składa się z 200 wartości.

Supplier’
Card=133, site=1
SNUM Name
Size 4 20
Val 133 111
 d) Następny etap
Operacja Koszt (w Zysk (w bajtach) p
bajtach)
Dept SJDPNUM=DPNUM Supply’’ 2*20 = 40 0 1

Redukcje nie przyniosą już zysku więc koniec półpołączeń.

Seria operacji półpołączeń jest następująca:
Supply SJDPNUM=DPNUM Dept →Supply’
Supply’ SJSNUM=SNUM Supplier →Supply’’
Supplier SJSNUM=SNUM Supply’’ →Supplier’

Ostateczna operacja połączenia powinna być wykonana na tej maszynie, na której jest
najwięcej danych uczestniczących w połączeniu.
Dla site-a 1 = card(Supplier’) * size(Supplier’) = 133 * 24
Dla site-a 2 = card(Supply’’) * size(Supply’’) = 200 * 6
Dla site-a 3 = card(Dept) * size(Dept) = 20 * 5
Jak widać operację połączenia wykonujemy na stanowisku 1.

5. (4pkt) W odpowiednie miejsca w poniższej tabeli wstaw odpowiedzi TAK lub NIE.

Twierdzenie Magazyny Danych Systemy Mediacyjne

Dane w źródłach są
NIE NIE
udostępniane do modyfikacji.
Istnieje (musi) warstwa
posiadająca wspólny model NIE TAK
danych.
Istnieją elementy systemu
TAK TAK
określane mianem wrapperów.
Dane pobierane ze źródeł są
magazynowane w jednym TAK NIE
miejscu.

6. (16pkt) System mediacyjny składa się z dwóch źródeł danych: X1 i X2.

Źródło X1 posiada następujące, przykłądowe dane:

<&z1, zespol, set, {&n1, &p1, &p2, &p3}>
<&n1, nazwam string, ‘Bazy Danych’>
<&p1, pracownik, set, {&a1, &s1}>
<&a1, nazwisko, string, ‘Ixsinski’>
<&s1, stanowisko, string, ‘profesor’>
<&p2, pracownik, set, {&a2, &s2}>
<&a1, nazwisko, string, ‘Ygrekowski’>
<&s1, stanowisko, string, ‘asystent’>
<&p3, pracownik, set, {&a3, &s3}>
<&a1, nazwisko, string, ‘Zetowski’>
<&s1, stanowisko, string, ‘student’>

Źródło X2 posiada następujące, przykładowe dane:

<&p1, pracownik, set, {&a1, &s1}>
<&a1, nazwisko, string, ‘Zetowski’>
 <&s1, email, string, ‘z@e.pl’>
<&p2, pracownik, set, {&a2, &s2}>
<&a1, nazwisko, string, ‘Ixsinski’>
<&s1, email, string, ‘i@e.pl’>
<&p3, pracownik, set, {&a3, &s3}>
<&a1, nazwisko, string, ‘Ygrekowski’>
<&s1, email, string, ‘y@e.pl’>

Mediator udostępnia następujący schemat globalny:

<’Zetowski’, pracownik, set, {&e1, &s1, &z1}>
<&e1, email, string, ‘z@e.pl’>
<&s1, stanowisko, string, ‘student’>
<&z1, zespol, string, ‘Bazy Danych’>
<’Ixsinski’, pracownik, set, {&e2, &s2, &z2}>
<&e2, email, string, ‘i@e.pl’>
<&s2, stanowisko, string, ‘profesor’>
<&z2, zespol, string, ‘Bazy Danych’>

część a)
Dla poniższego zapytania zdefiniuj proste reguły będące specyfikacją mediatora, które
pozwolą na jego (zapytania) realizację. Pokaż sposób transformacji zapytania przy
wykorzystaniu utworzonych przez Ciebie reguł. Przez proste reguły rozumiemy reguły
odnoszące się tylko do jednego źródła. Przez element identyfikujący (identyfikator
semantyczny) pracownika przyjmij jego nazwisko (N).

<N {<stanowisko S> <zespol Z> <email E>}>

AND Z = ‘Bazy Danych’

Odpowiedź:
Proste reguły:
1) <N{<stanowisko S><zespol Z>}>:-
<zespol{<nazwa Z><pracownik{<nazwisko N><stanowisko
S>}>}>@X1
2) <N{<email E>}>:-
<pracownik{<nazwisko N><email E>}>@X2

Transformacja zapytania:
<N {<stanowisko S> <zespol Z> <email E>}>:-
<N{<stanowisko S><zespol Z>}>
AND
<N{<email E>}>
AND
Z = ‘Bazy Danych’

Po podstawieniu ciał reguł:

<N {<stanowisko S> <zespol Z> <email E>}>:-
<zespol{<nazwa Z><pracownik{<nazwisko N><stanowisko
S>}>}>@X1
AND
<pracownik{<nazwisko N><email E>}>@X2
AND
 Z = ‘Bazy Danych’

część b)
Dokończ następujące reguły specyfikacji mediatora. Przez element identyfikujący
(identyfikator semantyczny) pracownika przyjmij jego nazwisko (N).

1) <N{<stanowisko S>}>:-<zespol{<pracownik{<nazwisko
N><stanowisko S>}>}>@X1

2) <N{<zespol Z>}>:-<zespol{<nazwa Z><pracownik{<nazwisko

N>}>}>@X1

3) <N{<zespol Z>}>:-....@X2 – w X2 nie ma danych o zespole!!

4) <N{<email E><zespol Z>}> :-

<zespol{<nazwa Z><pracownik{<nazwisko N>}>}>@X1
AND
<pracownik{<nazwisko N><email E>}>@X2

5) <N{<email E>}>:- <pracownik {<nazwisko N><email E>}>@X2

Odpowiedzi wpisane pogrubioną kursywą.