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.

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.

DBPLUS Performance Monitor w wersjach dla Oracle, Microsoft SQL Server i PostgreSQL jest obecnie licencjonowany per instancja 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 oprogramowania nigdy nie skutkuje utratą danych, spowolnieniem działania czy naruszeniem jakichkolwiek postanowień licencyjnych aplikacji korzystających z bazy.

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.

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:

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.

1. ogólnym
2. dla poszczególnych baz 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

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 numberoraz Busy Time. Wykres będzie przestawiał CPU zajęte przez serwer na tle wszystkich przydzielonych CPU w wybranym okresie.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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 planwidać wszystkie zapytania używające danego planu wykonania.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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

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

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

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:

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.

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

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

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.

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.

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.

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.

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.

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.

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

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.

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)

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

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

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.

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.

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ładkiI/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ą.

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.

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 columnsznajdują się kolumny na których został założony indeks. Po kliknięciu w niego na dole pojawią się szczegółowe informacje o kolumnach.

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.

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.

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.

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.

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.

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.

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.

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.