Systemy zarządzania bazami danych
11. Strojenie zamków
Strojenie trzewne
• Współbieżność
– Jak zminimalizować rywalizację o zamki?
• Odtwarzanie
– Jak przyspieszyć zapisy do dziennika (zrzuty)?
• System operacyjny
– Jak dobrać wielkość buforów, planowanie procesora...
• Sprzęt
– Jak przydzielić procesor, pamięć, przestrzeń dyskową?
Oryginał: Shasha & Bonnet 11. Strojenie zamków 3
Cele strojenia współbieżności
• Wydajność
– Redukcja zamków:
transakcja czeka, aż inna transakcja zwolni zamek
– Unikanie zakleszczeń:
transakcje wzajemnie czekają na zwolnienie zamków
• Poprawność
– Szeregowalność:
transakcja działa tal
jakby była izolowana od innych
– Programista ma
zapewnić, że wykonanie szeregowe jest
poprawne.
Kompromis między wydajnością i poprawnością
Idealna transakcja
• Potrzebuje niewielu zamków i woli dzielone od wyłącznych
– Redukuje liczbę konfliktów – są one wynikiem zamków dzielonych
• Żąda zamków o małej ziarnistości
– Redukuje zakres potencjalnych konfliktów
• Utrzymuje zamki przez krótki czas
– Redukuje czas oczekiwania
Oryginał: Shasha & Bonnet 11. Strojenie zamków 5
Strojenie zamków
• Podział transakcji
– Popraw aplikacje, żeby poprawić wydajność zamków
• Poziomy izolacji
– Zmniejsz poprawność by poprawić wydajność
• Narzuty powodowane przez zamki
– Nieunikniony koszt stosowania zamków
• Wąskie gardła
– Korzystanie z udogodnień systemowych, aby rozpychać wąskie gardła
Przykład: Zwykłe zakupy
• Kup towar I za cenę P
1. Jeśli gotówka < P, wycofaj transakcję 2. Magazyn(I) := Magazyn(I)+P
3. Gotówka := Gotówka – P
• Dwie transakcje zakupu P1 i P2
– W P1 towar I ma cenę 50 – W P2 towar I ma cenę 75 – Gotówki mamy 100
Oryginał: Shasha & Bonnet 11. Strojenie zamków 7
Zwykłe zakupy – analiza
• Jeśli 1-2-3 to jedna transakcja, P1 albo P2 musi być wycofana
• Jeśli 1-2-3 to trzy różne transakcje:
– P1 sprawdza, czy gotówka 50? Tak.
– P2 sprawdza, czy gotówka 75? Tak.
– P1 kończy. Gotówka = 50.
– P2 kończy. Gotówka = –25.
Zwykłe zakupy – rozwiązania
• Ortodoksyjne
– Cały program to jedna transakcja
• Sprawdzenie stanu gotówki staje się wąskim gardłem!
• Podziałowe
– Znajdź sposób na reorganizację i podziel transakcję tak, aby nie złamać
szeregowalności
Oryginał: Shasha & Bonnet 11. Strojenie zamków 9
Zwykłe zakupy – podział
• Podzielone:
1. Jeśli gotówka < P, wycofaj transakcję Gotówka := Gotówka – P
2. Magazyn(I) := Magazyn(I)+P
• Wykonanie podzielonych:
– P11: 100 > 50. Gotówka := 50.
– P21: 75 > 50. Wycofanie.
– P12: Magazyn(I) := Magazyn(I) + 50.
Dzielenie transakcji
• Reguły wykonawcze:
– Fragmenty są wykonywane według porzadku częściowego zdefiniowanego przez „dużą”
transakcję
– Jeśli fragment jest wycofywany z powodu konfliktu, jest ponawiany aż do skutku
(zatwierdzenia)
– Jeśli fragment jest wycofywany z powodu polecenia abort, żaden inny fragment nie zostanie już wykonany
Oryginał: Shasha & Bonnet 11. Strojenie zamków 11
Bezpieczeństwo wycofania
• Podział T jest bezpieczny ze względu na wycofania jeśli
1. T nie zawiera polecenia abort LUB
2. Wszystkie polecenia abort są w pierwszym fragmencie podziału
Poprawność podziału
• Graf podziału (jak graf kolejności transakcji):
– Wierzchołki to fragmenty
– Krawędzie K (konflikt): Między dwoma
fragmentami różnych transakcji jest krawędź K, wtw. działają na tym samym obiekcie i jedną z operacji jest zapis
– Krawędzie B (bliźniaki): Między dwoma
fragmentami tej samej transakcji jest krawędź B
• Cykl K-B to cykl złożony z co najmniej jednej krawędzi B i jednej K
Oryginał: Shasha & Bonnet 11. Strojenie zamków 13
Poprawność podziału: przykłady
• Podział jest poprawny gdy jest
bezpieczny ze względu na wycofania nie zawiera cyklu K-B
T1: r(x) w(x) r(y) w(y) T2: r(x) w(x)
T3: r(y) w(y) T1
T2 T3
T11: r(x) w(x) T12: r(y) w(y)
T11 T12
T3 T2
B
K K
T11: r(x) T12: w(x)
T13: r(y) w(y)
T12 T13
T3 T2
B
K K
T11 B
K
POPRAWNY
NIEPOPRAWNY
Przykład podziału
T1: RW(A) RW (B) T2: RW(D) RW(B) T3: RW(E) RW(C) T4: R(F)
T5: R(E)
T6: R(A) R(F) R(D) R(B) R(E) R(G) R(C)
Oryginał: Shasha & Bonnet 11. Strojenie zamków 15
Przykład podziału – graf
T1 T2
T4 T5
T3
T62 T61
T61: R(A) R(F) R(D) R(B) T62: R(E) R(G) R(C)
K K
K K
K
B
?
Podział lokalny
• Lokalny podział transakcji Ti, oznaczany
lokalny(Ti) to zbiór fragmentów {ci1, ci2, …, cik} takich, że:
– {ci1, ci2, …, cik} jest podziałem bezpiecznym ze względu na wycofanie
– Nie ma cykli K-B w grafie o wierzchołkach {T1, …, Ti-1, ci1, ci2, …, cik, Ti+1, … Tn}
• Podział złożony z {lokalny(T1), lokalny(T2),
…, lokalny(T2)} jest bezpieczny ze względu na wycofania i nie ma cykli K-B.
Oryginał: Shasha & Bonnet 11. Strojenie zamków 17
Najdokładniejszy podział
• Wejście: T, {T1, .. Tn-1}
• Inicjacja
– Jeśli są polecenia abort
• p1 := wszystkie zapisy T (i nieprzestawialne odczyty), które mogą nastąpić przed lub równolegle z dowolnym poleceniem abort w T
– W przeciwnym przypadku:
• p1 := pierwszy dostęp do bazy danych
– P := {x | x operacja na bazie danych spoza p1}
– P := P {p1}
Najdokładniejszy podział c.d.
• Scalanie fragmentów
– Znajdź spójne fragmenty grafu podziału tylko na podstawie cykli K transakcji {T1,
…, Tn-1} i fragmentów P.
– Popraw P korzystając z reguły:
• Jeśli p_j i p_k są w tej samej spójnej składowej oraz j < k, to
– Dodaj operacje p_k do p_j – Usuń p_k z P
Oryginał: Shasha & Bonnet 11. Strojenie zamków 19
Strojenie zamków
• Podział transakcji
– Popraw aplikacje, żeby poprawić wydajność zamków
• Poziomy izolacji
– Zmniejsz poprawność by poprawić wydajność
• Narzuty powodowane przez zamki
– Nieunikniony koszt stosowania zamków
• Wąskie gardła
– Korzystanie z udogodnień systemowych, aby rozpychać wąskie gardła
Poświęć izolację dla wydajności?
• Transakcja, która trzyma zamki w czasie interakcji ekranowej jest potencjalnym wąskim gardłem.
– Rezerwacje lotnicze
1. Pobierz listę wolnych miejsc 2. Ustal z klientem, co wybiera 3. Zarezerwuj miejsce
• Jedna transakcja 1-2-3 jest niedopuszczalna, bo będzie trzymała zamek na wszystkich wolnych miejscach
• Umieszczaj interakcję z użytkownikiem poza kontekstem transakcyjnym
• Problem: wybrane miejsce zostało już w międzyczasie
Oryginał: Shasha & Bonnet 11. Strojenie zamków 21
Poziomy izolacji
• Odczyt niezatwierdzony (Brak utraty modyfikacji)
– Zamki wyłączne blokują zapisy innych transakcji na czas transakcji piszącej
– Zamki do zapisu trzymane do zatwierdzenia. Brak zamków do odczytu
• Odczyt zatwierdzony (Brak brudnego odczytu)
– Zamki do zapisu trzymane do zatwierdzenia
– Zamki dzielone zwalniane natychmiast po zakończeniu odczytu
• Odczyt powtarzalny (Brak odczytu niepowtarzalnego)
– Ścisłe 2PL – zamki zapisowe i odczytowe trzymane do końca transakcji
• Szeregowalność (Brak fantomów)
– Zamki na całych tabelach lub na węzłach indeksów, żeby uniknąć fantomów
Przykład: relacja R (E#,nazwisko,…) więzy: E# to klucz
zamki zakładane na wierszach
R E# nazwisko….
o1 55 Alef
Problem fantomów
Oryginał: Shasha & Bonnet 11. Strojenie zamków 23
T
1: Wstaw <99,Gimel,…> do R T
2: Wstaw <99,Dalet,…> do R
T
1T
2S
1(o
1)
S
2(o
1) S
1(o
2)
S
2(o
2)
Sprawdź więzy Sprawdź więzy Wstaw o
3[99,Gimel,..]
Wstaw o
4[99,Dalet,..]
... ...
Rozwiązania problemu fantomów
• Zamki na tabelach
– Koniec problemów
– Koniec współbieżności
• Zamki na węzłach indeksu
– Zamykanie zakresowe (zamek na wartości klucza indeksu)
– Bardziej złożone
– Więcej współbieżności
Oryginał: Shasha & Bonnet 11. Strojenie zamków 25
Izolacja migawkowa
T1
T2
T3
CZAS
R(Y) zwraca 1
R(Z) zwraca 0 R(X) zwraca 0
W(Y:=1)
W(X:=2, Z:=3) X=Y=Z=0
• Każda transakcja działa na
obrazie danych zatwierdzonych do chwili jej rozpoczęcia:
– Nie ma zamków przy odczycie – Zamki przy zapisie
– Koszt pamięciowy (trzeba przechowywać stare wersje)
• Prawie szeregowalność:
– T1: x:=y – T2: y:= x
– Początkowo x=3 i y =17 – Wykonanie szeregowe:
x,y=17 or x,y=3
– Izolacja migawkowa:
x=17, y=3, jeśli obie transakcje zaczęły się w tej samej chwili
Cena szeregowalności – dane
Środowisko:
accounts( number, branchnum, balance);
create clustered index c on accounts(number);
– 100000 wierszy
– Pusty bufor; wielkosc bufor taka sama na wszystkich systemach – Zamki na wierszach
– Poziom izolacji (SERIALIZABLE lub READ COMMITTED) – SQL Server 7, DB2 v7.1 and Oracle 8i on Windows 2000
– Dual Xeon (550MHz,512Kb), 1Gb RAM, Internal RAID controller from Adaptec (80Mb), 4x18Gb drives (10000RPM), Windows 2000.
Oryginał: Shasha & Bonnet 11. Strojenie zamków 27
Cena szeregowalności – transakcje
• Współbieżne transakcje:
– T1: zapytanie sumujące [1 wątek]
select sum(balance) from accounts;
– T2: podmień salda dwóch kont (w takim porządku jak odczyty, by uniknąć zakleszczeń) [N watków]
valX:=select balance from accounts where number=X;
valY:=select balance from accounts where number=Y;
update accounts set balance=valX where number=Y;
update accounts set balance=valY where number=X;
Cena seregowalności – wyniki
• SQL Server i DB2
sumacja daje bledne wyniki na poziomie READ COMMITED
(domyslne ustawienie)
• Oracle zawsze daje poprawne wyniki
(izolacja migawkowa), ale uwaga na podmiany
Oracle
0 0.2 0.4 0.6 0.8 1
0 2 4 6 8 10
Ratio of correct answers read committed serializable
SQLServer
0 0.2 0.4 0.6 0.8 1
0 2 4 6 8 10
Concurrent update threads
Ratio of correct answers
read committed serializable
Oryginał: Shasha & Bonnet 11. Strojenie zamków 29
Cena seregowalności – wyniki
Modyfikacje są w
konflikcie z sumacją, więc poprawność
wyników uzyskuje się kosztem mniejszej
współbieżności, więc i
mniejszej przepustowości
Oracle
0 2 4 6 8 10
Concurrent Update Threads
Throughput (trans/sec)
read committed serializable
SQLServer
0 2 4 6 8 10
Concurrent Update Threads Throughput (trans/sec)
read committed serializable
Strojenie zamków
• Podział transakcji
– Popraw aplikacje, żeby poprawić wydajność zamków
• Poziomy izolacji
– Zmniejsz poprawność by poprawić wydajność
• Narzuty powodowane przez zamki
– Nieunikniony koszt stosowania zamków
• Wąskie gardła
– Korzystanie z udogodnień systemowych, aby rozpychać wąskie gardła
Oryginał: Shasha & Bonnet 11. Strojenie zamków 31
A
• Jeśli obiektu nie ma w tej tablicy haszującej, to jest niezamknięty
Informacja o zamkach na A
A
... ...
H
Tablica zamków
Zamki w SQL Server 7
syslockinfo
dbid objid ziarnistość tryb właściciel oczekujący
1 117 RID X 1 117 PAG IX
1 117 TAB IX 1 118 RID S
LO1 LO1 LO1
LO2, LO3 LW2 LW3
spid
10
10 10
10
Zamek – 32 bajty Właściciel zamka – 32 bajty
LW1, LW4
Oryginał: Shasha & Bonnet 11. Strojenie zamków 33
Zamki w Oracle 8i
Strona danych wiersz
Tablica zainteresowanych transakcji
(stała wielkość - INITRANS – MAXTRANS)
T1
Zamek T1
Struktura kolejki zamków
(stała tablica – domyślnie 4 pozycje na transakcję)
T1
Tablica kolejki zamków Zamek
T2
Oczekiwanie na kolejkę (limit ~ 3 sekundy)
Proces
Zamek T3
Wykrywanie zakleszczeń H
Narzuty zamków – dane
Środowisko:
accounts( number, branchnum, balance);
create clustered index c on accounts(number);
– 100000 wiersze – Stały bufor
– SQL Server 7, DB2 v7.1 and Oracle 8i on Windows 2000
– Brak promocji zamków w Oracle; Parametry DB2 ustawione, żeby nie było promocji zamków; brak takiej kontroli w SQL Server.
– Dual Xeon (550MHz,512Kb), 1Gb RAM, Internal
RAID controller from Adaptec (80Mb), 4x18Gb drives
Oryginał: Shasha & Bonnet 11. Strojenie zamków 35
Narzuty zamków – transakcje
Bez współbieżności:
– Modyfikacja [10 000 razy]
update accounts set balance = Val;
– Wstawienie [10 000 razy], np. takie typowe:
insert into accounts
values(664366,72255,2296.12);
0 0.2 0.4 0.6 0.8 1
update insert
Throughput ratio (row locking/table locking)
db2 sqlserver oracle
Narzuty zamków
• Zamki wierszowe są
trochę droższe niż zamki tabelowe ponieważ
narzuty związane z
odtwarzaniem są większe niż narzuty zamków
• Wyjątkiem są
modyfikacje w DB2 gdzie zamki tabelowe są
wyraźnie tańsze niż wierszowe
Oryginał: Shasha & Bonnet 11. Strojenie zamków 37
Strojenie zamków
• Podział transakcji
– Popraw aplikacje, żeby poprawić wydajność zamków
• Poziomy izolacji
– Zmniejsz poprawność by poprawić wydajność
• Narzuty powodowane przez zamki
– Nieunikniony koszt stosowania zamków
• Wąskie gardła
– Korzystanie z udogodnień systemowych, aby rozpychać wąskie gardła
Waskie gardło: generowane klucze
• Rozwazmy aplikację, w której korzystamy z generowanych kolejno wartości jako kluczy, np. numerów faktur
• Rozwiązanie naiwne: oddzielna tabela, która trzyma ostatni numer faktury. Każda
transakcja pobiera i modyfikuje ten wiersz
• Rozwiązanie licznikowe: uzyj udogodnienia systemowego takiego jak sekwencja (Oracle) lub kolumna autonumerowana (SQL Server)
Oryginał: Shasha & Bonnet 11. Strojenie zamków 39
Zatrzaski i zamki
• Zamki są używane do kontroli wspolbieznosci
– Żądania zamków są kolejkowane
• Kolejka priorytetowe
– Struktura tablicy zamków
• Tryb, obiekt, ziarnistość, id transakcji
• Zatrzaski sluzą do zapewnienia wzajemnego wykluczania
– Ządanie zatrzasku udaje się lub nie
• Aktywne czekanie na zatrzaski przy wielu procesorach
– Pojedyncze miejsce w pamieci
• Mechanizm Test&Set do obsługi zatrzaskow
Wartość liczników – dane
Środowisko:
– Domyślny poziom izolacji: READ COMMITTED; Puste tabele
– Dual Xeon (550MHz,512Kb), 1Gb RAM, Internal RAID controller from Adaptec (80Mb), 4x18Gb drives
accounts( number, branchnum, balance);
create clustered index c on accounts(number);
counter ( nextkey );
insert into counter values (1);
Oryginał: Shasha & Bonnet 11. Strojenie zamków 41
Wartość liczników – transakcje
Bez współbieżności:
– Udogodnienie systemowe [100 000 wstawień, N wątków]
• SQL Server 7 (kolumna Identity)
insert into accounts values (94496,2789);
• Oracle 8i (sekwencja)
insert into accounts values (seq.nextval,94496,2789);
– Rozwiązanie naiwen [100 000 wstawien, N wątków]
begin transaction
NextKey:=select nextkey from counter;
update counter set nextkey = NextKey+1;
commit transaction begin transaction
insert into accounts values(NextKey,?,?);
commit transaction
Unikaj wąskiego gardła – liczniki
• Liczniki oferowane przez SZBD o niebo lepsze od rozwiązań naiwnych
• Sekwencja Oracle może stać się waskim gardlem jeśli
kazde pobranie jest
zapisywane na dysk, ale można stosować CACHE sekwencji
CREATE SEQUENCE seq CACHE 20;
• Liczniki mogą gubic wartości
SQLServer
0 10 20 30 40 50
Number of concurrent insertion threads Throughput (statements/sec)
system ad-hoc
Oracle
hroughput tements/sec)
system ad-hoc