DBPLUS BETTER PERFORMANCE. Dokumentacja operacyjna do oprogramowania DBPLUS PERFOMANCE MONITOR firmy DBPLUS

DBPLUS BETTER PERFORMANCE Dokumentacja operacyjna do oprogramowania DBPLUS PERFOMANCE MONITOR firmy DBPLUS

Data: 24 listopad 2010

Spis treści 1 Cel... 4 2 Problemy wydajnościowe widziane oczami firmy DBPLUS... 4 2.1 Konfiguracja problemy wydajnościowe...4 2.2 Zapytanie SQL problemy wydajnościowe...4 3 Monitoring bazy danych... 5 3.1 Poziom zajętości serwera bazy danych?...5 3.2 W jaki sposób zidentyfikować problem wydajnościowy?...6 3.2.3 Oczekiwania - identyfikacja... 6 3.2.4 Czas realizacji odczytu i zapisu (I/O obsługa)... 8 3.2.5 Zapytania SQL powodujące problem wydajnościowy... 9

1 Cel Dokument omawia w jaki sposób użyć oprogramowania DBPLUS PERFORMANCE MONITOR w codziennej diagnozie wydajności baz danych Oracle. 2 Problemy wydajnościowe widziane oczami firmy DBPLUS Specjaliści DBPLUS zajmujący się tematyką wydajności baz danych Oracle dzielą problemy wydajnościowe na dwie grupy : konfiguracja oraz zapytania SQL. Mimo, iż wiodącym problemem u klientów jest problem z zapytaniami SQL, który generuje wszelkiego rodzaju problemy poboczne opisane poniżej to zdarza się, że bez rozwiązania problemów konfiguracyjnych wydajność bazy danych nie zostanie poprawiona poprzez optymalizację zapytań SQL. 2.1 Konfiguracja problemy wydajnościowe Konfiguracja dotyczy optymalnego ustawienia zarówno parametrów systemu operacyjnego, serwera, macierzy dyskowej jak również parametrów bazy danych Oracle. Oprogramowanie DBPLUS PERFORMANCE MONITOR nie sprawdza konfiguracji parametrów systemu operacyjnego, serwera ani macierzy. Przykładowym problemem wydajnościowym, którego przyczyną jest konfiguracja systemu operacyjnego może być ustawienie parametrów odpowiadających za SWAP w systemie operacyjnym. Kolejnym przykładem może być wymiana macierzy lub serwera bazy danych na inny typ lub model. Wydajność po wymianie sprzętu spada gwałtowanie i wówczas gdzie szukać przyczyny kiedy dostawca usilnie nam mówi, że dostarczony sprzęt jest kilkukrotnie szybszy od starego? Czy oznacza to że administrator nie otrzyma informacji o złej wydajności i jej przyczynach z oprogramowania DBPLUS PERFORMANCE MONITOR jeśli problemy te są związane z konfiguracją systemu operacyjnego i sprzętu a nie bazy danych Oracle? Administrator jak najbardziej otrzyma informacje o złej wydajności bazy danych oraz otrzyma informację o obszarze w którym wydajność ta jest niezadowalająca ponieważ wolno działające zasoby systemu operacyjnego jak również sprzętowe odbijają się na statystykach bazy danych Oracle. Przykład1: Nastąpiła awaria cache zapisu w macierzy dyskowej. Macierz dyskowa zamiast informować o awarii cache informuje o awarii dysku. Przyjeżdża inżynier dokonuje wymiany dysku jednak problem wydajnościowy pozostaje. Nasuwa się pytanie w jaki sposób można zobaczyć taką awarię na podstawie Naszego oprogramowania. Otóż zapisujemy czasy zapisów i odczytów danych przez bazę danych. Zapis który dla bloku 8K trwał 1 milisekundę trwa 8 milisekund a liczba zapisywanych danych jest na tym samym poziomie co wskazuje, że problem istnieje poza bazą danych i należy go szukać w macierzy dyskowej. Wymiana cache zapisu w macierzy dyskowej rozwiązała problem. Patrz film: http://www.youtube.com/user/dbpluspl#p/a/u/0/yyyvi8nlm0s Przykład2: Źle skonfigurowane parametry kernela w systemach unixowych do obsługi file system. W bazach danych generujących dużą liczbę operacji I/O gdzie pliki bazy danych składowane są na wielu file systemach ważne jest odpowiednie ustawienie parametrów kernela odpowiadających za obsługę file system. W przypadku złej konfiguracji bardzo szybko zobaczymy, że czas zapisu czy też odczytu pojedynczego bloku danych w bazie danych trwa nie 1 czy 2 milisekundy tylko od 5 milisekund w górę. 2.2 Zapytanie SQL problemy wydajnościowe Wszystkie problemy wydajnościowe wyłączając problemy związane z konfiguracją opisaną powyżej są zawsze generowane przez zapytania SQL. Lista problemów bazy danych generowana przez zapytanie SQL lub kod PL/SQL: Zajętość CPU Duża utylizacja I/O Latche Deadlocki krzyżowe blokowanie rekordów przez sesje Lock,enqueue blokady tych samych rekordów przez różne sesje

