• Artykuł

Microsoft SQL Server 2008

Rozszerzone zdarzenia w SQL Server 2008 Udostępnij na: Facebook

Autor: Damian Widera

Opublikowano: 17 lipca 2008

Serwer SQL 2008 udostępnił administratorom baz danych mechanizm rozszerzonych zdarzeń służący do monitorowania systemów serwerowych. Jego infrastruktura pozwala na korelowanie informacji nie tylko pochodzących z serwera SQL, ale także – pod pewnymi warunkami – na korelowanie informacji pochodzących z systemu operacyjnego czy innych aplikacji.

Zawartość strony
Koncepcja i charakterystyka mechanizmu rozszerzonych zdarzeń   Koncepcja i charakterystyka mechanizmu rozszerzonych zdarzeń
Architektura rozwiązania   Architektura rozwiązania
Działanie mechanizmu rozszerzonych zdarzeń   Działanie mechanizmu rozszerzonych zdarzeń
Wsparcie dla mechanizmu rozszerzonych zdarzeń w serwerze SQL 2008.   Wsparcie dla mechanizmu rozszerzonych zdarzeń w serwerze SQL 2008.
Przykład rozwiązania praktycznego   Przykład rozwiązania praktycznego

Serwer SQL 2008 udostępnił administratorom baz danych doskonałe narzędzie służące do monitorowania systemów serwerowych. Tym narzędziem jest mechanizm rozszerzonych zdarzeń (ang. Extended events - XE), którego infrastruktura pozwala na korelowanie informacji nie tylko pochodzących z serwera SQL, ale także – pod pewnymi warunkami – na korelowanie informacji pochodzących z systemu operacyjnego czy innych aplikacji. W tym drugim, bardziej złożonym przykładzie, zdarzenia pochodzące z mechanizmu XE muszą zostać skierowanie do systemu śledzenia zdarzeń dla Windows (ang. Event Tracing for Windows - ETW ) i tam zostaną powiązane ze zdarzeniami pochodzącymi z innych aplikacji czy systemu operacyjnego.

Głównymi zaletami mechanizmu zdarzeń rozszerzonych są:

  a) Ścisła integracja ze zdarzeniami systemu Windows – administratorzy mogą śledzić jądro systemu Windows od momentu, kiedy działał będzie serwer SQL

  b) Niski koszt przechwytywania zdarzeń, co czyni mechanizm XE idealnym rozwiązaniem także dla dużych systemów produkcyjnych

  c) Krótki czas zdiagnozowania problemów występujących w serwerze baz danych, takich jak np. wąskie gardła – zamiast pracochłonnego przeglądania czy analizowania plików zarejestrowanych narzędziem SQL Server Profiler

  d) Natychmiastowa agregacja danych pochodzących ze zdarzeń, która odbywa się w pamięci procesu, co z kolei pozwala na zaszycie w tej pamięci pewnej logiki, która w odpowiedni sposób zareaguje na uzyskany wynik

  e) Konfigurowalność – administrator może utworzyć sesję zbierającą dane zależne od środowiska, w którym została ta sesja utworzona. Sesje mogą zostać utworzone za każdym razem, gdy zostaje uruchomiony serwer SQL

Koncepcja i charakterystyka mechanizmu rozszerzonych zdarzeń

Silnik mechanizmu rozszerzonych zdarzeń pozwala na przyjęcie każdego rodzaju zdarzenia i przesłanie go do każdego typu odbiorcy. Silnik ten, niezwykle uniwersalny, nie jest ograniczany w żaden sposób przez treść, dane lub informacje zawarte w każdym z przechwyconych zdarzeń. Implikacje tej uniwersalności są naprawdę daleko idące, bo pozwalają odbiorcom (konsumentom) zdarzeń na uruchamianie własnych, dynamicznie konstruowanych akcji, jako odpowiedzi na otrzymane tą drogą informacje. Wynika z tego, że same zdarzenie nie jest świadome akcji, która została mu przypisana w kontekście odbiorcy. Mechanizm rozszerzonych zdarzeń wprowadza także predykaty, które umożliwiają filtrowanie zdarzeń tak, aby odbiorca nie został zalany nadmiarem informacji, która nie jest mu potrzebna. Mechanizm rozszerzonych zdarzeń może generować informacje o przechwyconych zdarzeniach synchronicznie, ale rozsyłać je w sposób asynchroniczny, co czyni go najbardziej elastycznym rozwiązaniem dla obsługi zdarzeń i pozwala w praktyce wyeliminować jego wpływ na pracę serwera SQL.

Podsumowując krótkie wprowadzenie do mechanizmu rozszerzonych zdarzeń można nakreślić jego charakterystykę:

  a) Jest uniwersalnym rozwiązaniem do przechwytywania zdarzeń, które mają miejsce w systemach serwerowych, w pełni oparty o T-SQL

  b) Pozwala użytkownikom wyizolować interesujące ich zdarzenie i wykorzystać informacje w nim zawarte np. dla celów diagnostycznych

  c) Jest w pełni zintegrowane i wspierane przez narzędzia ETW

  d) Może dynamicznie monitorować aktywne procesy i jednocześnie w minimalny sposób mieć na nie wpływ

 Do początku strony Do początku strony

Architektura rozwiązania

Architektura mechanizmu rozszerzonych zdarzeń nie jest skomplikowana i została zaprezentowana na rys.1 poniżej. Moduł jest to zewnętrzna, dowolna aplikacja, która będzie wysyłała informacje o istotnych z jej punktu widzenia zdarzeniach. Modułem może być także biblioteka w formacie pliku .dll, jednakże dla administratorów serwera SQL 2008 najistotniejszym będzie monitorowanie procesów zawartych w aplikacji sqlserver.exe.

Rysunek 1: Architektura systemu rozszerzonych zdarzeń.

Paczki (ang. packages) są kontenerami dla obiektów mechanizmu rozszerzonych zdarzeń i mogą zawierać zero lub więcej takich obiektów, jak:

  a) Zdarzenia

  b) Odbiorcy zdarzeń

  c) Akcje

  d) Typy

  e) Predykaty

  f) Mapy

Obiekty z różnych paczek mogą być pomiędzy nimi wykorzystywane w ramach jednej tzw. sesji monitorowania zdarzeń (ang. event session). Konfiguracja kontenera - paczki nie może zmienić się po tym, jak została zarejestrowana dla danego modułu, tzn. sesja monitorowania zdarzeń została włączona. Paczkę identyfikują dwa atrybuty - jej nazwa i niepowtarzalny ciąg znaków, który w serwerze SQL jest definiowany przez GUID (uniqueidentifier). Serwer SQL 2008 definiuje trzy domyślne paczki:

  a) sqlos – oferuje niskopoziomowe zdarzenia interakcji z systemem operacyjnym,

  b) sqlserver – oferuje zdarzenia odpowiadające w większości licznikom monitora systemowego,

  c) package0 – zawiera typy danych, operatory porównania, akcje (podejmowane w odpowiedzi na zdarzenia), mapy (odpowiednik enumeracji w językach programowania, np. tryb I/O dla pliku), docelowe obiekty (targets), które mogą być w jakikolwiek sposób związane z przechwytywanymi zdarzeniami (dzięki tym obiektom można zdefiniować np. zapisywanie zdarzeń do plików).

Trzy paczki są jedynymi, które są dostępne dla mechanizmu rozszerzonych zdarzeń i administrator nie ma obecnie możliwości dodawania własnych paczek.

Zdarzenia są informacją, iż określony punkt kodu w aplikacji został osiągnięty oraz niosą informację o tym punkcie taką jak informacja o stanie aplikacji w danym momencie czy czasie wystąpienia samego zdarzenia. Mogą być wykorzystywane dla celów diagnostycznych lub uruchamiać zdefiniowane przez użytkownika akcje. Każde zdarzenie posiada wersjonowany schemat określający jego zawartość. Każde zdarzenie określonego typu musi generować zawsze dokładnie taką samą strukturę informacji, jaka została określona w jego schemacie. Jednakże odbiorcy zdarzenia nie muszą wykorzystywać wszystkich informacji, które to zdarzenie ze sobą niesie.

Mechanizm zdarzeń rozszerzonych używa modelu kategoryzacji zdarzeń podobna do zastosowanego w ETW, w którym każdemu zdarzeniu odpowiadają dwie własności – kanał (ang. channel) oraz słowo kluczowe (ang. keyword). Kanał identyfikuje krąg odbiorców dla danego zdarzenia, co ma zasadniczy wpływ nie tylko na ilość otrzymywanych informacji, ale także na poziom szczegółowości w nich zawarty. Mechanizm rozszerzonych zdarzeń definiuje 4 kanały:

  a) Debug, który jest przeznaczony w zasadzie wyłącznie dla programistów, którzy będą musieć diagnozować problemy na podstawie uzyskanej informacji. Prezentowane informacje niosą ze sobą najwyższy poziom szczegółowości

  b) Analityczny (ang. analytic), który charakteryzuje się tym, że publikuje ogromne ilości zdarzeń opisujących operacje wykonywane przez aplikację. Z tego względu zdarzenia należące do kategorii analitycznej posłużą do diagnozowania wydajności monitorowanej aplikacji

  c) Operacyjny (ang. operational), do którego napływają informacje, na podstawie których zostaną uruchomione akcje czy zadania, ale także do analizowania stanu aplikacji i diagnozowania problemów w niej występujących

  d) Administracyjny (ang. admin), który jest najistotniejszym kanałem punktu widzenia użytkowników końcowych czy administratorów systemów. Zdarzenia, które można znaleźć w tym kanale wskazują nie tylko problem, który zaistniał w aplikacji, ale również podają sposób na jego rozwiązanie. Przykładem informacji, która może zostać odnaleziona w kanale administracyjnym jest problem z drukarką. Zdarzenie informujące o tej sytuacji, oprócz precyzyjnej diagnozy, podaje także odnośnik do dokumentacji, w której znaleźć można przepis, jak ten problem rozwiązać czy nawet uniknąć go w przyszłości

Słowa kluczowe są specyficzne dla aplikacji i pomagają pogrupować zdarzenia tak, aby łatwiej otrzymać tylko te, które są potrzebne dla wykonania dalszej analizy. Poniższe zapytanie, korzystające z widoku dynamicznego sys.dm_xe_map_values wyświetla listę wszystkich słów kluczowych dostępnych w mechanizmie rozszerzonych zdarzeń.

SELECT map_value  

FROM sys.dm_xe_map_values

WHERE name = ‘keyword_map’

ORDER BY map_value

Odbiorcy zdarzeń przetwarzają zdarzenia na dwa sposoby. Pierwszy z nich – synchroniczny, używany jest w sytuacji, kiedy ważna jest kolejność przetwarzania nadchodzących zdarzeń. Jest to jednak sposób nieco bardziej obciążający serwer zwłaszcza w sytuacji, kiedy liczba zdarzeń tak obsługiwanych będzie duża. Jest to związane właśnie z modelem rozszerzonych zdarzeń, w którym każdy odbiorca może zdefiniować akcje dla otrzymywanych zdarzeń lub przetwarzać je w zasadzie w dowolny sposób. Asynchroniczne przetwarzanie zdarzeń jest z punktu widzenia serwera procesem mało obciążającym, gdyż zdarzenia są najpierw gromadzone w specjalnym buforze a następnie rozsyłane do oczekujących ich odbiorców. Proces rozsyłania zdarzeń uruchamiany jest w tle w sytuacji, kiedy istnieje odpowiednia pula zasobów do wykonania tego zadania.

Akcje można zdefiniować jako programową odpowiedź bądź odpowiedzi na pojawienie się zdarzenia bądź zdarzeń. Akcje są połączone do zdarzeń, a każde zdarzenie może posiadać zestaw unikalnych akcji, które są do niego przypisane i są wywoływane synchronicznie w wątku, który uruchomił zdarzenie. Serwer SQL definiuje wiele rodzajów akcji, przez co spektrum możliwych zastosowań jest w zasadzie ograniczone tylko pomysłowością użytkownika. Do przykładowych akcji, możliwych do wykonania w odpowiedzi na wystąpienie zdarzenia, można zaliczyć:

  a) Zagregowanie danych z wielu zdarzeń

  b) Przesłanie dodatkowych danych do zdarzenia

  c) Przechowanie informacji o stanie aplikacji

  d) Analiza danych pochodzących ze zdarzenia

Typy pozwalają na poprawną interpretację danych otrzymanych z silnika rozszerzonych zdarzeń. Takie dane są przesłane jako jeden łańcuch znaków, a więc długość i charakterystyka poszczególnych jego części jest niezwykle istotna dla poprawnej interpretacji uzyskanej informacji. W dalszej części tego rozdziału opisaliśmy, w jaki sposób uzyskać informacje o wszystkich zdefiniowanych typach w mechanizmie rozszerzonych zdarzeń.

Predykaty są zestawem logicznych reguł, które są użyte podczas przetwarzania zdarzenia. Pozwala to na wyselekcjonowanie i przesłanie tylko tych zdarzeń, które spełniają podane przez użytkownika kryteria. Filtrowanie nie jest jedyna funkcjonalnością, którą oferują obiekty predykatów. Można także przechować wewnątrz takiego obiektu – w jego kontekście – dane dotyczące zdarzenia i przekazywać je dalej po n minutach lub n wystąpieniach. Predykaty mogą także uzyskiwać dane zawarte w zdarzeniu oraz inne informacje, które są dostępne w ramach kontekstu, tj. identyfktor wątka. Fakt, iż predykat jest w stanie przechować informacje o zdarzeniach w swoim lokalnym kontekście jest bardzo użyteczny, gdyż można to wykorzystać do jego aktualizacji, co może spowodować, że zdarzenie, które do tej pory było przez predykat przepuszczane, po aktualizacji będzie filtrowane.

Mapy są obiektami, a ściślej mówiąc tablicami, które zamieniają jedną wartość (np. cyfrę) na inny ciąg znaków, np. opis. Zastosowanie takich tablic ma swoje uzasadnienie oszczędzając chociażby ilość danych, które należy zawrzeć w zdarzeniu. Dzięki takiemu podejściu użytkownik może otrzymać informacje w sposób łatwy do interpretacji, tj. zamiast kolejnych liczb czy skrótów będzie mógł uzyskać opisy, które tym liczbom czy skrótom odpowiadają.

 Do początku strony Do początku strony

Działanie mechanizmu rozszerzonych zdarzeń

Działanie mechanizmu rozszerzonych zdarzeń opiera się o sesje monitorowania zdarzeń. Sesje te są tworzone i zarządzane w procesie serwera SQL. W ramach sesji następuje zbieranie informacji o zdarzeniach, a konfiguracja sesji obejmuje tworzenie paczek, odbiorców, akcji, predykatów – obiektów, które opisane zostały wcześniej w tym artykule. Każda z sesji posiada trzy podstawowe własności, a są to:

  a) Stan sesji

  b) Zawartość sesji

  c) Charakterystyka sesji

Stan sesji

Stan sesji mechanizmu rozszerzonych zdarzeń jest kontrolowany za pomocą poleceń DDL (ang. data definition language ), takich jak CREATE EVENT SESSION czyALTER EVENT SESSION. Sesja mechanizmu rozszerzonych zdarzeń może znajdować się w jednym z czterech stanów, jak pokazano na rys.2 poniżej

Rysunek 2: Stany sesji rozszerzonych zdarzeń.

Odnosząc się do powyższego rysunku można zauważyć, że stan sesji zmienia się w zależności od wykonanego polecenia DDL.

Pierwszym poleceniem, które musi zostać wykonane, jest polecenie CREATE EVENT SESSION, które pozwala na utworzenie definicji sesji. Metadane uzyskane w wyniku wykonania tej operacji są zapisywane w bazie danych master. Ze względu na fakt, że definicja sesji może zawierać m.in. listę zdarzeń, które mają być obserwowane oraz listę akcji, które powinny być wykonane jako odpowiedź na przechwycone zdarzenie, to sesja jest nieaktywna po wykonaniu tego polecenia DDL.

Polecenie CREATE EVENT SESSION posiada następującą składnię:

CREATE EVENT SESSION event_session_name

ON SERVER

{

<event_definition> [ ,...n]

[ <event_target_definition> [ ,...n] ]

[ WITH ( <event_session_options> [ ,...n] ) ]

}

;

Składania polecenia tworzącego sesję jest dość rozbudowana, ponieważ zawiera aspekty całej konfiguracji, a więc administrator musi mieć możliwość dodawania zdarzeń, definiowania odbiorców oraz akcji, określania predykatów, typów i map. Dokładne informacje na temat tego polecenia dostępne są w internecie, w Microsoft Books Online pod adresem https://msdn.microsoft.com/en-us/library/bb677289(SQL.100).aspx .

Z punktu widzenia administratora bardzo ciekawe informacje kryją się pod fragmentem składni WITH ( <event_session_options> [,...n] ), w którym należy zdefiniować istotne, mające wpływ na pracę całego mechanizmu rozszerzonych zdarzeń, opcje:

  a) Maksymalną ilość pamięci możliwą do zaalokowania w ramach sesji podczas operacji buforowania

  b) Określenie trybu retencji zdarzeń – jest to jedna z ważniejszych opcji, ponieważ administrator może wskazać, że dopuszcza utratę czy to pojedynczego zdarzenia w ramach sesji, czy dopuszcza utratę całego bufora ze zdarzeniami lub nie pozwala na utratę zdarzeń. Ustawienie tej opcji ma duży wpływ na wydajność całego mechanizmu rozszerzonych zdarzeń, a wartością domyślną jest zezwolenie na utratę pojedynczego zdarzenia. Najmniejszy wpływ na wydajność ma ustawienie opcji pozwalającej utracić cały bufor z zapisanymi zdarzeniami, ale ta opcja powinna być ustawiona w momencie, kiedy system otrzymuje dużo zdarzeń, które są generowane bardzo często i ich utrata nie ma wpływu w zasadzie na działanie pozostałych części aplikacji

  c) Podanie maksymalnego czasu, przez który zdarzenia będą buforowane w pamięci przed wysłaniem ich do odbiorców

  d) Określenie maksymalnego rozmiaru danych, które może dostarczyć zdarzenie.

  e) Określić stan sesji po jej utworzeniu. Domyślnie sesja jest wyłączona, nieaktywna.

  f) Określić czy mają być śledzone związki przyczynowo-skutkowe. Domyślnie ta opcja jest wyłączona, a o politykach zarządzających tą opcją napisaliśmy w dalszej części rozdziału.

  g) Określenie miejsca, w którym zostaną utworzone bufory przechowujące zdarzenia. Domyślnie zestaw buforów jest tworzony przez wystąpienie serwera SQL, ale można również utworzyć bufory dla każdego procesora czy węzła NUMA.

Polecenie CREATE EVENT SESSION może wykonać jedynie użytkownik posiadający uprawnienia CONTROL SERVER.

Poleceniem, które włącza sesję i rozpoczyna proces przechwytywania zdarzeń jest polecenie ALTER EVENT SESSION, STATE=START. System odczytuje wtedy zapisane wcześniej metadane, sprawdza poprawność definicji sesji i potwierdza uprawnienia użytkownika do rozpoczęcia pracy z mechanizmem rozszerzonych zdarzeń. Obiekty zdefiniowane wewnątrz sesji zostaja załadowane (np. odbiorcy) i nie mogą już ulegać zmianom.

Trzecim stanem sesji jest jej zatrzymanie za pomocą polecenia ALTER EVENT SESSION, STATE=STOP. Proces przechwytywania zdarzeń jest zatrzymywany, a metadane pozostają w bazie danych master.

Dokładne informacje na temat polecenia ALTER EVENT SESSION dostępne są w internecie, w Microsoft Books Online pod adresem https://msdn.microsoft.com/en-us/library/bb630368(SQL.100).aspx

Ostatni, czwarty stan sesji usuwa ją, a ściślej mówiąc zatrzymuje (o ile była uruchomiona) i kasuje informacje o metadanych sesji. Operację usuwania sesji przeprowadza się wykonując polecenie DROP EVENT SESSION.

Dokładne informacje na temat tego polecenia dostępne są w internecie,w Microsoft Books Online pod adresemhttps://msdn.microsoft.com/en-us/library/bb630257(SQL.100).aspx

Zawartość sesji

Sesje mechanizmu rozszerzonych zdarzeń maja określone granice. Implikacja tego faktu powoduje, że jedna sesja nie może wpływać czy zmieniać konfiguracji innej sesji. Z drugiej jednak strony zdefiniowane ramy sesji nie zapobiegają przed użyciem zdarzeń czy odbiorców w innych, aktywnych, równolegle działających sesjach. Relacje pomiędzy paczkami a sesjami są to relacje wiele – do – wielu, czyli obiekt zdefiniowanych wewnątrz jednej paczki może pojawiać się w wielu sesjach i sesja może zawierać wiele obiektów.

Charakterystyka sesji

Nie wszystkie obiekty zdefiniowane w ramach sesji mogą być wykorzystane w innych sesjach. W szczególności to stwierdzenie jest prawdziwe dla akcje i predykatów, które są widoczne w granicach tylko jednej sesji. Można więc wyobrazić sobie dwie sesje, które definiują w sobie, że będą przechwytywały to samo zdarzenie ale przypisują mu różne akcje i odmienne predykaty. Akcje i predykaty nie będą miały wpływu na siebie, ponieważ istnieją w odrębnych sesjach.

Dodatkowo, każda sesja może dołaczyć polityki, które będą odpowiedzialne za zarządzanie buforami i rozsyłaniem informacji (ang. buffreing and dispatch) – w trybie asynchronicznym oraz polityki śledzenia związków przyczynowo-skutkowych (ang. causality tracking).

 Do początku strony Do początku strony

Wsparcie dla mechanizmu rozszerzonych zdarzeń w serwerze SQL 2008.

Serwer SQL 2008 wprowadzając mechanizm rozszerzonych zdarzeń, dostarcza również odpowiednie polecenia DDL umożliwiające tworzenie, modyfikację czy usuwanie sesji monitorowania rozszerzonych zdarzeń. Dynamiczne widoki oraz widoki katalogowe pomagają z kolei uzyskać informacje o konfiguracji sesji, architekturze mechanizmu rozszerzonych zdarzeń czy pozwalają wreszcie wyświetlić dane zawarte w przechwyconych zdarzeniach.

Dostęp do wszystkich informacji opisanych powyżej odbywa się z poziomu kodu T-SQL. Wyświetlenie informacji zawartych w dynamicznych widokach czy widokach katalogowych wymaga posiadania uprawnień VIEW SERVER STATE.

Dynamiczne widoki wspierające mechanizm rozszerzonych zdarzeń

Dynamiczne widoki odpowiadają logicznie architekturze mechanizmu rozszerzonych zdarzeń, ponieważ w zasadzie większość elementów tej architektury ma swoje odzwierciedlenie w odpowiednim widoku dynamicznym. W widokach tych można również znaleźć dane, które są przekazywane pomiędzy obiektami . Wszystkie widoki dynamiczne związane z tym mechanizmem utworzone są w schemacie sys i rozpoczynają się od dm_xe_. Do dyspozycji administratora pozostawiono następujące dynamiczne widoki zarządcze:

  a) sys.dm_xe_objects

  b) sys.dm_xe_object_columns

  c) sys.dm_xe_packages

  d) sys.dm_xe_sessions

  e) sys.dm_xe_session_events

  f) sys.dm_xe_session_targets

  g) sys.dm_xe_session_event_actions

  h) sys.dm_xe_session_object_columnsv

  i) sys.dm_xe_map_values

Pierwszy z przytoczonych widoków – sys.dm_xe_objects zwraca po jednym wierszu dla każdego obiektu zdefiniowanego w paczce. Zgodnie z modelem architektury mechanizmu XE otrzymamy informacje o obiektach takich jak zdarzenia, akcje, odbiorcy, predykaty oraz typy, ale nie otrzymamy informacji o mapach. Pole name informuje o nazwie obiektu, w polu object_type zawarta jest wspomniana wcześniej informacja o jego typie, pole package_guid przechowuje identyfikator paczki, który można wykorzystać w innych widokach dynamicznych (np. sys.dm_xe_packages) dla otrzymania informacji o samej paczce. Każdy obiekt może mieć również opis nadany przez jego twórcę i zawarty w polu description.

Najprostsze zapytanie wykonane na omawianym widoku dynamicznym ma więc postać – po jego wykonaniu otrzymaliśmy informacje o wszystkich zdarzeniach zapisanych we wszystkich zdefiniowanych paczkach.

SELECT  name

     ,object_type

     ,package_guid

     ,description

FROM sys.dm_xe_objects

WHERE object_type='event'

Dynamiczny widok sys.dm_xe_object_columns zwraca listę kolumn opisujących wszystkie obiekty znajdujące się w paczkach. Każdej kolumnie obiektu paczki odpowiada jeden wiersz w omawianym dynamicznym widoku, więc można stwierdzić, że ten widok definiuje na swego rodzaju schemat każdego obiektu. Jest to o tyle istotna informacja, że np. każde zdarzenie musi zwracać informacje dokładnie zgodne ze schematem zapisanym w tym widoku.

Kolejnym dynamicznym widokiem jest sys.dm_xe_packages, który przechowuje podstawowe informacje o paczkach dostępnych w systemie. Każda paczka jest identyfikowana poprzez swoją nazwę (kolumna name) oraz identyfikator (kolumna guid), po którym wykonuje się złączenie do innych widoków dynamicznych mechanizmu rozszerzonych zdarzeń, aby uzyskać bardziej szczegółowe informacje na temat paczki. Kolumna description przechowuje zwięzły opis paczki nadany przez je twórców. Wszystkie paczki są dynamicznie ładowane przez moduły do przestrzeni adresowej procesów. Identyfikator modułu oraz jego adres są także zawarte w widoku dynamicznym sys.dm_xe_packages.

Poniższe zapytanie pobiera podstawowe informacje z dynamicznego widoku sys.dm_xe_packages:

SELECT name

    , guid

    , description

    , module_guid

    , module_address    

FROM sys.dm_xe_packages

Dynamiczny widok sys.dm_xe_sessions przechowuje informacje o każdej aktywnej sesji mechanizmu rozszerzonych zdarzeń. Z punktu widzenia administratora baz danych ten widok ma pierwszorzędne znaczenie w sytuacji, kiedy istotne jest sprawdzenie w jaki sposób dana sesja została skonfigurowana, czyli nadaje się do celów diagnostycznych. Z tego właśnie względu przytoczono poniżej wszystkie informacje o kolumnach zawartych w tym widoku:

  a) addres – adres sesji w pamięci procesu, jest to wartość unikalna w ramach całego lokalnego systemu.

  b) name – unikalna wewnątrz lokalnego systemu nazwa sesji

  c) buffer_size – podaje rozmiar każdego bufora w pamięci użytego do przechowania zdarzeń w ramach sesji

  d) pending_buffers – liczba pełnych buforów będących w stanie oczekiwania na przetwarzanie (rozsyłanie informacji do odbiorców)

  e) total_buffers –liczba buforów przydzielonych do sesji

  f) buffer_policy_flags – bitmapa określająca zachowanie bufora w momencie, kiedy jest on pełny a w ramach sesji przechwycono kolejne zdarzenie

  g) buffer_policy_desc – opis zachowania bufora w momencie, kiedy jest on pełny a w ramach sesji przechwycono kolejne zdarzenie. Dopuszczalne opisy to: drop event, do not drop events, drop full buffer oraz allocate new buffer

  h) flags – bitmapa określająca flagi, które zostały nadane sesji

  i) flag_desc – opis flag nadanych sesji. Kolumna może zawierać kombinację następujących fraz: flush buffer on close, dedicated dispatcher lub allow recursive events

  j) dropped_event_count – zawiera liczbę niezapisanych zdarzeń w sytuacji, kiedy bufory były pełne

  k) dropped_buffer_count – zawiera liczbę buforów, które zostały usunięte w sytuacji, kiedy bufory były pełne

  l) blocked_event_fire_time – podaje czas, w trakcie którego mechanizm rozszerzonych zdarzeń nie mógł zapisać danych w buforach ponieważ były one pełne

  m) create_time – podaje czas utworzenia sesji

  n) largest_event_dropped_size – przechowuje rozmiar największego zdarzenia, które nie zmieściło się do bufora sesji

Kolejne trzy widoki dynamiczne opisują zachowanie obiektów wewnątrz sesji. Pierwszy z nich – sys.dm_xe_session_events zwraca informacje o zdarzeniach, jakie będą przechwytywane w ramach aktywnej sesji. Ten widok przechowuje również informacje o predykatach, które muszą być spełnione, aby zdarzenie mogło zostać zapisane w buforze sesji. Predykat jest zapisany w kolumnie event_predicate w formacie XML. Widok dynamiczny sys.dm_xe_session_event_actions zwraca informacje o akcjach przypisanych do określonych zdarzeń. Ostatnim widokiem powiązanym z samą sesją jest widok sys.dm_xe_session_targets zwracający informacje o opisanych przez nas szczegółowo odbiorcach funkcjonujących w ramach aktywnej sesji. Ciekawostką jest, że można z tego widoku otrzymać informację o całkowitym czasie (podanym w milisekundach) przetwarzania informacji, które ma miejsce w odbiorcy zdarzenie. Informacja ta jest zapisana w kolumnie execution_duration_ms. Drugą ciekawą informacją jest licznik zapisany w kolumnie execution_count przechowujący informacje o ilości wykonania procesu przetwarzania w danym obiekcie odbiorcy. Ostatnia kolumną wartą uwagi w widoku sys.dm_xe_session_targets jest kolumna target_data, wewnątrz której zapisane są informacje zarządzane przez odbiorców, takie jak zagregowane informacje o zdarzeniach.

Dynamiczny widok sys.dm_xe_map_values jest w rzeczywistości tablicą map, która zamienia kody (w tym wypadku liczby całkowite) na łańcuchy znaków - opisy, które są łatwiejsze dla interpretacji przez użytkownika.

Widoki katalogowe wspierające mechanizm rozszerzonych zdarzeń

Widoki katalogowe przechowują informacje o metadanych tworzonych w momencie konfigurowania sesji monitorowania rozszerzonych zdarzeń.

Najbardziej rozbudowanym widokiem katalogowym odnoszącym się do mechanizmu rozszerzonych zdarzeń jest widok sys.server_event_sessions, który w każdym wierszu przechowuje konfigurację jednej utworzonej na serwerze SQL. W tym widoku katakogowym można znaleźć wszystkie informacje, które wskazaliśmy w komendzie CREATE EVENT SESSION.

Kolejny z widoków katalogowych – sys.server_event_session_events przechowuje informacje o każdym zdarzeniu, które zostało przypisane do określonej sesji. Z tego widoku można dowiedzieć się również, w jakiej paczce dane zdarzenie zostało zdefiniowane oraz jaki predykat użyto do filtrowania zdarzenia.

Podobne informacje – dotyczące oczywiście odpowiednich obiektów – są zawarte w widokach sys.server_event_session_actions oraz sys.server_event_session_targets. Nazwy tych widoków katalogowych są na tyle samo opisujące zawartość, że nie zostały omówione ich struktury w tym miejscu pozostawiając czytelnikowi zapoznanie się z nimi na własną rękę.

Ostatnim widokiem katalogowym przechowującym po jednym wierszu dla każdej kolumny, której wartość została ustawiona w zdarzeniu lub odbiorcy jest widok sys.server_events_session_fields. Widok ten przechowuje identyfikator sesji oraz trzy inne kolumny: identyfikator obiektu, z którym dane pole jest połączone, nazwę pola oraz wartość obiektu zachowaną w danym polu. Warto zauważyć, że nie wystarczyło zapisać tylko kolumny przechowującej identyfikator obiektu i należało dodać także kolumnę jednoznacznie identyfikującą sesję, w której dany obiekt został utworzony, ponieważ ten sam obiekt może istnieć w ramach wielu sesji.

 Do początku strony Do początku strony

Przykład rozwiązania praktycznego

W poniższym ćwiczeniu pokazaliśmy, w jaki sposób można użyć mechanizmu rozszerzonych zdarzeń w codziennej pracy z serwerem SQL 2008. Na prostym przykładzie dotyczącym analizowania zakładania blokad dla wskazanej bazy danych zaprezentowaliśmy, jak od podstaw zbudować sesję rozszerzonych zdarzeń oraz skonfigurować jej wszystkie obiekty. Operacje te zostały wykonane metodą krok po kroku tak, aby czytelnik po wykonani ćwiczenia mógł samodzielnie rozpocząć pracę z tą funkcjonalnością.

  1. Po zalogowaniu się do instancji serwera SQL należy w nowym oknie zapytania sprawdzić, czy istnieje już sesja o nazwie Sesja_LocksAcquired.

IF EXISTS(select * from sys.server_event_sessions where name='DemoStats')

DROP EVENT SESSION DemoStats ON SERVER

GO

  2. W drugim kroku ćwiczenia zdefiniowana została sesja rozszerzonych zdarzeń. W ramach sesji wstawiono informację o trzech zdarzeniach, w których będziemy odczytywać dane o założonych blokadach, ilości odczytów danych ze stron oraz ilości zakończonych operacji odczytywania pliku. Odbiorcą zdarzenia jest obiekt typu synchronous_object_counter, który będzie zliczał odpowiednie liczniki

CREATE EVENT SESSION DemoStats ON SERVER

ADD EVENT sqlserver.physical_page_read (

    ACTION (sqlserver.session_id)

    WHERE (sqlserver.session_id > 50)),

ADD EVENT sqlserver.file_read_completed (

    ACTION (sqlserver.session_id)

    WHERE (sqlserver.session_id > 50)),

ADD EVENT sqlserver.lock_acquired (

    ACTION (sqlserver.session_id)

    WHERE (sqlserver.session_id > 50))

ADD TARGET package0.synchronous_event_counter 

GO

  3.  Domyślnie sesja rozszerzonych zdarzeń jest wyłączona. Proces zbierania danych uruchamia się ustawiając stan za pomocą komendy ALTER EVENT SESSION własności STATE na START. Dodatkowo - czyszczone są także bufory, co wymusi pobieranie danych z dysku

DBCC DROPCLEANBUFFERS

GO



ALTER EVENT SESSION DemoStats ON SERVER

STATE=START

GO

  4.  Po uruchomieniu sesji system kolekcjonuje wszystkie zdefiniowane przez nas zdarzenia. Pora więc utworzyć testowe zapytanie, które wymusi różne typy blokad w serwerze SQL oraz pobierze dane do wyświetlenia. Zapytanie to wyświetla hierarchię pracowników oraz listę kontaktów dla każdego z nich i zostało wykonane w oparciu o mechanizm Common Table Expressions (CTE), który znany jest z poprzedniej wersji systemu i pozwala na wydajne tworzenie np. struktur drzewistych czy hierarchicznych.

-- 1. Hierarchia pracownikow oraz lista kontaktow

WITH [EMP_cte]([EmployeeID], [ManagerID], [FirstName], [LastName], [RecursionLevel]) 

  AS (

      SELECT e.[EmployeeID], e.[ManagerID], c.[FirstName], c.[LastName], 0

      FROM [HumanResources].[Employee] e 

          INNER JOIN [Person].[Contact] c 

          ON e.[ContactID] = c.[ContactID]

      WHERE [ManagerID] = 109 -- CEO

      UNION ALL

      SELECT e.[EmployeeID], e.[ManagerID], c.[FirstName], c.[LastName], [RecursionLevel] + 1

      FROM [HumanResources].[Employee] e 

          INNER JOIN [EMP_cte]

          ON e.[ManagerID] = [EMP_cte].[EmployeeID]

          INNER JOIN [Person].[Contact] c 

          ON e.[ContactID] = c.[ContactID]

      )

SELECT [EMP_cte].[RecursionLevel], [EMP_cte].[ManagerID], c.[FirstName] AS 'Imie', c.[LastName] AS ‘Nazwisko’,

       [EMP_cte].[EmployeeID], [EMP_cte].[FirstName], [EMP_cte].[LastName]

  FROM [EMP_cte] 

      INNER JOIN [HumanResources].[Employee]

      ON [EMP_cte].[ManagerID] = e.[EmployeeID]

      INNER JOIN [Person].[Contact] c 

      ON e.[ContactID] = c.[ContactID]

  ORDER BY [RecursionLevel], [ManagerID], [EmployeeID]

GO

  5.  Po uruchomieniu zapytania z pkt. 4 dane już zapisane i pozostaje je tylko właściwie przetworzyć i wyświetlić. Odbiorca typu synchronous_object_counter przechowuje informacje w formacie XML, a znaleźć je można w dynamicznym widoku sys.dm_xe_session_targets w kolumnie target_data. Złączenie wspomnianego tu widoku z dynamicznym widokiem sys.dm_xe_sessions pozwala na ograniczenie wyświetlonych informacji tylko dla interesującej nas sesji (której nazwa jest zapisane w kolumnie name) i typu odbiorcy. Przykład pliku XML zawierającego dane zdarzenia znajduje się poniżej:

<CounterTarget truncated="0">

  <Packages>

    <Package name="package0" />

    <Package name="sqlos" />

    <Package name="sqlserver">

      <Event name="lock_acquired" count="87593" />

      <Event name="physical_page_read" count="53" />

      <Event name="file_read_completed" count="8" />

    </Package>

    <Package name="SecAudit" />

  </Packages>

</CounterTarget>

  6. Zapytanie, które analizuje i wyświetla informacje zawarte w przykładowym pliku XML ma postać:

SELECT C.value('../@name', 'nvarchar(60)') as [nazwa paczki],

       C.value('@name', 'nvarchar(60)') as [nazwa zdarzenia],

       C.value('@count', 'int') as [ilosc]

 FROM (select cast(xest.target_data as xml) eventXml

          from sys.dm_xe_session_targets xest

          join sys.dm_xe_sessions xes 

            on xes.address = xest.event_session_address

         where xest.target_name = 'synchronous_event_counter' 

           and xes.name = 'DemoStats' ) R

CROSS APPLY eventXml.nodes('//Event') as T(C)

Po uruchomieniu zapytania na testowym serwerze uzyskano następujące wyniki:

nazwa paczki   nazwa zdarzenia    ilosc

------------   ---------------    ------

sqlserver      lock_acquired      87593

sqlserver      physical_page_read      53

sqlserver      file_read_completed     8

  7. Zatrzymanie sesji rozszerzonych zdarzeń dokonuje się za pomoca polecenia DDL ALTER EVENT SESSION, w którym należy zmienić stan własności STATE na STOP. Definicja i wsyztskie dane konfiguracyjne oraz dane zdarzeń pozostana w pamięci serwera i mogą być wykorzystane w poźniejszym czasie. Istnieje także drugie polecenie DDL – DROP EVENT SESSION, za pomoca którego można nie tylko zatrzymac, ale również uzunąć sesję i wszystkie infomacje o niej z systemu. W takim przypadku dane zostają utracone i nie mogą być wykorzystane w przyszłości.

DROP EVENT SESSION DemoStats ON SERVER
  Damian Widera, Project Manager & Team Lead (MCT, MCITP – DBA, MCSD.NET)
Od 8 lat zajmuje się projektowaniem, tworzeniem i wdrażaniem aplikacji wykorzystujących platformę .NET, SQL Server oraz Oracle. Obecnie pracuje jako project manager dla LGBS Polska. Pracował także jako trener, programista, administrator baz danych, twórca domumentacji oraz analityk biznesowy. Aktywnie współpracuje z polskim oddziałem Microsoft publikując atykuły, webcasty oraz porady z zakresu SQL Server na stronach TechNet. Jest współautorem książki „Serwer SQL 2008. Administracja i programowanie”.

Speaker na wielu konferencjach, m.in. Microsoft Heroes Happen Here, C2C, European PASS Conference, Microsoft Technology Summit, Energy Launch, TechED. Od 2004 r. posiada certyfikaty firmy Microsoft: MCT, MCITP–DBA oraz MCSD.NET. Jest współtwórcą oraz liderem jednej z najwiekszych grup pasjonatów SQL Server w Polsce – Śląskiej Regionalnej Grupy Microsoft (PLSSUG Katowice). Od listopada 2008 jest prezesem Polish SQL Server Users Group (PLSSUG) w Polsce. W styczniu 2009 nagrodzony tytułem MVP w kategorii SQL Server.
 Do początku strony Do początku strony

 

Microsoft SQL Server 2008