Najczęściej zadawane pytania (FAQ)

Zapoznaj się z pytaniami zadanymi przez innych użytkoników i sprawdź, czy znajdziesz szukaną odpowiedź. Nie widzisz odpowiedzi na Twoje pytanie? Zawsze możesz zapytać!

performance monitor
data replicator
usługi
partnerzy
ogólne

Pytania ogólne

Czy dajecie wsparcie do bezpłatnego testu waszego oprogramowania?

Kiedy chcesz przetestować nasze oprogramowanie 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ł 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 przetestować DBLUS 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 wersji pełnej, program automatycznie przełączy się w tryb wersji bezpłatnej, gdzie zaawansowane funkcje są niedostępne, możliwe jest jednak monitorowanie podstawowych parametrów wydajnościowych.

Jaki jest model licencyjny DBPLUS Performance Monitor?

DBPLUS Performance Monitor w zarówno w wersji dla Oracle jak i SQL Server jest obecnie licencjonowany per instancja bazy danych.

Czy używanie DBPLUS Performance Monitora 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.

Performance Monitor dla Oracle®

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 RAM ma serwer a ile jest przypisanego 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.

Performance Monitor dla Microsoft® SQL Server®

1. W jaki sposób sprawdzić które instancje sql pracują na danym serwerze?

W celu sprawdzenia jakie instancje znajdują się na danym serwerze należy rozpocząć od ekranu Dashboard. Na liście PHYSICAL SERVERS należy wybrać serwer, a następnie wszystkie instancje na wybranym serwerze zostaną wyszczególnione poniżej.

2. Czy na dashbord widać obciążenie poszczególnych instancji SQL lub że instancje te są nie dostępne?

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

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 SQL INSTANCES umożliwi podgląd statystyk wydajnościowych z okresu ostatnich 15 minut.

Ekran Dashboard informuje nas o niedostępności instancji 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 instancji.

W celu zdefiniowania własnego alertu należy kliknąć w przycisk 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 instancji SQL?

W celu wygenerowania raportu 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 utylizujących CPU
• Czytających najwięcej z dysku twardego
• Czytających najwięcej z buffora 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 utylizowanych przez serwer SQL a ile przez wszystkie procesy na serwerze?

W celu sprawdzenia ile CPU utylizuje instancja, 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 (utylizacja CPU przez instancje) oraz Server CPU (utylizacja CPU przez wszystkie procesy na serwerze).

6. Czy można sprawdzić ile RAM ma serwer a ile jest przypisanego dla serwera SQL?

W celu uzyskania informacji o ilości przypisanej pamięci RAM należy przejść do zakładki Memory>Memory usage. Widać ile pamięci RAM jest używane przez instancje, a ile wolnej pamięci posiada serwer (TOTAL SERVER MEMORY) oraz w jakich proporcjach pamięć została podzielona (Memory Utilization).

7. W jaki sposób sprawdzić wielkość instancji SQL lub poszczególnych baz danych?

Do sprawdzenia wielkości instancji należy przejść do zakładki Space monitor > Current space. Na ekranie widać całkowitą, wolną, oraz zajętą przestrzeń w instancji.

W celu sprawdzenia wielkości dla poszczególnych baz danych należy pogrupować wynik po bazie danych:

8. W jaki sposób sprawdzić przyrost instancji SQL lub poszczególnych baz danych?

W celu sprawdzenia przyrostu instancji historycznie należy przejść do zakładki Space monitor > History. Na ekranie widać całkowitą, wolną, oraz zajętą przestrzeń w instancji za wybrany okres czasu. W celu sprawdzenia przyrostu dla poszczególnych baz danych należy pogrupować wynik po bazie danych.

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

W celu sprawdzenia ustawień poszczególnych parametrów instancji należy przejść do zakładki Parameters > Instance Parameters > Server Configuration Parameters Overview. 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 czasu. Jest możliwość wyselekcjonowania danego parametru wpisując jego nazwę lub wartość.

10. W jaki sposób sprawdzić ustawienie poszczególnych parametrów baz danych na instancji SQL oraz ich zmian w danym okresie czasu?

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


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

11. 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. Należy ustawić Draw bar na Disk Reads aby zobaczyć najbardziej obciążające zapytania pod kątem odczytów z macierzy dyskowej.

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

W celu sprawdzenia która sesja dokonuje najwięcej zmian w instancji należy przejść do zakładki Sessions > Log usage sessions. Następnie należy posortować malejąco kolumnę Log record count. Sesja z największą liczbą dokonuje najwięcej zmian.

13. Które zapytania zapisują najwięcej bloków danych do pamięci?

W celu odnalezienia poleceń odpowiedzialnych za latch typu shared_pool należy przejść do zakładki Performance > SQL 3D. Następnie ustawić Draw bar na Buffer Writes aby zobaczyć zapytania zapisujące najwięcej danych do pamięci.

14. Jak sprawdzić obciążenie instancji SQL w okresie 2 lat?

W celu analizy obciążenia instancji 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 instancji.

15. Jak sprawdzić do której bazy danych zapytania generują największe obciążenie?

W celu sprawdzenia do której bazy danych zapytania generują największe obciążenie należy przejść do zakładki Performance > SQL Analyze. Klikając w zakładkę Database Load i sortując tabele malejąco po kolumnie Elapsed Time wyświetlimy listę najbardziej obciążonych baz danych.

Drugim sposobem na sprawdzenie do której bazy zapytania generują największe obciążenie jest przejście do zakładki Performance > Instance load. Następnie w prawym górnym rogu należy kliknąć All databases. Pojawi się zestawienie na którym widać udział w obciążeniu każdej bazy danych za wybrany okres czasu.

16. Jak sprawdzić kto uruchamiał dane zapytanie?

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

17. 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 dany okres czasu.
Istnieje możliwość grupowania wyników po miesiącu, miesiącu, godzinie oraz snapie (15 minut).

18. Jak sprawdzić plan wykonania dla danego zapytania?

W celu sprawdzenia planu wykonania należy przejść do zakładki Performance > SQL Detail. 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.

19. W jakim stopniu pamięć na serwerze jest wykorzystana przez instancje SQL?

W celu weryfikacji w jakim stopniu pamięć na serwerze jest wykorzystywana przez instancje należy przejść do zakładki Memory > Memory usage. Po prawej stronie ekranu znajduje się wykres na którym widać:
• ilość dostępnej pamięci RAM oraz jej wykorzystanie przez wszystkie procesy działające na serwerze (słupek wykresu w niebieskiej ramce)
• ilość pamięci używanej przez instancje SQL (słupek wykresu w zielonej ramce)

20. Jak sprawdzić, czy instancja SQL w pełni wykorzystuje przydzieloną pamięć?

W celu weryfikacji czy instancja SQL w 100% wykorzystuję przydzieloną pamięć należy przejść do zakładki Memory > Memory usage. Następnie należy porównać wartość Max Server memory z używaną przez instancje pamięcią. Dodatkowo należy zweryfikować czy poszczególne obszary pamięci (sekcja Memory Utilization for last snapshot) sumują się do całego rozmiaru pamięci – wtedy wiemy że SQL używa przydzieloną pamięć w 100%.

21. Na jakie wartości są ustawione poszczególne obszary pamięci instancji?

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

22. W jaki sposób sprawdzić historię ustawień parametrów pamięci?

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

23. Które sesje najbardziej utylizują przestrzeń tymczasową tempdb?

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

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 instancji, tj:
• Przetwarzanie po stronie aplikacji
• Wolne działanie macierzy dyskowej

Przyczyna problemu często leży w długim oczekiwaniu po stronie aplikacji. Skutkiem są blokady. Sesja blokująca po stronie instancji jest nieaktywna i nic nie wykonuje czekając na commit / odpowiedź z aplikacji. W celu analizy takiego problemu należy przejść do zakładki Locks > Locks history. Jeżeli na wykresie widać długotrwałe blokady, a sesja blokująca cały czas ma Status SLEEPING, to jest to problem długim oczekiwaniem na odpowiedź z aplikacji.

Problem może również leżeć po stronie macierzy dyskowej. W celu dokonania takiej weryfikacji 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 posób sprawdzić które zapytania są najbardziej obciążające instnacje SQL w określonej kategorii np: CPU, Eecutions itd.?

W celu weryfikacji 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, statystykę 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 weryfikacji 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. W kolumnie Index columns znajdują się kolumny na których został założony indeks. Po kliknięciu w niego na dole pojawią się szczegółowe informacje o kolumnach.

27. Jak znaleźć zapytania używające danej 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 prawie przycisk Find SQL:

Następnie należy przejść do zakładki Statement by text i wpisać nazwę tabeli. Na dole pojawi się lista zapytań używających wskazanej tabeli wraz z podstawowymi statystykami wydajnościowymi za dany okres czasu.

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

W celu weryfikacji które zapytania zmieniły plan wykonania należy przejść do zakładki Performance > SQL Detail, a następnie kliknąć znajdujący się po prawie 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 czasu.

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 Trends > Compare Days. Następnie wybrać dni które do porównania i dodać je do listy. Wykres zawiera dane wydajnościowe z każdego dodanego dnia pogrupowane po snapie lub godzinie.

W celu porównania określonych okresów czasu należy przejść do zakładki Performance > Compare trends > Compare Periods. Następnie wybrać dwa interesujące nas okresy. Wykres zawiera dane wydajnościowe dla każdego okresu.

30. Jak sprawdzić kto generował problem wydajnościowy o 2 w nocy – sesje i zapytanie?

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

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

31. Jak sprawdzić czy w danym okresie występowały blokady? Jeśli występowały to kto był blokującym a kto blokowanym? Gdzie leży problem (po stronie instancji SQL czy aplikacji)?

W pierwszej kolejności należy przejść do zakładki Performance > Waits. Po kliknięciu w dany punkt na wykresie, odszukujemy w sekcji poniżej wait z „LCK” w nazwie. Jeżeli taki jest, należy postępować według dalszych instrukcji.

Następnie należy przejść do zakładki Locks > Locks history. Wykres przedstawia czas oczekiwania sesji oraz liczbę sesji w blokadzie w danym okresie czasu. Po kliknięciu w punkt pojawi się lista sesji blokujących oraz blokowanych.

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.
Problem leży po stronie instancji kiedy sesja blokująca jest aktywna i wykonuje polecenia w bazie danych. Natomiast kiedy sesja blokująca jest uśpiona (status sleeping), problem leży po stronie aplikacji.

32. Czy w instancji SQL istnieje problem z zapisem?

W pierwszej kolejności należy sprawdzić czy nie pojawiają się waity pod kątem zapisu, tj. writelog. W tym celu przechodzimy do zakładki Performance > Waits > Analyze. Następnie należy wyszukać i zaznaczyć wskazany wait.

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 Wites, 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.

W tym celu odszukania które zapytanie zapisało najwięcej danych do macierzy należy przejść do zakładki Performance > SQL 3D. Następnie ustawić Draw bar na Buffer Writes. Wyświetlone zapytania są najbardziej obciążające pod kątem zapisu do macierzy dyskowej.

33. Czy w mojej instancji SQL istnieje problem z odczytem danych?

W pierwszej kolejności należy sprawdzić czy nie pojawiają się waity dyskowe pod kątem odczytu, tj pageiolatch_sh. W tym celu przechodzimy do zakładki Performance > Waits > Analyze. Odszukujemy wait pageiolatch_sh.

Następnie przechodzimy do ekranu I/O Stats > I/O Analyze. Ustawiamy taki sam zakres daty jak wcześniej dla waitu pageiolatch_sh. Jeżeli w punkcie wzrostu waitu rośnie również read time, a przy tym liczba odczytów nie ulega wzrostowi – problem leży po stronie macierzy dyskowej.

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

W celu sprawdzenia w jakim procencie zapytanie obciąża instancje należy wybrać zakładkę Performance > SQL Details. Po wpisaniu identyfikatora zapytania pojawi nam się treść, statystyka wykonania za danych 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 instancje należy przejść do zakładki Performance > SQL Analyze. Na wykresie widać czas trwania wszystkich zaznaczonych poniżej poleceń na tle wszystkich zapytań w instancji.

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

Zasoby

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 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.

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®.

Potrzebujesz więcej informacji?

Zadzwoń do nas, skorzystaj z czatu na Skype lub wyślij e-mail. Odpowiemy na Twoje pytania i udzielimy Ci wsparcia w korzystaniu z naszych rozwiązań.

Zadzwoń do nas:

Polska +48 22 389 7324
8:00 – 16:00

Wsparcie online:

Polska +48 22 389 7324
8:00 – 16:00

Oświadczam, że jestem osobą pełnoletnią i zapoznałe(a)m się z Regulaminem Serwisu dbplus.tech, spełniam i akceptuję jego postanowienia.

Wyrażam zgodę na przetwarzanie moich danych osobowych w związku z przystąpieniem do serwisu dbplus.tech przez DBPLUS w celach marketingowych, w tym informowaniu o produktach i usługach DBPLUS. Przysługuje Ci prawo do cofnięcia zgody w dowolnym momencie bez wpływu na zgodność z prawem przetwarzania, którego dokonano na podstawie zgody.
Regulamin serwisu