Strona główna > Oracle Database > Gdy zaczyna iść źle – próby optymalizacji cz.2

Gdy zaczyna iść źle – próby optymalizacji cz.2

Dzisiejszy wpis będzie kontynuacją poprzedniej notki. Jak zaznaczyłem wcześniej – postaram się rozwinąć zaprezentowane punkty tak, aby można było dojść do wniosku, że wymienione rzeczy są dosyć istotne w próbie przywracania bazy danych do życia.

W moim odczuciu najważniejsze jest badanie problemów mając dany odpowiedni kontekst. Dlatego też, należy rozpocząć od analizy na wysokim poziomie abstrakcji i przechodzić coraz niżej.

Najwyższym poziomem abstrakcji – co zaznaczyłem w poprzednim wpisie – są ogólne informacje o bazie danych i jej przeznaczeniu.

Pierwsza „kropka” brzmiała :

  • Wersja bazy danych (zakładam Oracle)

Nie ma w tym punkcie zbyt dużej filozofii. Musimy znać dokładną wersję bazy danych, aby mieć możliwość wyboru odpowiedniego „oręża” w walce z problemem. Przykładem z mojego skromnego doświadczenia niech będzie sytuacja, w której nie sprawdziłem wersji bazy (przecież wszystko w firmie stoi na 10g lub 11g…). Okazało się, że w tym przypadku była to 9i, i wszystkie przygotowane przeze mnie skrypty wykorzystujące mechanizm AWR można było wyrzucić do kosza.
W przypadku Oracle, z wersji na wersję uzyskujemy coraz większą automatyzację niektórych procesów. Warto wiedzieć, że np. w wersji 10 udostępniony jest wspomniany wcześniej AWR oraz ADDM, a w wersji 11 np. PL/Scope. Dokładny release bazy może też pomóc przy naprawianiu „znanych bugów”.

Druga kropka z poprzedniego wpisu:

  • System operacyjny

Również dosyć oczywista kwestia. Inaczej wygląda środowisko Microsoftowe, inaczej Linuxowe bądź AIXowe. Znajomość systemu operacyjnego pozwoli na sprawdzenie parametrów środowiska.

Kolejny punkt:

  • Charakter pracy bazy danych (OLTP, hurtownia)

Na ten temat można napisać książkę.
Wymienione typy systemów ( a istnieją przecież inne ), diametralnie się różnią. W systemach OLTP mamy do czynienia z dużą ilością krótkich transakcji, wykonywanych przez wielu użytkowników. Struktura tabel jest znormalizowana (aby uniknąć składowania tych samych danych w kilku miejscach) – najczęściej do 3 postaci normalnej. Istnieją dobrze określone indeksy – zazwyczaj na kluczach głównych i obcych (B-drzewa). Dane nie są agregowane, nie jest dostępna również historia. Środowisko hurtowni danych jest zupełnym przeciwieństwem – ilość równoległych zapytań jest stosunkowo mała. Są to głównie długie operacje odczytu, które wykonują skomplikowaną logikę. Aby uprościć zrozumienie struktury danych przez użytkowników biznesowych, a także, aby specyficzne typy zapytań pracowały szybciej, przeprowadza się denormalizację schematu. Koronnym przykładem w przypadku hurtowni danych jest struktura gwiazdy lub płatka śniegu. Hurtownia przechowuje dane historyczne, na odpowiednim poziomie agregacji. Zazwyczaj – tabela faktów (składająca się z kluczy obcych do wymiarów i miar) jest dużo większa od tabel wymiarów. Przez to, kluczowym elementem może tu być strategia partycjonowania tabel faktów. W przypadku hurtowni częściej korzysta się z indeksów bitmapowych, lub złączeniowych indeksów bitmapowych zamiast B-drzew.

Widać wyraźnie, jak środowisko, w którym dana baza danych pracuje, wpływa na kontekst oceny odpowiednich parametrów na niższym poziomie abstrakcji.

W poprzednim wpisie wspominam również o :

  • Ilość użytkowników pracujących jednocześnie

Ilość użytkowników przywoływana była we wcześniejszym wpisie. Tutaj jednak chodzi mi o zaakcentowanie sposobu obsługi sesji. W Oracle oprócz dedykowanego serwera istnieje również opcja serwera współdzielonego. Ma to znaczenie przy określaniu potrzebnych parametrów instancji (w obszarze SGA oraz PGA), a także określeniu potrzebnego rozmiaru pamięci RAM i CPU.

Następnie:

  • Standardowe procesy zaimplementowane w bazie danych

Należy zyskać maksymalną wiedzę dotyczącą obciążenia bazy danych w każdym okresie aktywności tej bazy. Przykładowo – w czasie dnia baza może pracować jako OLTP, jednak w nocy może istnieć potrzeba przeliczania pewnych raportów operacyjnych. Dodatkowo należy wziąć pod uwagę politykę wykonywania backup-ów (częstotliwość i średni czas trwania), a także czynności administracyjnych – przeliczania statystyk, przebudowywania indeksów, czyszczenie przestrzeni tabel itp. Pomysłem może być stworzenie dokumentu, który obrazuje zarys przebiegów czasowych poszczególnych operacji.

Ostatni punkt wysokopoziomowego spojrzenia na bazę danych mówi o przyroście danych, a dokładnie pyta:

  • Jaki jest przyrost danych?

Tutaj schodzimy już na trochę niższy poziom, ponieważ pytanie to pozwoli nam określić ilość przestrzeni potrzebną w czasie wykonywania różnych operacji, a także pomoże zbudować wyobrażenie na temat ogólnej ilości danych w systemie za miesiąc, rok …
Ma to znaczenie np. przy wykonywaniu raportów (inaczej może zachować się raport operujący na 100 wierszach, a inaczej na 1 mln) lub też przy operacjach DML (przy dużych przyrostach danych warto spojrzeć na wydajność dysków).

Na dzisiaj to tyle. Kolejne wpisy już niebawem😉

Kategorie:Oracle Database Tags: ,
  1. Brak komentarzy.
  1. No trackbacks yet.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

%d bloggers like this: