DBPLUS Performance Monitor™

Nowoczesny system do precyzyjnego monitorowania i analizowania wydajności bazy danych.

To wszechstronne i intuicyjne w użyciu oprogramowanie, które w przejrzysty sposób pokazuje problemy z wydajnością bazy danych, a także jest w stanie precyzyjnie wskazać ich przyczyny. Jednym z głównych problemów dla efektywnego dostarczania usług IT jest utrzymanie wystarczającej wydajności systemów informatycznych. Bardzo często, jedyną odpowiedzią wielu firm na problemy z wydajnością są inwestycje w większe, bardziej wydajne serwery. Niestety nie zawsze przynosi to oczekiwane rezultaty, pomimo poniesionych wysokich wydatków a optymalizacja wydajności systemu biznesowego na poziomie działającej pod nim bazy danych skutecznie rozwiązuje te problemy.

 

Zamiast inwestycji w sprzęt, problemy z wydajnością mogą być znacznie lepiej rozwiązane poprzez odpowiednią optymalizację bazy danych na poziomie najbardziej obciążających zapytań SQL. Aby móc zoptymalizować bazę danych należy zlokalizować w niej wąskie gardła oraz zrozumieć przyczyny ich powstania.

Najważniejsze cechy:


  • Umożliwia sprawne lokalizowanie przyczyn problemów wydajnościowych w bazach danych

  • Minimalnie obciąża silnik bazy danych podczas zbierania parametrów jej pracy

  • System nie ma dostępu i nie analizuje danych biznesowych

  • Regularne aktualizacje i wsparcie producenta zapewniają wsparcie dla najnowszych wersji baz danych

  • Intuicyjny interface użytkownika i łatwość nawigacji również dla osób bez wiedzy technicznej

opis
ZASOBY
TUTORIALE
FAQ
Q&A








Zobacz krótkie wideo wprowadzające


Zapoznaj się z głównym ekranem aplikacji i możliwościami konfiguracji dashboardu oraz sposobem dostępu do podstawowych i zaawansowanych parametrów monitorowanych baz danych. Ze względu na swój intuicyjny DBPLUS Performance Monitor™ jest wykorzystywany nie tylko przez administratorów baz danych, ale również innych specjalistów IT np. deweloperów lub administratorów aplikacji, ułatwiając współpracę w ramach organizacji i przyspieszając rozwiązywanie problemów.

 

Architektura aplikacji wykorzystuje serwer IIS, aby umożliwić wielu użytkownikom dostęp do aplikacji za pośrednictwem przeglądarki internetowej. To znacznie przyspiesza wdrażanie DBPLUS Performance Monitora™ w organizacji, gdyż nie ma potrzeby instalowania oprogramowania klienckiego na stacjach roboczych.



Opis



Koncentracja na przyczynach i źródle problemów


Cała filozofia powstania narzędzia koncentruje się wokół znalezienia prawdziwych przyczyn problemów z wydajnością. System pozwala na łatwe porównywanie danych i parametrów w różnych przekrojach na skali czasu. Pozwala szybko znaleźć problematyczne zapytania SQL i zrozumieć, dlaczego są one przyczyną zaistniałych problemów wydajnościowych.




Intuicyjny interface


Oprogramowanie posiada bardzo intuicyjny interfejs, łatwy do użycia nawet dla użytkowników, którzy nie mają dużego doświadczenia w tuningu wydajności baz danych.




Minimalne obciążenie procesora


Nie generuje zauważalnego obciążenia dla CPU. Inne narzędzia do mierzenia wydajności bazy danych generują problemy związane z obciążeniem procesorów bazy danych do zebrania niezbędnych informacji. Czasami potrzeba na to nawet mocy 4 CPU.




Zbieranie statystyk SQL co 15 minut