3 Monitoring bazy danych Monitoring bazy danych Oracle prowadzony jest przez Nasze oprogramowanie w sposób automatyczny poprzez uruchamianie joba, którego statystyki można zobaczyć w ALERTS Dbplus Procedure Statustus. W razie jakichkolwiek problemów z uruchomieniem joba w oknie tym pojawi się informacja o błędzie. 3.1 Poziom zajętości serwera bazy danych? Monitoring wydajności bazy danych należy zacząć od sprawdzenia jaki poziom obciążenia generuje monitorowana baza danych. W tym celu należy użyć funkcjonalności Performance database load (druga zakładka w głównym menu). Wykres powinien zawsze mieścić się w białej strefie. Jeśli wykres znajduje się powyżej białego pola oznacza to, że problemy wydajnościowe odczuwają wszyscy użytkownicy aplikacji pracujący na bazie danych a serwer bazy danych obciążony jest w 100% przez bazę danych pod warunkiem, że wysoki poziom czerwonej linii nie jest spowodowany oczekiwaniami typu enqueue*, latche*.

Administrator zawsze może otrzymać zgłoszenie problemu wydajnościowego mimo, że wykres mieści się w białej strefie. Biała strefa informuje nas ile procent maszyny jest zajętej oraz czy występują problemy wydajnościowe dla całej bazy danych a nie to czy istnieją problemy wydajnościowe pojedynczych procesów. Możemy wyobrazić sobie sytuacje w której otrzymujemy zgłoszenie wolno działającej bazy danych Oracle a w funkcjonalności PERFORMANCE database load wykres jest na poziomie 3CPU a nasza maszyna ma 16 CPU. Jak należy zinterpretować ten wynik? Należy rozumieć go tak, że co najmniej trzy procesy użytkowników działały w sposób równoległy a więc maszyna była zajęta w 18% a czas trwania zapytań mógł być na tyle długi, że użytkownicy odczuwali dyskomfort z pracy w aplikacji. Wówczas należy skorzystać z funkcjonalności SQL3D lub SQL ANALYZE w celu identyfikacji wolnych zapytań i poddaniu ich optymalizacji. 3.2 W jaki sposób zidentyfikować problem wydajnościowy? Identyfikacja problemu wydajnościowego zawsze powinna następować w opisanej kolejności: Sprawdzenie typu oczekiwania, którego czas był największy w okresie, który nas interesuje Sprawdzenie czasu realizacji odczytu i zapisu bloku danych przez bazę danych w okresie, który nas interesuje Wytypowanie zapytań, które są odpowiedzialne za problem wydajnościowy w okresie, który nas interesuje Dlaczego identyfikacja problemu wydajnościowego powinna zawsze następować w przedstawionej kolejności? Powód jest bardzo prosty, typ oczekiwań powinien być zawsze sprawdzany jako pierwszy ponieważ odpowie nam czy oczekiwania, które występują w interesującym Nas czasie mogły wpłynąć na wydajność zapytań SQL niezależnie od tego jakie to były zapytania. Przykład: Jeżeli głównym oczekiwaniem w intersującym nas czasie będzie LATCHE* wówczas nie ma sensu wykonywać kolejnych kroków ponieważ nieważne jakie były uruchamiane zapytania, musimy w pierwszej kolejności zająć się rozwiązaniem problemu wydajnościowego typu LATCHE*. Jeśli głównym oczekiwaniem będzie ENQUEUE* wówczas musimy znaleźć sesję blokującą a więc nie ma sensu wykonywać kolejnych kroków sprawdzania w identyfikacji problemu wydajnościowego. Dlaczego powinienem w drugim ruchu sprawdzić czasy zapisów i odczytów pojedynczego bloku bazy danych przez bazę danych? Powodem jest sprawdzenie czy nie ma problemu konfiguracyjnego. Jeśli wystąpi problem konfiguracyjny wówczas w sposób znaczący spowolnia wszystkie procesy uruchamiane w bazie danych a więc w sposób znaczący spowolnia również bardzo szybkie zapytania których czas trwania wynosi 1 milisekundę. Optymalizacja ich nie ma żadnego sensu bez rozwiązania problemu konfiguracyjnego. Dopiero w trzecim ruchu szukamy wolnych zapytań w interesującym nas okresie pod warunkiem, że pierwsza dwa ruchy nie wykazały niczego niepokojącego. Wówczas jesteśmy pewni, że optymalizacja wolnodziałającego zapytania przyniesie efekt w postaci rozwiązania problemu wydajnościowego. 3.2.3 Oczekiwania - identyfikacja Identyfikacji oczekiwań w bazie danych wykonujemy za pomocą ekranu PERFORMANCE Waits Klikając w interesujący nas czas otrzymujemy detalistyczne informacje na temat typu oraz czasu trwania oczekiwań. Przykład1: Ekran poniżej przedstawia, że o godzinie 09:00:56 największy typ oczekiwań, który stanowi około 90% czasu wszystkich oczekiwań w tym czasie to db file sequential read co oznacza, że wszystkie sesje użytkowników w tym czasie czekały na odpowiedź z urządzeń dyskowych. Widzę również w prawym dolnym rogu (wykres niebieski) statystyki za cały wybrany okres a nie za dana chwilę czasową. Statystyki za cały wybrany okres również wskazują, że największym problemem wydajnościowym w bazie danych jest czas oczekiwania na urządzenia dyskowe.

A więc oznacza to, że mogę iść do sprawdzenia numeru dwa ponieważ typ oczkiwania nie jest związany z LATCHE ani ENQUEUE. Przykład2 Ekran poniżej przedstawia, że o godzinie 12:01:58 największy typ oczekiwań, który stanowi około 80% czasu wszystkich oczekiwań w tym czasie to latch free co oznacza, że połowa czasu trwania wszystkich zapytań oczekiwała na obsługę latcha(blokowanie dostępu do pamięci). Można to również przetłumaczyć na to że ponad 100 sesji w bazie danych w każdej sekundzie w ciągu 15 minut nie robiła nic poza czekaniem na obsługę latcha. Ozanacza to, że nie ma sensu wykonywać optymalizacji zapytań dopóki nie zostanie rozwiązany problem z latchem. Widzę również w prawym dolnym rogu (wykres niebieski) statystyki za cały wybrany okres a nie za dana chwilę czasową. Statystyki za cały wybrany okres (od 15 do 16 listopada 2010) wskazują, że największym problemem wydajnościowym w bazie danych jest czas oczekiwania na urządzenia dyskowe choć widać, że latch free jest na drugim miejscu i stanowi dla wybranego okresu 20% czasu trwania zapytań.

Przykład3 Ekran poniżej przedstawia, że o godzinie 12:14:40 największy typ oczekiwań, który stanowi około 40% czasu wszystkich oczekiwań w tym czasie to enqueue co oznacza, że 40% czasu trwania wszystkich zapytań oczekiwało na blokadę wierszy między sesjami. Widać również, że 30% czasu trwania wszystkich zapytań oczekiwało na obsługę latcha. Dopiero na trzecim miejscu jest obsługa I/O. Można to również przetłumaczyć, że 50 sesji w każdej sekundzie w ciągu 15 minut było blokowanych przez inne sesje w dostępie do modyfikacji rekordu oraz, że 38 sesji w bazie danych w każdej sekundzie w ciągu 15 minut nie robiła nic poza czekaniem na obsługę latcha. Oznacza to, że bez rozwiązania problemu z blokadą rekordów jak również rozwiązania problemu z latchem nie ma potrzeby dokonywać optymalizacji zapytań SQL. 3.2.4 Czas realizacji odczytu i zapisu (I/O obsługa) W drugiej kolejności monitoringu bazy danych zawsze należy sprawdzić czasy realizacji odczytu i zapisu bloku danych w bazie danych. Jeśli czas ten jest poniżej oczekiwań (progiem powinny być 4 milisekundy choć szybkie macierze dyskowe rzadko kiedy realizują czas odczytu i zapisu pojedynczego bloku o wielkości 8K powyżej 2 milisekund). Należy pamiętać, że wartości te są miarodajne tylko w sytuacji gdzie liczba wszystkich odczytanych bloków danych w ciągu dwóch godzin jest na poziomie > 10000. W celu uzyskania informacji o statystykach odczytu i zapisu należy w aplikacji DBPLUS PERFORMANCE MONITOR wybrać czwartą zakładkę I/O stat I/O Analyze. Slajd poniżej przedstawia informacje o odczytach oraz zapisach w interesującym administratora czasie. Widać, że największy czas odczytu pojedynczego bloku danych wynosi 0,002 sekundy czyli 2 milisekundy.

Slajd poniżej przedstawia informacje o odczytach i zapisach dla przestrzeni tabel o nazwie SA_J w interesującym administratora czasie. Czas odczytu pojedynczego bloku danych wynosi nawet 4 sekund. Czy oznacz to że mamy problem z urzedzeniami dyskowymi? Nic z tych rzeczy zawsze patrząc na czas odczytu pojedynczego bloku danych należy sprawdzić czy liczba odczyatnych bloków jest większa niż 10000. Jeśli liczba bloków jest mniejsza wówczas wynik można traktować jako nie miarodajny ze względu na brak buforowania. Dokładnie taką sytuację widzimy poniżej. 3.2.5 Zapytania SQL powodujące problem wydajnościowy Jeżeli zostaną sprawdzone czasy oczekiwań oraz czasy realizacji odczytu i zapisu danych a wynik sprawdzenia pokazuje że nie ma problemu na tym poziomie wówczas należy przejść do monitoringu zapytań SQL, które stanowią problem wydajnościowy. W celu znalezienia zapytań, które należy poddać optymalizacji w pierwszej kolejności należy: Otworzyć ekran PERFORMANCE SQL3D wybrać interesujący nas zakres z ziarnistością 15 minut poprzez wybór group by option Snap oraz zawęzić okres godzin do pracy użytkowników np.; od godziny 07:00 do 15:00. Jeśli system działa 24 godziny na dobę na tych samych obrotach wówczas zawężenie nie ma sensu.

Slajdy pokazują czas trwania zapytań, każde z zapytań zaznaczone jest innym kolorem. Oś pozioma wskazuje czas wybranych godzin a oś pionowa wskazuje czas trwania zapytania w danej chwili osi czasu. Zapytanie o numerze 3024981896 kolor niebieski trwa od godziny 7 rano do godziny 13:00 nie jest to czas dla jednego uruchomienia tylko suma czasu trwania zapytania dla wszystkich uruchomień mających miejsce w wybranym zakresie godzin. Widać, że w najniższym punkcie około godziny 8 zapytanie trwało 28 sekund(slajd pierwszy) a w najwyższym punkcie 514 sekund(slajd drugi). Doskonale również widać zapytania, które działały tylko w krótki porach wybranego zakresu np.: zapytanie numer 3642647183 występuje jako czwarte. Detale dotyczące zapytanie można sprawdzić poprzez zaznaczenie interesującego koloru i naciśnięcie przycisku add to sql details. Wówczas zapytanie zostanie przeniesione do funkcjonalności PERFORMANCE SQL DETAILS gdzie przed podjęciem decyzji o optymalizacji można sprawdzić czy zapytanie zmienilo plan wykonania oraz jak wygląda historia jego uruchomień. Są to bardzo ważne wskazówki ponieważ nie ma sensu optymalizaować zapytania, które wystąpiło tylko raz. Jeśli zapytanie zmieniło plan wykonania będziemy od razu o tym wiedzieć wraz z otrzymaniem informacji, który z planów wykonania jest szybszy a więc mamy od razu informacje co się stało, że zapytanie zaczęło wolno działać oraz wzkazówkę w jaki sposób powinno zostać naprawione od strony wydajnościowej. W celu ustawienia danego planu można posłużyć się STORED OUTLINES lub ustawić odpowiednie statystyki dla tabel biorących udział w zapytaniu. Slaj poniżej przedstawia zapytanie o numerze już nam znanym z SQL3D 3024981896. Wiemy już, że zapytanie jest uruchamiane praktycznie codziennie a czas trwania na dzień zapytania wynosi od

284 sekund do 2456 sekund. Czas ten jest zależny od liczby uruchomień na dany dzień (kolumna executions) jak również od liczby przeczytanych danych (kolumna disk_reads MB). Zapytanie jest realizowane poprzez jeden plan wykonania w tym przypadku jest to full scan po indeksie TOW_NAZ_P. Chcąc poznać listę kolumn indeksu TOW_NAZ_P należy użyć funkjconalności Show Plan Objects. Indeks składa się z kolumn NAZ_P oraz KOD a więc kolumn, które w żaden sposób nie borą udziału w zapytaniu, więc używanie wskazanego indeksu nie ma żadnego sensu. Developer poprzez użycie konstrukcji w zapytaniu /*+ INDEX_ASC (TOW TOW_NAZ_P) FIRST_ROWS */ wymusza użycie indeksu na kolumnach bez sensu do wyboru danych. Należy pamiętać że indeks ten pełni również funkcję sortującą wynik poprzez zastosowanie INDEX_ASC. Zmieniając plan wykonania dla omawianego zapytania zostanie zwiększona wydajność zapytania ale zostanie również zmienione sortowanie wyniku. Jaki indeks pownien zostać użyty do obsługi zapytania? Żeby odpowiedzieć na to pytanie należy sprawdzić selektywność wszystkich kolumn występujących po słowie WHERE w zapytaniu. Dokonać tego można za pomocą funkcjonalność Show Plan Objects klikając na TABLE jak w slajdzie poniżej. Jedyną kolumną ograniczająca wybór wierszy jest ZNACZNIK_KOD, która to posiada 633 różnych wartości w tabeli. A więc w celu zwiększenia wydajności tego zapytania należy stworzyć indeks function based opraty o kolumnę upper(znacznik_kod)

Przykład ponieżej przedstawia zapytanie które zmienia podczas działania plan wykonania. Każdego dnia zapytanie pracuje z dwoma różnymi planami wykonania kolumna plan hash value. Plan wykonania o wartości 512111095 jest dwukrotnie a nawet trzykrotnie szyby od planu wykonania 818720697. Administrator powinien w takiej sytuacji wymusić używanie jednego szybszego planu wykonania za pomocą STORED OUTLINES. Funkcjonalność taka będzie dostępna w kolejnej wersji Naszego oprorgamowania. Do optymalizacji zapytań SQL można podejść również w sposób grupowy przez co rozumiemy optymalizacje wszystkich zapytań, które mają taki sam plan wykonania. Za pomocą funkcjonalności SQL Analyze (musi być zaznaczona opcja Group By Plan) zostaną wyświetlone statystyki dla

planów zapytań a nie pojedynczych zapytań. Jest to bardzo przydatne w sytuacji gdzie w bazie danych występują literały lub gdy ten sam plan wykonania używany jest przez wiele zapytań. Slajd poniżej przedstawia trzy plany wykonań, które powinny być zoptymalizowane. Zółte slupki pokazują obciążenie serwera bazy danych przez zapytania, które mają trzy zaznaczone plany wykonania. Klikając dla każdego z nich w przycisk Add to Sql Details zobaczymy w PERFORMANCE Database Load SQL Plan wszystkie zapytania, które używają zaznaczonych planów wykonania wraz z pełnymi statystykami, które można oglądać zarówno dla planu wykonania jak również dla pojedynczych zapytań. Ddzięki tym informacją podejmując decyzję o zmianie planu wykonania będziemy wiedzieć ile zapytań jest objętych zmianą. Widok zapytań zawierających się we wskazanych planach wykonań. Widzimy zapytania wraz z ich statystykami, dzięki czemu można podjąć decyzję czy zapytanie da się zoptymalizowac z poziomu bazy danych. Wszystkie zapytania różnią się od siebie zakresem dat jak również liczbą argumentów w klauzuli IN.Doskonale więc wiemy, że zmiana planu wykonania spowoduje wzrost wydajności wszystkich pokazanych zapytań.

Optymalizacja planu wykonania polegała na sprawdzeniu wielkości tabel. Największą tabelą na której odczycie baza traci najwiećej czasu jest tabela /BIC/AZRT038F00. W durgiej kolejności została sprawdzona selektywność dla poszczególnych kolumn występujących po kaluzuli WHERE. Poprzez użycie funkjconalności Show plan objects uzykałem informację, że kolumna PSTING_DATE zawiera 586 różnych wartości a dotychczas używany indeks /BIC/AZRT03BF00~02 zabudowany na kolumnie PLANT jest zbyt mało selektywny dla tak wielu wartości występujących w IN. Idealnym indeksem do obsługi tego zapytania byłby indeks zbudowany na kolumnach PSTING_DATE,PLANT. Został więc usunięty indeks jednokolumnowy i zbudowany indeks dwukolumnowy. Czas trwania zapytania zmniejszył się dziesięciokrotnie z ponad 3000 sekund do 300 sekund. Tak wygląda porównanie obciążenia baza danych przed i po optymalizacji. Wykres wykonany poprzz funkcjonalność PERFORMANCE COMPARE. Linia niebieska przedstawia czas trwania wszystkich zapytań w dniu 15 listopada 2010 a linia pomarańczowa przedstawia czas tyrwania wszystkich zapytań w dniu 15 grudnia 2010. Slajd poniżej przedstawia różnicę w liczbie odczytanych danych w dniach 15 listopada linia niebieska i 15 grudnia 2010 linia pomaranczońwa. Doskonale widać, że czas trwania zapytań pokazany na slajdzie powyżej uległ zmniejszeniu ze względu na redukcje liczby odczytywanych danych a co za tym idzie zmniejszenie czasu odczytywanych danych.