Systemy zarządzania bazami danych

1. Systemy zarządzania bazami danych 13. Strojenie dziennika

2. 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ąć Atomowośći trwałość ZATWIERDZONA COMMIT Ø AKTYWNA (działa, czeka) BEGIN WYCOFANA ROLLBACK 13. Strojenie dziennika

3. Ś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 Awarie, przestoje 13. Strojenie dziennika

4. 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 Przestoje – częstości From J.Gray and A.ReutersTransaction Processing: Conceptsand Techniques 13. Strojenie dziennika

5. Architektura SZBD Podsystem składu Kontrola współbieżności Odtwarzanie Menedżer buforów System operacyjny Sprzęt[ Procesor(y), Dysk(i), Pamięć ] 13. Strojenie dziennika

6. Obsługa buforów bazy danych Brak wymiany ramek • Force/No force + Steal/No steal Wymiana ramek Zapis synchroniczny Banał Zapis asynchroniczny Pożą- dane 13. Strojenie dziennika

7. Obsługa buforów – rozwiązania Brak wymiany ramek • Undo – dziennik wycofań • Redo – dziennik powtórzeń Wymiana ramek Zapis synchroniczny Banał Undo Zapis asynchroniczny Undo redo Redo 13. Strojenie dziennika

8. 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 13. Strojenie dziennika

9. 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 13. Strojenie dziennika

10. SKŁADOWISKO NIETRWAŁE BUFOR BAZY DANYCH BUFOR DZIENNIKA wi wj ZRZUĆwpisy dziennika przez COMMIT ZAPISZ Zmodyfikowane strony przed/po COMMIT DZIEN- NIK DANE DANE DANE ODTWARZANIE SKŁADOWISKO TRWAŁE 13. Strojenie dziennika

11. Dziennikiw SQL Server 2000 • Wpis dziennika: • LSN (zegar logiczny)- obraz fizyczny przed lub po, • albo operacje logiczne DB2 UDB v7 ma podobnie Wolny bufordziennika Bieżącybufor dz. Zapełniony bufor dz. BUFOR BAZY DANYCH Procesy czekające Pisarzgorliwy Zapełniony bufor dz. Pisarz leniwy Kolejka do zrzutu Synchroniczne I/O Asynchroniczne I/O DZIEN- NIK DANE 13. Strojenie dziennika

12. Dzienniki Oracle 8i Obrazy przed Lista wolnych Segmenty wycofań (stały rozmiar) Bufor dziennika (domyślnie 32 KB) BUFOR BAZY DANYCH Obraz po(wpisy REDO) LGWR(pisarz dziennika) DBWR(pisarz bazy danych) Segmenty wycofań DZIENNIK DANE Plik#1 Plik#2 13. Strojenie dziennika

13. 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 13. Strojenie dziennika

14. 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 Dziennik oddzielnie – eksperymenty 13. Strojenie dziennika

15. 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 Grupowe zatwierdzenia 13. Strojenie dziennika

16. 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). 13. Strojenie dziennika

17. 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 Strojenie odstępów punktów kontrolnych 13. Strojenie dziennika

18. 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 13. Strojenie dziennika