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

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

Dzisiejszy wpis czysto teoretyczny. Oczywiście istnieje pewne nawiązanie do praktycznych sytuacji napotkanych w pracy.

Załóżmy, że pewna baza danych służąca w pewnym projekcie (którego nie znamy) zaczyna pracować nie tak jak powinna. Czasy odpowiedzi są zdecydowanie wydłużone, planowane raporty nie wykonują się w okienku czasowym, procesy integracji danych pomiędzy systemami również zwalniają, no i idzie rozkaz z góry – „trzeba to naprawić na wczoraj”.

Co w takiej sytuacji należy zrobić? Od czego zacząć? Nie znamy przecież kompletnie systemu, logiki tam wykonywanej, czy też parametrów fizycznych serwera aplikacyjnego i bazodanowego.

Stworzyłem sobie taką listę rzeczy, których powinienem się dowiedzieć (lub o które powinienem zapytać kogoś pracującego w danym projekcie). Lista ta została podzielona na odrębne kategorie, i tak:

Ogólne informacje o bazie danych i jej przeznaczeniu

  • Wersja bazy danych (zakładam Oracle)
  • System operacyjny
  • Charakter pracy bazy danych (OLTP, hurtownia)
  • Ilość użytkowników pracujących jednocześnie
  • Standardowe procesy zaimplementowane w bazie danych (przeładowanie danych źródłowych, wystawiane danych do innych systemów itp.), oraz okienka czasowe, w czasie których są realizowane
  • Jaki jest przyrost danych?

Informacje dotyczące konkretnych procesów wykonywanych w bazie danych

  • W przypadku problemów wydajnościowych związanych z raportami – kod sql raportu
  • Częstość i standardowe czasy działania funkcji oraz procedur PL/SQL
  • Czynności wykonywane równocześnie
  • Polityka audytu i logowania wykonywanych operacji

Parametry sprzętowe

  • Dostępny RAM
  • Dostępne procesory
  • Dostępne dyski/macierze dyskowe

Parametry „bazodanowe”

  • Metryki i statystyki dostępne w Oracle (ADDM, Statspack)
  • Wielkość TEMP
  • Wielkość UNDO
  • Parametry instancji – rozmiar SGA, PGA, poszczególnych procesów (LGWR, DBWR)
  • Plan zapytania, optymalizacja kodu
  • Indeksy
  • Partycjonowanie
  • Ilość i wielkość datafile, redo logów itp.
  • „Dodatki” np. używanie LogMinera

Powyższa lista to wnioski z mojego skromnego doświadczenia. Byłoby miło gdyby ktoś, kiedyś, mógł się ustosunkować do powyższego i podpowiedzieć, które rzeczy są zbędne, które są ważne, a które ważniejsze?
A może o czymś zapomniałem? Czegoś nie wiem (to to na pewno🙂 )
Dzięki za wszelkie podpowiedzi i wskazówki.

W kolejnych wpisach postaram się rozwinąć wymienione punkty, i pokazać ich istotność w praktycznych działaniach.

  1. rafg28
    2010/11/24 o 18:55

    🙂 ja bym dodal na pierwszym miejscu „komunikatywna osobe ktora prosi Cie o pomoc i oczekuje pomocy a nie……robi wszytko zebys sie od niej od…walil”🙂

    niestety jak widac kreatywne pomysly PM’ow z cyklu „my wam pomozemy…ale my nie chcemy….ale i tak wam pomozemy” rodza duze frustracje🙂

    • gdrzymala
      2010/11/25 o 14:07

      Dokładnie. Jednak na tym blogu chciałbym skupić się na samych merytorycznych rzeczach, odsuwając się jak najdalej od sposobu działania korporacji i polityki jaką czasem trzeba uprawiać🙂

  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: