Systemy zarzdzania bazami danych 10 Strojenie Orygina Shasha

Systemy zarządzania bazami danych 10. Strojenie Oryginał: Shasha & Bonnet 10. Strojenie

Oryginał: Shasha & Bonnet 10. Strojenie 2

Strojenie bazy danych to działalność mająca na celu sprawienie, aby baza danych działała szybciej. “Szybciej” zwykle oznacza większą przepustowość, ale może też oznaczać krótszy czas reakcji aplikacji, w których jest on ważny. Oryginał: Shasha & Bonnet 10. Strojenie 3

Programista aplikacyjny Aplikacja Zmyślny programista aplikacyjny Procesor zapytań (np. konsul. SAP) Podsystem składu Indeksy Men. transakcji Admin BD, Stroiciel BD Odtwarzanie System operacyjny Sprzęt [procesor(y), dysk(i), pamięć] Oryginał: Shasha & Bonnet 10. Strojenie 4

Cel wykładu • Pokazać: – Pryncypia strojenia, które są wspólne dla różnych systemów, platform i technologii – Wyniki eksperymentów nada efektywnością proponowanych metod – Techniki radzenia sobie z problemami wydajnościowymi Oryginał: Shasha & Bonnet 10. Strojenie 5

Myśl globalnie, działaj lokalnie • Zasada taka jak w medycynie (chirurgii) – Osiągnąć jak największy efekt za pomocą jak najmniejszej interwencji – Nie lecz symptomów, lecz przyczyny – Nie zajmuj się drobnymi problemami, bo możesz popsuć całość • Strojenie baz danych nie mniej tajemne niż medycyna (mniej wtajemniczonych) Oryginał: Shasha & Bonnet 10. Strojenie 6

Partycjonowanie rozpycha wąskie gardła • Partycjonowanie w przestrzeni – Rozproszenie danych geograficzne – Hurtownictwo danych, bazy analityczne – Bazy rezerwowe (partycjonowanie dla dostępności) – Rozproszenie danych na wielu dyskach (równoległa praca kontrolerów) • Partycjonowanie w czasie – Przeniesienie zadań wsadowych na okresy mniejszego obciążenia (noc, weekend) Oryginał: Shasha & Bonnet 10. Strojenie 7

Inicjacja jest droga, używanie tanie • Inicjacja operacji dyskowej jest droga, a potem odczyt ciągu sektorów tani • Wysłanie komunikatu sieciowego jest drogie, ale każdy dodatkowy bajt wysłany tym samym komunikatem jest bardzo tani • Analiza składniowa, kontrola praw dostępu, optymalizacja zapytania jest droga, ale następne wykonanie tego zapytania tanie – używaj prepared statement, soft parse • Otwarcie połączenia z bazą danych jest drogie, ale wielokrotne użycie tanie – Używaj puli połączeń Oryginał: Shasha & Bonnet 10. Strojenie 8

Wsadź na serwer to, co ma tam być • Równoważ obciążenie klienta i serwera • Lepszy jest mechanizm wyzwalaczy niż aktywne czekanie aplikacji na zdarzenie (np. poprzez wielokrotne ponawianie zapytania o oczekiwane dane) • Interakcja z użytkownikiem GUI powinna odbywać się poza zakresem transakcji, bo trwa długo • Obliczenia numeryczne (np. FFT) raczej nie na SZBD • Złączenie tabel raczej nie na kliencie Oryginał: Shasha & Bonnet 10. Strojenie 9

Bądź gotowy na kompromis • Dodanie pamięci RAM przyspiesza system, ale kosztuje $ • Dodanie indeksu przyśpiesza zapytania, ale spowalnia modyfikacje danych • Robienie dużych zapytań raportujących na kopii głównej bazy danych, obniża jej obciążenie, ale kosztuje $ i sprawia, że odpowiedzi nie są dokładne • Obniżenie izolacji transakcji zwiększa szybkość, ale obniża poprawność Oryginał: Shasha & Bonnet 10. Strojenie 10

Eksperymenty • Będą wyniki eksperymentów pozwalających ocenić sensowność porad • http: //www. diku. dk/dbtune/experiments zawiera zapytania SQL, dane i narzędzia do przeprowadzania eksperymentów • Teraz to jest nawet: http: //www. databasetuning. org/ Oryginał: Shasha & Bonnet 10. Strojenie 11

Sprzęt użyty do eksperymentów • SQL Server 7, SQL Server 2000, Oracle 8 i, Oracle 9 i, DB 2 UDB 7. 1 • Trzy konfiguracje: – Dual Xeon (550 MHz, 512 Kb), 1 Gb RAM, Internal RAID controller from Adaptec (80 Mb) 2 Ultra 160 channels, 4 x 18 Gb drives (10000 RPM), Windows 2000. – Dual Pentium II (450 MHz, 512 Kb), 512 Mb RAM, 3 x 18 Gb drives (10000 RPM), Windows 2000. – Pentium III (1 GHz, 256 Kb), 1 Gb RAM, Adapter 39160 with 2 channels, 3 x 18 Gb drives (10000 RPM), Linux Debian 2. 4. Oryginał: Shasha & Bonnet 10. Strojenie 12