Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



07.08.2019

Kurzinformation it-sa, 8-10...

It-sa is one of the leading international trade fairs for IT security. With around 700...
08.07.2019

Narzędzie EDR

ESET Enterprise Inspector
08.07.2019

Usuwanie skutków awarii

Veeam Availability Orchestrator v2
08.07.2019

Indywidualna konfiguracja

baramundi Management Suite 2019
05.07.2019

Technologia Ceph

SUSE Enterprise Storage 6
05.07.2019

Szybkie i bezpieczne...

Konica Minolta bizhub i-Series
05.07.2019

Edge computing

Atos BullSequana Edge
04.07.2019

Terabitowa ochrona

Check Point 16000 i 26000
04.07.2019

Obsługa wideokonferencji

Poly G7500

Analiza zdarzeń zgłaszanych przez serwer SQL

Data publikacji: 22-03-2019 Autor: Marcin Szeliga
Rys. 2. Przykład analizy...

Serwery baz danych są na tyle skomplikowanymi programami, że nawet zdefiniowanie wartości brzegowych i analiza zależności między wartościami poszczególnych liczników wydajności nie zawsze pozwalają zidentyfikować przyczyny problemów wydajnościowych. Dlatego w tej części uzupełnimy naszą analizę o informacje zgłaszane przez sam serwer SQL.

 

W dwóch poprzednich częściach artykułu przedstawiono metodę zbierania danych o wydajności serwerów przy użyciu systemowego monitora wydajności oraz sposób analizy tak zebranych danych za pomocą programu Power BI. Przeprowadzona ocena nominalnej wydajności serwera pozwoliła nam zbudować kluczowe wskaźniki wydajności, dzięki którym mogliśmy na bieżąco monitorować wydajność serwera SQL mierzoną zużyciem zasobów systemowych.

Przykłady, w tym szablon z definicjami liczników monitora wydajności, plik Power BI z raportami oraz skrypty SQL są dostępne pod adresem github.com/szelor/SQL-Server-Performance-Monitoring.

> MECHANIZM ROZSZERZONYCH ZDARZEŃ

Mechanizm rozszerzonych zdarzeń XE (Extended Events) został wprowadzony w wersji 2008 serwera SQL Server. Wtedy do kodu serwera SQL zostały dodane punkty, których wykonanie powoduje zgłoszenie określonego zdarzenia, na przykład zakończenia wykonywania instrukcji SQL, zapisanie danych do pliku dziennika transakcyjnego czy wystąpienie zakleszczenia. Mechanizm rozszerzonych zdarzeń jest odpowiedzialny za przechwytywanie takich zdarzeń. Informacje opisujące zdarzenia są zbierane w ramach sesji XE i mogą być zapisane w pamięci lub plikach. Co ważne, koszt przechwytywania zdarzeń jest bardzo mały, co czyni mechanizm XE idealnym rozwiązaniem do monitorowania wydajności mocno obciążonych serwerów.

Mechanizm rozszerzonych zdarzeń został ulepszony i rozbudowany w kolejnych wersjach serwera SQL. Przede wszystkim dodane zostały następne zdarzenia i narzędzia ułatwiające definiowanie sesji oraz odczytywanie zgromadzonych danych. Poznawanie tego mechanizmu zaczniemy od odczytania zdarzeń przechwyconych przez systemową sesję system_health.

Sesja system_health jest automatycznie uruchamiana podczas włączania serwera SQL Server i przechwytuje zdarzenia, które mogą mieć bezpośredni wpływ na jego działanie. Są to m.in.: błędy krytyczne, błędy związane z brakiem pamięci RAM i długotrwałym wykonywaniem żądań użytkowników, zakleszczenia i długotrwałe oczekiwania. W plikach system_health*.xel przechowywane są informacje o 5000 ostatnio zgłoszonych zdarzeń, część tych danych znajduje się również w buforze pamięci o wielkości 4 MB. Jeżeli bufor zostanie zapełniony, najstarsze zdarzenia są z niego automatycznie usuwane.

Informacje o zdarzeniach zapisywane są w formacie XML. Przekształcić je na postać tabelaryczną można przy użyciu funkcji XML serwera SQL. Poniższe instrukcje zwracają nazwy i czasy wystąpienia wszystkich zdarzeń przechwyconych przez sesję system_health i zapisanych w plikach sesji.

SELECT
events.event.value('@timestamp', 'datetime') AS EventTime,
events.event.query('.').value('(/event/@name)[1]', 'varchar(255)') as EventName
FROM (
SELECT convert(xml, event_data) AS event_data
FROM sys.fn_xe_file_target_read_file('system_health*.xel', NULL, NULL, NULL)
) AS system_health
CROSS APPLY system_health.event_data.nodes('/event') AS events(event);

Zwracane przez te instrukcje wyniki użyjemy jako źródła kolejnego zapytania zasilającego danymi raport Power BI – SQL Server Performance.pbix. W tym celu należy je wkleić w okienku opcji zaawansowanych źródła danych SQL Server. Po kliknięciu OK zobaczymy wycinek tabeli o dwóch kolumnach: w kolumnie EventName będą się znajdować nazwy zdarzeń, a w kolumnie EventTime – czasy ich zgłoszenia. Na razie nie będziemy modyfikować tych danych, a więc możemy je załadować do modelu.

W pierwszej kolejności sprawdzimy, ile różnych zdarzeń zostało zgłoszonych i jak często były one zgłaszane. Do nowej strony raportu dodamy, tak samo jak do poprzednich, niestandardową kontrolkę TimeLine. Pozwoli nam ona wybrać interesujący nas zakres dat.

Następnie utworzymy tabelę SystemHealthSession z trzema kolumnami: EventName, liczbą EventTime i liczbą (wartość odrębna) EventTime. W ten sposób w pierwszej kolumnie zobaczymy nazwy zdarzeń, w drugiej częstotliwość ich występowania (czasy wystąpienia zdarzeń zostały zaimportowane z dokładnością do sekund), a w trzeciej liczbę wystąpień danego zdarzenia. Te informacje pozwolą nam sprawdzić, czy i jak często serwer baz danych zgłasza zdarzenia, które mają bezpośredni wpływ na jego wydajność. Na przykład jak często występują zakleszczenia albo jak często serwer SQL musiał odebrać dostęp do procesorów długo wykonywanym sesjom użytkowników. Wyszukując w internecie nazwy zaobserwowanych zdarzeń, znajdziemy ich opisy oraz odpowiedzi na pytania, czy dane zdarzenie jest problematyczne i jak można ten problem rozwiązać.

Poniżej tabeli dodamy wykres warstwowy zgrupowany. Po umieszczeniu na jego osi X czasu zgłoszenia zdarzenia, a na osi Y (osi wartości) i w polu legendy nazwy zdarzenia będziemy mogli przeanalizować częstotliwość występowania poszczególnych zdarzeń w czasie.

Połączenie danych zebranych przez liczniki wydajności z danymi zarejestrowanymi przez sesję rozszerzonych zdarzeń wymaga wykonania kilku dodatkowych kroków. Potrzebna nam będzie tabela kalendarza zawierająca wszystkie daty, w których były zbierane dane. Na potrzeby przykładu przyjęliśmy jako jednostkę czasu minutę, czyli będziemy mogli analizować dane z dokładnością do minut. Taką tabelę można utworzyć jako tabelę wyliczeniową. Wystarczy dodać do modelu nową tabelę i skopiować do okienka edytora DAX poniższe wyrażenie. Daty początkowa i końcowa zostały zaznaczone pogrubieniem.

 

[...]
 

Pracownik naukowy Wyższej Szkoły Bankowej w Poznaniu Wydział Zamiejscowy w Chorzowie; jest autorem książek poświęconych analizie danych i posiada tytuł Microsoft Most Valuable Professional. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"