• Nie Znaleziono Wyników

Systemy zarządzania bazami danych

N/A
N/A
Protected

Academic year: 2021

Share "Systemy zarządzania bazami danych"

Copied!
42
0
0

Pełen tekst

(1)

Systemy zarządzania bazami danych

11. Strojenie zamków

(2)

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ą?

(3)

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ą

(4)

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

(5)

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

(6)

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

(7)

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.

(8)

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

(9)

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.

(10)

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

(11)

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

(12)

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

(13)

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

(14)

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)

(15)

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

?

(16)

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.

(17)

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}

(18)

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

(19)

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

(20)

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

(21)

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

(22)

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

(23)

Oryginał: Shasha & Bonnet 11. Strojenie zamków 23

T

1

: Wstaw <99,Gimel,…> do R T

2

: Wstaw <99,Dalet,…> do R

T

1

T

2

S

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,..]

... ...

(24)

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

(25)

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

(26)

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.

(27)

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;

(28)

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

(29)

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

(30)

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

(31)

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

(32)

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

(33)

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

(34)

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

(35)

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);

(36)

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

(37)

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

(38)

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)

(39)

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

(40)

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);

(41)

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

(42)

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

Cytaty

Powiązane dokumenty

SELECT /*+ REWRITE(s) */ t.calendar_month, sum(s.amount_sold) AS dollars FROM sales s, times t.. WHERE s.time_id

(2) Zanim zmieniony x znajdzie się na dysku, wszystkie wpisy dotyczące transakcji, która zmodyfikowała x muszą trafić na dysk. (3) Przy commit , zrzuć dziennik na dysk ( flush

(4) Ti może założyć zamek X,SIX,IX na węzeł Q tylko wtedy, gdy rodzic(Q) ma zamek IX lub SIX założony przez transakcję Ti. (5) Ti zakłada

• Otwarcie połączenia z bazą danych jest drogie, ale wielokrotne użycie tanie. – Używaj

– Zapis do pamięci podręcznej: transfer kończy się, gdy dane znajdą się w pamięci podręcznej sterownika. • Baterie gwarantują zapis przy

• Punkt kontrolny (częściowy zrzut brudnych strona na dysk) odbywa się w stałych odstępach lub po zapełnieniu dziennika:. – Wpływa na wydajność bazy + Pozwala

– Jeśli często odczytuje się adres dostawcy na podstawie numeru zamówionej części, to schemat 1 jest dobry.. – Jeśli jest wiele dodawanych wiele zamówień, schemat 1

• Indeks niepogrupowany jest dobry, gdy używające go zapytania zwracają znacznie mniej rekordów niż jest stron w tabeli. •