Nasze oprogramowanie zbiera statystyki w interwałach czasowych co 15 minut, a jeden taki przebieg trwa od 5 do 30 sekund w zależności od wielkości bazy danych. Takie podejście gwarantuje to, że obciążenie dla bazy danych będzie minimalne i niezauważalne nawet w największych i najbardziej obciążonych systemach biznesowych. Architektura naszego rozwiązania zaprojektowana jest pod kątem udostępnienia jak największej ilości użytkowników dostępu do systemu monitorującego, bez wpływu na wydajność monitorowanej bazy.




Regularne aktualizacje


Aby zagwarantować użytkownikom najwyższą jakość nasze oprogramowanie jest ciągle udoskonalane. W ciągu roku wydawane są minimum 4 nowe aktualizacje DBPLUS Perfomance Monitor™.




Wsparcie na najwyższym poziomie


Wsparcie, jakie udzielane jest użytkownikom, świadczą min. zespoły techniczne bezpośrednio zaangażowane w proces tworzenia oprogramowania.




Elastyczna polityka cenowa


Wskaźnik TCO, czyli możliwości rozwiązań DBPLUS do ceny zakupu i użytkowania jest w przypadku naszego oprogramowania nieosiągalny dla naszej konkurencji.

Zasoby



Pobierz program instalacyjny


Pobierz w pełni funkcjonalną wersję 30-dniową oprogramowania TRIAL. Jeżeli po 30 dniach nie zdecydujesz się na zakup pełnej licencji, system wyłączy pewne zaawansowane funkcje, lecz będzie można dalej używać jego podstawowych funkcjonalności dostępnych w wersji bezpłatnej.





Sprawdź nasze demo online


Zanim zainstalujesz program w swoim środowisku możesz zapoznać się z jego interfejsem i funkcjami dzięki w pełni funkcjonalnym wersjom demo jakie udostępniamy online.





Pobierz instrukcję użytkownika


Dokumentacja użytkownika opisuje w przystępny sposób wszystkie funkcje dostępne w oprogramowaniu. Instrukcja jest dostępna w dwóch wersjach – dla Oracle® i Microsoft™ SQL Server®.





Pobierz materiały informacyjne


Zapoznaj się z podstawowymi informacjami o DBPLUS Performance Monitor™.


Video Tutoriale





DBPLUS Performance Monitor: Locks by Application Issues






DBPLUS Performance Monitor: Locks by Ineffective Query






DBPLUS Performance Monitor: Memory Usage Issues (SQL Server)






DBPLUS Performance Monitor: Execution Plan Change






DBPLUS Performance Monitor: Ineffective Execution Plan



FAQ




Czy dajecie wsparcie do bezpłatnego testu waszego oprogramowania?


Tak. Jeśli zechcesz przetestować nasze oprogramowanie w swoim środowisku testowym to możemy wesprzeć Cię w jego instalacji i konfiguracji. Do tego oferujemy darmową usługę „Audyt wydajności”, w której na podstawie testowego działania naszego narzędzia badamy wydajność i przygotowujemy raport nt. wąskich gardeł wydajnościowych tego systemu. Jeżeli podczas testu oprogramowania napotkasz na jakieś problemy z jego używaniem możesz się z nami skontaktować telefonicznie (w godzinach 8-16) lub wysłać nam wiadomość przez e-mail, a my udzielimy Ci wsparcia przy rozwiązaniu problemu.





Czy można samodzielnie przetestować DBPLUS Performance Monitor™?


Możesz ściągnąć z naszej strony wersję instalacyjną naszego oprogramowania i używać pełnej wersji przez okres 30 dni. Jeżeli po 30 dniach nie będziesz chciał się zdecydować na wykupienie licencji w pełnej wersji to program automatycznie przełączy się w tryb wersji bezpłatnej, gdzie zaawansowane funkcje są niedostępne, ale możliwe jest monitorowanie podstawowych parametrów wydajnościowych.





Jaki jest model licencyjny DBPLUS Performance Monitor™?


DBPLUS Performance Monitor™ zarówno w wersji dla Oracle® i dla Microsoft™ SQL Server® jest obecnie licencjonowany per monitorowana instancja.





Czy używanie DBPLUS Performance Monitor™ jest bezpieczne dla mojej bazy danych?


Nasze narzędzie jest w pełni bezpieczne dla bazy danych. Nic samodzielnie nie zmienia w bazie danych i nie generuje zauważalnego obciążenia. Używanie naszego narzędzia nigdy nie skutkuje utratą danych, spowolnieniem działania czy naruszeniem jakichkolwiek postanowień licencyjnych aplikacji korzystających z bazy.



Q&A




1. W jaki sposób sprawdzić, które bazy danych pracują na danym serwerze?


W celu sprawdzenia, które bazy danych znajdują się na danym serwerze należy przejść do ekranu Dashboard. Z listy PHYSICAL SERVERS należy wybrać serwer, a następnie wszystkie bazy danych na wybranym serwerze zostaną wyszczególnione poniżej.







2. Czy na ekranie Dashboard widać obciążenie poszczególnych baz danych lub że bazy te są niedostępne?


Dashboard daje możliwości sprawdzenia obciążenia w poszczególnych bazach danych.

Poprzez zmianę widoku na Television mode. Z tego poziomu widać obciążenie CPU serwera, czas trwania blokad oraz waitów w czasie rzeczywistym.



Wybranie bazy danych z listy ORACLE INSTANCES umożliwi podgląd statystyk wydajnościowych za ostatnie 15 minut. Odświeżanie danych wykonywane jest w odstępach 30 sekundowych dla CPU, Waits, Waits details, Sessions. Pozostałe funkcjonalności odświeżane są co 15 minut.



Ekran Dashboard informuje o niedostępności bazy poprzez zaznaczenie jej na szaro:







3. Czy da się ustawić własne alerty?


W celu ustawienia własnych alertów należy przejść do zakładki Configuration > Alert settings > Alerts definition. Alerty można definiować na 2 poziomach:
• ogólnym
• dla poszczególnych baz danych.

W celu zdefiniowania własnego alertu należy kliknąć w pole Add new alert.



W nowo otwartym oknie w zależności od potrzeb można zdefiniować własny alert.







4. W jaki sposób wygenerować raport z obciążenia bazy danych?


W celu wygenerowania raportu z obciążenia bazy danych należy przejść do zakładki Reports > Performance report. Następnie ustawić zakres daty i nacisnąć Run Report. Wygenerowany raport zawiera TOP11 poleceń:
• Najdłużej trwających
• Najdłużej wykorzystujących CPU
• Czytających najwięcej z dysku twardego
• Czytających najwięcej z bufora danych
• Najczęściej uruchamianych
Oraz:
• Czas trwania blokad na każdą godzinę
• Top 10 najdłużej trwających Waitów oraz Latchy w bazie danych









5. W jaki sposób sprawdzić, ile CPU jest wykorzystywanych przez bazę danych a ile przez wszystkie procesy na serwerze?


W celu sprawdzenia, ile CPU wykorzystuje baza, a ile serwer należy przejść do ekranu Performance > Database load. Po najechaniu kursorem na wykres widać wartości za okres 15 minut. Jest to między innymi CPU Time (wykorzystanie CPU przez bazę danych) oraz Server CPU (wykorzystanie CPU przez wszystkie procesy na serwerze).



W celu sprawdzenia, ile CPU używa serwer, a ile ma ich do dyspozycji należy przejść do zakładki Performance > OS Stat. W tabeli poniżej należy zaznaczyć kolumny CPU number oraz Busy Time. Wykres będzie przestawiał CPU zajęte przez serwer na tle wszystkich przydzielonych CPU w wybranym okresie.







6. Czy można sprawdzić, ile pamięci RAM ma serwer a ile jest przypisane do bazy danych?


W celu sprawdzenia, ile pamięci RAM jest zaalokowane przez bazę danych należy przejść do zakładki Parameters > Parameters Overview. W polu Param name należy wpisać SGA oraz odszukać z listy SGA_MAX_SIZE. Wartość parametru określa pamięć przypisaną dla bazy danych.



Następnie należy przejść do zakładki Memory > SGA. Na ekranie widać, ile pamięci RAM jest używane, ile wolne (SGA TOTAL). Widać również wielkość poszczególnych składowych pamięci SGA.



W celu sprawdzenia, ile pamięci RAM ma serwer, należy przejść do zakładki Performance > OS Stat. Z tabeli poniżej należy wybrać kolumnę Physical Memory. Na wykresie widać ilość pamięci RAM na serwerze.







7. W jaki sposób sprawdzić wielkość oraz przyrost bazy danych?


Do sprawdzenia wielkości oraz przyrostu bazy danych należy przejść do zakładki Space monitor > Database size. Na ekranie widać całkowitą, wolną oraz zajętą przestrzeń w bazie danych w danym okresie. Dodatkowo w sekcji DATABASE GROWTH widać przyrost w ostatnim dniu, tygodniu oraz miesiącu.







8. W jaki sposób sprawdzić wielkość oraz przyrost tablespace?


Informacje o wielkości bazy danych, przestrzeni tabel, plików danych znajdują się w zakładce Space monitor. Funkcjonalność Last Snap Tablespace Size pokazuje graficznie oraz w tabeli najnowsze dane o wielkości każdej przestrzeni tabel znajdujących się w bazie danych.



Takie same informacje można uzyskać z poziomu ekranu Dashboard. Należy wybrać bazę danych, następnie Database space.



Przyrost przestrzeni tabel w zakresie wybranych dat należy sprawdzić w zakładce Space monitor > Tablespace history. Jest możliwość ustawienia zakresu daty oraz wyboru konkretnej przestrzeni tabel.







9. W jaki sposób sprawdzić ustawienie poszczególnych parametrów bazy danych oraz ich zmian w danym okresie?


W celu sprawdzenia ustawień poszczególnych parametrów bazy danych należy przejść do zakładki Parameters. Ekran wyświetla wszystkie parametry w bazie danych wraz z ustawioną wartością. Po wybraniu parametru poniżej pojawi się historia zmian.



Ekran Parameters > Parameters History przedstawia listę wszystkich zmian parametrów za wyznaczony okres. Jest możliwość wyselekcjonowania danego parametru wpisując jego nazwę lub wartość.







10. Jak znaleźć najbardziej obciążające I/O zapytania?


W celu odnalezienia poleceń najbardziej obciążających I/O należy wejść w zakładkę Performance > SQL 3D.

Szukając pod kątem odczytów – należy ustawić Draw bar na Disk Reads aby zobaczyć najbardziej obciążające zapytania pod kątem odczytów z urządzeń dyskowych.



Szukając pod kątem zapisów – należy rozwinąć belkę Show additional filters i wybrać Log generating statements aby wyświetlić najbardziej obciążające zapytania pod kątem zapisu.







11. Która sesja zmienia najwięcej rekordów a w konsekwencji generuje problem UNDO GLOBAL?


W celu sprawdzenia, która sesja generuje problem UNDO GLOBAL należy przejść do zakładki Sessions > Undo usage sessions. Następnie posortować malejąco kolumnę Used records. Sesja z największą liczbą procesowanych rekordów jest przyczyną problemów.



W celu analizy problemu w danym okresie należy przejść do zakładki Session / Undo history oraz ustawić zakres dat. Po wybraniu punktu w czasie należy wybrać poniżej zakładkę Undo i posortować malejąco kolumnę Used records. Sesja z największą liczbą procesowanych rekordów jest przyczyną problemów.







12. Jak sprawdzić która sesja dokonuje najwięcej zmian w bazie danych?


W celu sprawdzenia która sesja dokonuje najwięcej zmian w bazie danych należy przejść do zakładki Sessions > Undo usage sessions. Następnie posortować malejąco kolumnę Used records. Sesja z największą liczbą procesowanych rekordów dokonuje najwięcej zmian w bazie danych.







13. Jak sprawdzić co jest odpowiedzialne za generowanie latchy związanych z shared_pool?


W celu sprawdzenia co generuje latche shared pool należy przejść do zakładki Performance > Latches > Latch library cache. W sekcji SHARED POOL STATEMENTS widać listę zapytań z literałami wraz z ilością wykorzystywanej pamięci shared pool. Jest również ujęta liczba wersji zapytania.
Literały które w największym stopniu wykorzystują pamięć są przyczyną latchy shared_pool.







14. Jak sprawdzić obciążenie bazy danych w okresie 2 lat?


W celu analizy obciążenia bazy danych w okresie ostatnich 2 lat należy przejść do zakładki Performance > Load trends. Następnie ustawić zakres daty za ostatnie 24 miesiące oraz ustawić grupowanie po miesiącu. Domyślnie widać wykres Elapsed time, który przedstawia czas trwania wszystkich poleceń w bazie danych za wybrany okres w wybranym grupowaniu czasu (15 minut, dzień, miesiąc).







15. Jak sprawdzić, kto uruchamiał dane zapytanie?


W celu sprawdzenia, kto uruchamia dane zapytanie należy przejść do zakładki Sessions > Session / Undo history. Po wpisaniu w polu Using Query Hash identyfikatora zapytania poniżej pojawi się lista wszystkich sesji które uruchamiały zapytanie w wybranym okresie.







16. Jak sprawdzić statystyki wydajnościowe dla danego zapytania?


W celu sprawdzenia statystyk wydajnościowych danego zapytania należy przejść do zakładki Performance > SQL Details. Po wpisaniu identyfikatora zapytania lub wybraniu go z listy w sekcji SQL STATISTICS pojawią się statystyki wydajnościowe za wybrany okres.
Istnieje możliwość grupowania wyników po miesiącu, dniu, godzinie oraz snapie (15 minut).







17. Jak sprawdzić plan wykonania dla danego zapytania?


W celu sprawdzenia planu wykonania należy przejść do zakładki Performance > SQL Details. Po wpisaniu identyfikatora zapytania lub wybraniu go z listy na samym dole w zakładce Explain plan pojawi się plan wykonania.



Zdarza się że zapytanie używa więcej niż jednego planu wykonania. Po zaznaczeniu pola Compare Plans pojawia się drugi plan wykonania. W ten sposób można wyszczególnić różnice i znaleźć przyczynę wolnego działania na danym planie wykonania.



Plan wykonania można również sprawdzić dla aktywnej sesji. W tym celu należy przejść do zakładki Sessions. Po zaznaczeniu sesji poniżej pojawi się tekst wykonywanego zapytania oraz plan wykonania.







18. Jak sprawdzić, ile zapytań używa danego planu wykonania?


W celu sprawdzenia, ile zapytań używa danego planu wykonania należy wybrać polecenie w zakładce SQL Details, a następnie kliknąć Add to SQL plan.



Następnie należy przejść do zakładki SQL Plan i wybrać dodany wcześniej plan wykonania z listy po lewej stornie. Pojawia się ogólna statystyka wydajnościowa dla danego planu wykonania oraz po wybraniu zakładki Statements using plan widać wszystkie zapytania używające danego planu wykonania.







19. Jak sprawdzić czy bufor pamięci bazy danych jest skonfigurowany w AUTO czy MANUAL?


Rodzaj konfiguracji pamięci znajduje się w zakładce Memory > SGA, w polu SGA Usage.







20. Na jakie wartości są ustawione poszczególne składowe buforów pamięci bazy danych?


Poszczególne składowe buforów pamięci znajdują się w zakładce Memory > SGA w sekcji CURRENT MEMORY UTILIZATION. Po najechaniu kursorem na składową na wykresie pojawi się jej wartość.







21. W jaki sposób sprawdzić historię ustawień parametrów SGA?


W celu sprawdzenia historii parametrów ustawień SGA należy przejść do zakładki Memory > SGA History. Widać zajętość poszczególnych elementów SGA za wybrany okres.







22. Które sesje najbardziej wykorzystują przestrzeń tabel do sortowania?


W celu sprawdzenia która sesja najbardziej wykorzystuje przestrzeń do sortowania należy przejść do zakładki Sessions > Sort usage sessions. Widać zajętość przestrzeni do sortowania oraz listę sesji korzystających z przestrzeni. Następnie w celu wyświetlenia szukanych sesji należy posortować malejąco kolumnę Space Used.







23. Czy w bazie danych występują literały, a jeśli tak to czy stanowią problem?


W celu sprawdzenia czy w bazie danych występują literały należy przejść do zakładki Performance > Latches > Latch library cache. W sekcji SHARED POOL STATEMENTS widać listę zapytań z literałami wraz z ilością wykorzystywanej pamięci shared pool.



Literały sprawiają problem, jeżeli w bazie danych pojawiają się latche typu SHARED POOL. W celu sprawdzenia występowania latchy tego typu należy przejść do zakładki Waits > Analyze, następnie ustawić zakres daty oraz grupowanie. W sekcji WAIT STATISTICS należy wyszukać wait latch: shared pool. Jeżeli czas trwania oczekiwania jest na znikomym poziomie w stosunku do czasu trwania wszystkich procesów – nie występuje problem z literałami.







24. Czy problem wydajnościowy występuje z powodu złego działania bazy danych czy źródło problemu jest poza bazą danych np. w serwerze lub macierzy dyskowej?


Wyróżnia się kilka problemów wydajnościowych które nie mają swojej przyczyny w bazie danych:
• Problemy sieciowe
• Przetwarzanie po stronie aplikacji
• Wolne działanie macierzy dyskowej

W celu sprawdzenia czy w bazie istnieje problem z długim oczekiwaniem na odpowiedź z sieci należy przejść do zakładki Waits > Overview, następnie kliknąć wybrany punkt na wykresie. Jeżeli w bazie na wysokim poziomie występuje wait TCP Socket (KGAS) – występuje problem na sieci. Najczęściej występujące waity widać poniżej wykresu.



Problem może również leżeć po stronie macierzy dyskowej. Aby to sprawdzić, należy przejść do zakładki I/O Stats > I/O Analyze, następnie wybrać odpowiednio kolumny Writes/Reads oraz Write time/Read time w zależności od badanej operacji. Jeżeli nie widać wzrostu odczytów/zapisów, a czas tych operacji znacznie się wydłuża to problem leży po stronie hardware lub inne procesy na serwerze z poza bazy danych obciążają macierz dyskową.







25. W jaki sposób sprawdzić które zapytania są najbardziej obciążające bazę danych w określonej kategorii np. CPU, Executions itp.?


W celu odszukania najbardziej obciążających zapytań należy przejść do zakładki Performance > SQL 3D. Następnie w polu Draw bar należy wybrać kategorię w jakiej zapytania obciążają bazę, ustawić datę oraz pogrupować wynik na dzień, miesiąc lub snap (15 minut). Poniżej na wykresie 3D wyświetlą się najbardziej obciążające zapytania. W celu analizy jednego z nich należy kliknąć na dane zapytanie, następnie View SQL detail, co otworzy zakładkę SQL details.



W zakładce Performance > SQL details zobaczymy tekst zapytania, statystyki wykonania za dany okres oraz plan wykonania zapytania. Istnieje możliwość grupowania statystyk wydajnościowych po snapie (15 minut), godzinie, dniu oraz miesiącu.







26. Czy można zobaczyć jakie indeksy są zbudowane na danej tabeli?


W zakładce Performance > SQL Details po wybraniu zapytania na dolnym ekranie pokaże się plan wykonania. Należy kliknąć w show plan objects:



Na ekranie widać wszystkie obiekty użyte w zapytaniu. W celu sprawdzenia jakie indeksy znajdują się na danej tabeli należy kliknąć w nazwę tabeli, a po prawej stronie pojawi się lista zbudowanych na niej indeksów. Po kliknięciu w indeks na samym dole pojawią się użyte w nim kolumny.







27. Jak znaleźć zapytania używające danego indeksu lub tabeli?


W celu odnalezienia zapytań na podstawie użytych obiektów należy przejść do zakładki Performance > SQL Details, a następnie kliknąć znajdujący się po prawej stronie przycisk Find SQL:



Następnie przejść do zakładki Statements using objects i wpisać nazwę obiektu. Na dole pojawi się lista zapytań używających wskazanego obiektu wraz z podstawowymi statystykami wydajnościowymi za dany okres.







28. Jak znaleźć zapytania które zmieniły plan wykonania?


W celu odszukania które zapytania zmieniły plan wykonania należy przejść do zakładki Performance > SQL Details, a następnie kliknąć znajdujący się po prawej stronie przycisk Find SQL:



Następnie należy wybrać zakładkę Plan Flip-Flop Statements. Po odświeżeniu pojawi się lista poleceń które zmieniły plan wykonania w danym okresie.







29. Jak porównać wydajność dni lub okresów ze sobą?


W celu porównania wydajności kilku dni należy przejść do zakładki Performance > Compare > Compare Days. Następnie wybrać dni do porównania i dodać je do listy. Wykres zawiera dane wydajnościowe z każdego dodanego dnia pogrupowane po snapie lub godzinie. Porównywać można po czasie trwania wszystkich zapytań, CPU, executions, rowsprocessed, fetches, disk reads, buffer gets.



W celu porównania określonych okresów czasu należy przejść do zakładki Performance > Compare > Compare Periods. Następnie wybrać dwa interesujące nas okresy. Wykres zawiera dane wydajnościowe dla każdego okresu czasu. Porównywać można czas trwania procesów w bazie danych, CPU, executions, fetches, rowsproccesed, disk reads, buffer gets.







30. Które zapytanie generuje latch: cache buffer chains?


W celu odnalezienia zapytania generującego latch: cache buffer chains należy przejść do zakładki Performance > Latches > Buffer Latches. Po zaznaczeniu na wykresie danego punktu w czasie poniżej pojawi się lista zapytań odczytujących najwięcej bufforów. Należy sprawdzić które zapytanie ma największe Buffer Utilization. Będzie ono odpowiedzialne za pojawianie się latch: cache buffer chains.







31. Jak sprawdzić, kto generował problem wydajnościowy o 2 w nocy (sesje i zapytania)?


W celu sprawdzenia, kto spowodował problem wydajnościowy o 2 w nocy należy przejść do zakładki Performance > Database load. Następnie wybrać na wykresie godzinę 2 w nocy. Jeżeli widać wzrost wykorzystania serwera bazy danych należy sprawdzić na liście poniżej jakie zapytanie było za to odpowiedzialne.



Następnie w celu sprawdzenia kto uruchamiał to polecenie należy przejść do zakładki Sessions > Session / Undo history. Następnie należy wpisać identyfikator zapytania i wyszukać kto je uruchamiał około godziny 2:00.







32. Jak sprawdzić czy w danym okresie występowały blokady? Jeśli występowały to kto był blokerem a kto blokowanym?


W pierwszej kolejności należy przejść do zakładki Performance > Waits. Po kliknięciu w dany punkt na wykresie, odszukać w sekcji wait z „enq” w nazwie. Jeżeli taki występuje, wówczas należy przejść do Locks > Locks history.



W pierwszej kolejności należy sprawdzić czy nie pojawiają się waity pod kątem zapisu, tj. log file sync, db file parallel write, log file paralel write, free buffer busy. W tym celu przechodzimy do zakładki Performance > Waits > Analyze. Następnie należy wyszukać i zaznaczyć wskazane waity.



Przy sesji blokującej znajduje się strzałka z możliwością zwijania pozostałych sesji poniżej. Sesje blokowane natomiast można zwinąć do sesji blokującej.





33. Czy w mojej bazie istnieje problem z zapisem?


W pierwszej kolejności należy sprawdzić czy nie pojawiają się waity pod kątem zapisu, tj. log file sync, db file parallel write, log file paralel write, free buffer busy. W tym celu przechodzimy do zakładki Performance > Waits > Analyze. Następnie należy wyszukać i zaznaczyć wskazane waity.



Następnie należy przejść do ekranu I/O Stats > I/O Analyze. Po ustawieniu takiego samego zakresu daty jak wcześniej dla waitów dyskowych należy zaznaczyć kolumny Writes, Write time. Jeżeli w punkcie wzrostu waitu rośnie również write time, a przy tym liczba zapisów nie ulega wzrostowi – problem leży po stronie macierzy dyskowej. Jeżeli natomiast liczba zapisów rośnie – należy odszukać polecenie które zapisało w tym okresie najwięcej danych do macierzy.

Oczywiście jeśli czas zapisu pojedynczego 8K bloku danych jest na poziomie większym niż 0,004 sekundy wówczas świadczy to o wolnej obsłudze I/O i problemu należy szukać poza bazą danych. Dla macierzy SSD czas odczytu pojedynczego 8K bloku jest na poziomie 0,003 sekundy.



W celu znalezienia zapytania, które zapisało najwięcej danych do macierzy należy przejść do zakładki Performance > SQL 3D, rozwinąć belkę Show additional filters i wybrać Log generating statements. Wyświetlone zapytania są najbardziej obciążające pod kątem zapisu do macierzy dyskowej.







34. Czy w mojej bazie istnieje problem z odczytem danych?


W celu analizy czy występują problemy z odczytem należy przejść do zakładki I/O Stats > I/O Analyze. Następnie ustawić zakres daty, ziarnistość, oraz zaznaczyć z tabeli poniżej kolumny Reads oraz Read time. Jeżeli na wykresie rośnie czas odczytywania danych, a przy tym liczba odczytów nie ulega wzrostowi – istnieje problem z odczytem po stronie macierzy dyskowej. Jeżeli natomiast liczba odczytów również rośnie – należy odszukać polecenie które odczytało w tym okresie najwięcej danych, a co za tym idzie spowodowało problemy z odczytem.

Oczywiście jeśli czas odczytu pojedynczego 8K bloku danych jest na poziomie większym niż 0,003 sekundy wówczas świadczy to o wolnej obsłudze I/O i problemu należy szukać poza bazą danych. Dla macierzy SSD czas odczytu pojedynczego 8K bloku jest na poziomie 0,0002 sekundy.



W tym celu odszukania które zapytanie przeczytało najwięcej danych z macierzy należy przejść do zakładki Performance > SQL 3D, ustawić Draw bar na Disk Reads. Wyświetlone zapytania są najbardziej obciążające pod kątem odczytu do macierzy dyskowej.







35. Ile procent obciążenia stanowi dane zapytanie lub stanowią dane zapytania?


W celu sprawdzenia w jakim procencie zapytanie obciąża bazę, należy wybrać zakładkę Performance > SQL Details. Po wpisaniu identyfikatora zapytania pojawi nam się treść, statystyka wykonania za dany okres, oraz plan wykonania. Na dolnej zakładce należy wybrać Graph, oraz zaznaczyć Database load for Elapsed Time. Na wykresie widać czas trwania polecenia oraz jego procentowy udział na tle wszystkich zapytań w bazie danych.



W celu sprawdzenia w jakim stopniu kilka wybranych zapytań obciąża bazę należy przejść do zakładki PERFORMANCE > SQL Analyze. Na wykresie widać czas trwania wszystkich zaznaczonych poniżej poleceń na tle wszystkich zapytań w bazie danych.







36. Czy da się podstawić do zapytań ze zmiennymi literały?


W celu podstawienia literałów pod zmienne należy w pierwszej kolejność przejść do zakładki Performance > SQL Details. Po wybraniu zapytania należy zaznaczyć pole Online value. Następnie na samym dole planu wykonania pojawią się wartości podstawiane pod zmienne wraz z ich typem danych. Następnie należy dopasować wartości do zmiennych w treści zapytania.