Systemy zarządzania bazami danych
13. Strojenie dziennika
Atomowość i trwałość
• Każda transakcja kończy się wycofaniem lub
zatwierdzeniem. Nie może zmienić zdania
• Nawet po awarii:
– Wyniki zatwierdzonych transakcji muszą być trwałe – Wyniki wycofanych
transakcji muszą całkowicie zniknąć
AKTYWNA
(działa, czeka)
WYCOFANA ZATWIERDZONA
COMMIT
ROLLBACK
Ø BEGIN
Awarie, przestoje
• Środowiskowe
– Pożar w serwerowni (Credit Lyonnais, 1996)
• Operacyjne
– Problemy przy rutynowej administracji systemu, konfiguracji, eksploatacji
• Pielęgnacyjne
– Problemy w czasie naprawy i konserwacji systemu
• Sprzętowe
– Usterka fizyczna w urządzeniu:
procesor, pamięć, dysk, karta sieciowa
• Programowe
– 99% to „błędy Heisenberga”
• błędy, który wymykają się próbom wyizolowania warunków ich
występowania,
• nie występują lub zmieniają swoje zachowanie w trakcie próby
powtórzenia w tych samych warunkach
• zwykle związane z synchronizacją lub przeciążeniem
• nie widać ich śladów po restarcie systemu
Przestoje – częstości
• System tolerujący awarie musi być zabezpieczony na wszystkie rodzaje awarii
• Problemem jest oprogramowanie
– Awarie sprzętu powodują poniżej 10% przestojów
– Błędy Heisenberga zatrzymują system, ale nie niszczą danych
• SZBD chronią integralność danych przy pojedynczych awariach sprzętu i niektórych awariach oprogramowania
Software Hardware Maintenance Operations Environment Unknown
From J.Gray and A.Reuters Transaction Processing: Concepts and Techniques
Architektura SZBD
Sprzęt
[ Procesor(y), Dysk(i), Pamięć ] System operacyjny
Kontrola
współbieżności Odtwarzanie
Podsystem składu
Menedżer buforów
Obsługa buforów bazy danych
Zapis
synchroniczny
Zapis
asynchroniczny
Brak
wymiany ramek
Wymian a
ramek
Banał
Pożą- dane
• Force/No force + Steal/No steal
Obsługa buforów – rozwiązania
Zapis
synchroniczny
Zapis
asynchroniczny
Brak
wymiany ramek
Wymian a
ramek
Banał
Undo redo Undo
Redo
• Undo – dziennik wycofań
• Redo – dziennik powtórzeń
Prowadzenie dziennika
• Dziennik zawiera informację do powtórzeń (redo) i wycofań (undo)
– Sekwencyjne zapisy do dziennika (umieść go a oddzielnym dysku).
– Minimalizacja informacji zapisywanych do dziennika, żeby wiele modyfikacji zmieściło się na jednej stronie
• Dziennik: Uporządkowana lista akcji REDO/UNDO
– Wpis do dziennika zawiera:
• (IDTrans, IDStrony, offset, długość, stare dane, nowe dane) – Dodatkowe informacje sterujące
Obecny stan bazy danych = obecny stan danych na dysku + dziennik
Zapis wyprzedzający (WAL)
• WAL = Write-Ahead Logging
• Protokół zapisu wyprzedzającego
Wymusza zrzut wpisu dziennika na dysk przed zapisem odpowiedniej strony na dysk
Gwarantuje atomowość
Wymusza zrzut wpisów dziennika z transakcji, zanim zakończy się jej zatwierdzenie
Gwarantuje trwałość
• Algorytm ARIES opracowany przez C.Mohan w IBM Almaden na początku lat 90-tych XX wieku
– http://www.almaden.ibm.com/u/mohan/ARIES_Impact.htm
DZIEN-
NIK DANE DANE DANE
SKŁADOWISKO TRWAŁE SKŁADOWISKO NIETRWAŁE
ZRZUĆ
wpisy dziennika przez COMMIT
ZAPISZ
Zmodyfikowane strony przed/po COMMIT
ODTWARZANIE
Si Sj
BUFOR BAZY DANYCH
BUFOR
DZIENNIKA wi wj
Dzienniki w SQL Server 2000
Wolny bufor dziennika
Zapełniony bufor dz.
Bieżący bufor dz.
Zapełniony bufor dz.
Pisarz gorliwy
Kolejka do zrzutu
Procesy czekające
DZIEN-
NIK DANE
wolne
Si
wolneSj
Wpis dziennika:
- LSN (zegar logiczny)
- obraz fizyczny przed lub po, albo operacje logiczne
Pisarz leniwy
Synchroniczne I/O Asynchroniczne I/O
DB2 UDB v7 ma podobnie
BUFOR BAZY DANYCH
Dzienniki Oracle 8i
Segmenty wycofań (stały rozmiar)
Obraz po (wpisy REDO)
Bufor dziennika (domyślnie 32 KB)
Si Sj
Lista wolnych
BUFOR BAZY DANYCH
DZIENNIK DANE
Segmenty wycofań
Plik
#1 Plik
#2
LGWR (pisarz dziennika)
DBWR (pisarz bazy danych)
Obrazy przed
Dziennik na oddzielnym dysku
• Zapisy do dziennika są sekwencyjne (szczególny profil dostępu)
• Zapisy na dysk są (co najmniej) 100 razy szybsze, gdy są sekwencyjne, niż gdy są losowe
Dysk z dziennikiem nie powinien zawierać nic innego
+ sekwencyjne I/O
+ awaria nośnika dziennika niezależna od nośnika bazy danych
Dziennik oddzielnie – eksperymenty
• 300 000 transakcji. Każda ma instrukcję INSERT.
– DB2 UDB v7.1
• 5 % większa wydajność gdy dziennik jest na
oddzielnym dysku
• Pamięć podręczna
sterownika trochę tłumi negatywny wpływ
– Średniej klasy serwer, z kontrolerem Adaptec RAID (80Mb RAM) i dwoma dyskami 18GB
0 50 100 150 200 250 300 350
controller cache no controller cache Throughput (tuples/sec) Log on same disk
Log on separate disk
Grupowe zatwierdzenia
• 300 000 transakcji. Każda zawiera zdanie INSERT.
– DB2 UDB v7.1
• Wpisy dziennika różnych transakcji są zapisywane razem
– Zwiększa przepustowość poprzez obniżenie liczby zapisów
– Kosztem jest za to większy średni czas oczekiwania
0 50 100 150 200 250 300 350
1 25
Size of Group Commit
Throughput (tuples/sec)
Strojenie zapisów bazy danych
• Brudne dane są zapisywane na dysk, gdy
– liczba brudnych stron przekroczy wartość graniczną (np. parametr w Oracle8)
– odsetek brudnych stron przekroczy wartość graniczną (np. 3% wolnych buforów w SQL Server 7)
– Wykonywany jest punkt kontrolny
• w regularnych odstępach czasu
• gdy dziennik jest pełny (Oracle 8).
Strojenie odstępów punktów kontrolnych
• 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 obciąć dziennik + Zmniejsza czas odtwarzania
• 300 000 transakcji. Każda ma polecenie INSERT.
– Oracle 8i na Windows 2000
0 0.2 0.4 0.6 0.8 1 1.2
0 checkpoint 4 checkpoints
Throughput Ratio
Zmniejsz rozmiar długich transakcji modyfikujących
• Wsadowa transakcja z dużą liczbą modyfikacji (dostęp współbieżny nie jest problemem):
Lepiej ją podzielić na mniejsze:
+ Łatwiejsze odtwarzanie
+ Nie przepełni bufora dziennika
• Przykład: Transakcja, która w określonym porządku przetwarza i modyfikuje konta, na których były zmiany danego dnia
• Podziela ją na mniejsze wsady po 10000 kont i dodaj licznik, żeby pamiętać, co już jest zrobione
