Narzędzia do analizy plików śladu sesji ORACLE

post_img

Analiza pliku śladu sesji bazy danych ORACLE dostarcza wielu informacji na temat zużycia zasobów oraz wykonywanych operacji. W prostych przypadkach można ów plik przeglądać w postaci źródłowej. Jednak przy bardziej skomplikowanych problemach jego czytelność nie pozwala na sprawne rozwiązywanie problemów. Firma ORACLE dostarczyła dwa narzędzia do generowania raportu z plików śladu. Czasem warto poszukać jeszcze innych rozwiązań. Każde z nich ma swoje mocne i słabe strony. W bardzo pobieżny sposób spróbuję opisać kilka z nich.

Do testów użyłem pliku śladu sesji z wersji bazy 11.2 o wielkości 440MB i wielu podobnych, lecz nie jednakowych zdań SQL (nie używane BindVariables).

ORACLE TKPROF

Jest to standardowe narzędzie dostarczone z bazą danych. Do jego zalet należą szybkość i brak potrzeby dodatkowej instalacji. W przypadku plików małych i średniej wielkości prędkość działania jest także zadowalająca. Jeżeli plik śladu zawiera bardzo dużo unikalnych zdań SQL, czas przetwarzania znacznie się wydłuża. Za duży minus uważam brak agregowania podobnych zdań SQL – parametr AGGREGATE służy tylko do agregacji takich samych zdań SQL.

ORACLE TRACE ANALYZER

Tu mamy do czynienia ze znacznie bardziej zaawansowanym narzędziem. Można je pozyskać z metalink.oracle.com (note #224270.1). Wymaga ono bazy danych ORACLE oraz instalacji przez administratora. Mimo to atuty narzędzia rekompensują ewentualne niedogodności. Możliwość konfigurowania oraz kompletność informacji stawia je w czołówce dostępnych rozwiązań.

Aby uzyskać pełny zakres możliwości oferowany przez TRCA, należy zainstalować je na tej samej bazie, z której pochodzi plik śladu. Z tego powodu zastosowanie rozwiązania może być utrudnione, a czasem wręcz niemożliwe. Dodatkowym minusem jest dość duże obciążenie generowane przy przetwarzaniu pliku śladu. W przypadku baz produkcyjnych może to stanowić wystarczający powód do szukania alternatyw. Niestety moja próba analizy pliku testowego nie powiodła się. Po trzech godzinach zakończyłem próbę wygenerowania raportu.

OraSRP

http://oracledba.ru/orasrp/

Aktualnie jest to mój ulubiony  sposób analizy plików śladu. Działa szybko nawet z bardzo dużymi plikami. Pliki wynikowe mają bardzo przejrzysty i ergonomiczny układ. Linki nawigują pomiędzy różnymi częściami raportu. Spośród testowanych programów ten najlepiej radzi sobie z agregowaniem podobnych zdań SQL, dzięki czemu raport jest bardziej czytelny i zwarty.

Przykład poniżej obrazuje sposób działania agregacji podobnych zdań SQL. Bardzo dobrze rozpoznawane i agregowane są SQL’e z literałami.

Tvdxtat

http://antognini.ch/category/apmtools/tvdxtat/

Rozwiązanie to napisano w języku Java, dzięki czemu jest ono przenośny. Domyślne raporty wyglądają mniej czytelnie niż w przypadku OraSRP, za to można zmienić arkusz stylów na własny. Agregacja niestety nie działa już tak dobrze. Powyższe zdanie SQL zostało rozbite na wiele identycznych, jeśli pominiemy literały, co znacząco utrudnia analizę. Poniżej lista najbardziej obciążających zdań SQL, gdzie każda pozycja typu INSERT powinna być zagregowana do jednego wykonania, tak jak w przypadku OraSRP.

TraceAnalyzer

http://dominicgiles.com/traceanalyzer.html

Aplikacja ta została napisana w Javie z GUI, co zapewnia jej przenośność. Niestety próba wczytania dużego pliku śladu nie udała się. Przy mniejszych plikach czytelność i ergonomia jest wystarczająca, lecz osobiście preferuję wygenerowane strony HTML. Za bardzo udany pomysł uważam oznaczanie sposobu obciążenia za pomocą „Ratings Key”, czyli graficznych symbolów oznaczających dany typ obciążenia z numerkiem świadczącym o pozycji w raporcie typu „Top N”.

Podsumowanie

Przy pliku śladu wielkości 440MB czasy przetwarzania wyglądały następująco :

Narzędzie Czas przetwarzania w minutach Wielkość pliku wynikowego [MB]
ORACLE TKPROF 15 140
ORACLE TRACE ANALYZER
OraSRP 1 0,3
Tvdxtat 7 2,5
TraceAnalyzer

Przy mniejszych wielkościach pliku śladu bardzo dobrze sprawują się narzędzia dostarczone przez ORACLE. Przy dużych plikach – z wieloma podobnymi, ale nie identycznymi zdaniami SQL –niezastąpiony okazuje się OraSRP. Ten jako jedyny potrafił poradzić sobie z ekstremalnymi przypadkami.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *