W trakcie monitorowania wydajności lub rozwiązywania problemów, takich jak powolność systemu, może być konieczne znalezienie lub przechwycenie zapytań, które mają długi czas trwania, wysoki procesor lub generują znaczące operacje we/wy podczas wykonywania. Możesz użyć DMV lub magazynu zapytań, aby uzyskać informacje o wydajności zapytań, ale informacje w obu źródłach są agregacją. DMV reprezentują średni procesor, we/wy, czas trwania itp. dla zapytania tylko tak długo, jak długo znajduje się w pamięci podręcznej. Query Store zapewnia również średnie metryki dla wielu zasobów, ale są one agregowane w określonym przedziale czasu (np. 30 minut lub godzinę). Istnieją oczywiście rozwiązania monitorujące innych firm, które są w stanie zapewnić ci to wszystko i więcej (takie jak SentryOne), ale w tym poście chciałem skupić się na narzędziach natywnych.
Jeśli chcesz zrozumieć wydajność zapytań dla poszczególnych wykonań, aby wskazać dokładne zapytanie lub zestaw zapytań, które mogą stanowić problem, najłatwiejszą opcją jest użycie zdarzeń rozszerzonych. Jednym z najszybszych sposobów na rozpoczęcie pracy jest użycie XEvent Profiler, który jest dostępny za pośrednictwem SQL Server Management Studio (od wersji 17.3):
XEvent Profiler w SSMS
Podstawowe zastosowanie
Istnieją dwie opcje programu XEvent Profiler:Standard i TSQL. Aby użyć jednego z nich, wystarczy dwukrotnie kliknąć nazwę. Za kulisami tworzona jest wewnętrznie zdefiniowana sesja zdarzenia (jeśli jeszcze nie istnieje) i uruchamiana, a przeglądarka danych na żywo natychmiast otwiera się z fokusem. Pamiętaj, że po rozpoczęciu sesji pojawi się ona również pod Zarządzanie | Wydarzenia rozszerzone | Sesje. Zakładając, że masz aktywność na serwerze, powinieneś zacząć wyświetlać wpisy w przeglądarce w ciągu pięciu sekund lub mniej.
Przeglądarka danych na żywo (po dwukrotnym kliknięciu, aby rozpocząć sesję standardową)
Sesje Standard i TSQL współdzielą niektóre zdarzenia, przy czym Standard ma w sumie więcej. Oto lista wydarzeń dla każdego z nich:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Jeśli chcesz zrozumieć informacje o wykonywaniu zapytania, takie jak czas wykonywania zapytania lub ilość zużytych operacji we/wy, opcja Standard jest lepszą opcją ze względu na dwa zakończone zdarzenia. W przypadku obu sesji jedynym filtrem jest wykluczenie zapytań systemowych dotyczących zdarzeń wsadowych, RPC i uwagi.
Wyświetlanie i zapisywanie danych
Jeśli uruchomimy sesję standardową i uruchomimy kilka zapytań, w przeglądarce zobaczymy zdarzenie, tekst zapytania i inne przydatne informacje, takie jak cpu_time, Logic_reads i czas trwania. Jedną z zalet używania rpc_completed i sql_batch_completed jest to, że pojawia się parametr wejściowy. W przypadku, gdy istnieje procedura składowana, która ma duże różnice w wydajności, przechwycenie parametru wejściowego może być niezwykle przydatne, ponieważ możemy dopasować wykonanie, które trwa dłużej, z określoną wartością przekazaną do procedury składowanej. Aby znaleźć taki parametr, musimy posortować dane według czasu trwania, czego nie możemy zrobić, gdy plik danych jest aktywny. Aby przeprowadzić jakąkolwiek analizę, przesyłanie danych musi zostać zatrzymane.
Zatrzymywanie źródła danych w przeglądarce na żywo
Teraz, gdy moje zapytania nie są już rozmyte, mogę kliknąć kolumnę czasu trwania, aby posortować moje wydarzenia. Pierwsze kliknięcie spowoduje posortowanie w porządku rosnącym, a ponieważ jestem leniwy i nie chcę przewijać dołu, kliknę ponownie, aby posortować w porządku malejącym.
Zdarzenia posortowane według czasu trwania malejąco
Teraz widzę wszystkie zarejestrowane przeze mnie zdarzenia w kolejności od najdłuższego do najdłuższego czasu trwania. Jeśli szukałem określonej procedury składowanej, która była powolna, mogłem albo przewinąć w dół, aż ją znajdę (co może być bolesne), albo pogrupować lub przefiltrować dane. Grupowanie jest tu łatwiejsze, ponieważ znam nazwę procedury składowanej.
Nazwa_obiektu jest wyświetlana w górnej części przeglądarki, ale kliknięcie dowolnego zdarzenia rpc_completed powoduje wyświetlenie wszystkich elementów przechwyconych w panelu Szczegóły. Kliknij prawym przyciskiem myszy nazwę_obiektu, która go podświetli, i wybierz opcję Pokaż kolumnę w tabeli.
Dodaj nazwę_obiektu do przeglądarki danych
W górnym panelu mogę teraz kliknąć prawym przyciskiem myszy nazwę_obiektu i wybrać Grupuj według tej kolumny. Jeśli rozwinę zdarzenia w usp_GetPersonInfo, a następnie posortuję ponownie według czasu trwania, teraz widzę, że wykonanie z PersonID=3133 miało najdłuższy czas trwania.
Zdarzenia pogrupowane według nazwy_obiektu, usp_GetPersonInfo posortowane według czasu trwania malejąco
Aby filtrować dane:Użyj przycisku Filtry…, opcji menu (Zdarzenia rozszerzone | Filtry…) lub CTRL + R, aby wyświetlić okno, aby zredukować zestaw wyników na podstawie różnych wyświetlanych pól. W tym przypadku filtrowaliśmy według object_name =usp_GetPersonInfo, ale można było również filtrować według pól takich jak server_principal_name lub client_app_name, ponieważ zostały one zebrane.
Warto zaznaczyć, że ani sesja Standard, ani TSQL nie zapisuje do pliku. W rzeczywistości nie ma celu dla żadnej sesji zdarzenia (jeśli nie wiedziałeś, że możesz utworzyć sesję zdarzenia bez celu, teraz wiesz). Jeśli chcesz zapisać te dane do dalszej analizy, musisz wykonać jedną z następujących czynności:
- Zatrzymaj przesyłanie danych i zapisz dane wyjściowe do pliku za pomocą menu Zdarzenia rozszerzone (Eksportuj do | Plik XEL…)
- Zatrzymaj przesyłanie danych i zapisz dane wyjściowe w tabeli w bazie danych za pomocą menu Zdarzenia rozszerzone (Eksportuj do | Tabela…)
- Zmień sesję zdarzenia i dodaj plik event_file jako cel.
Opcja 1 jest moją rekomendacją, ponieważ tworzy plik na dysku, który można udostępniać innym i przeglądać później w Management Studio w celu dalszej analizy. W Management Studio masz możliwość filtrowania nieistotnych danych, sortowania według jednej lub większej liczby kolumn, grupowania danych i wykonywania obliczeń (np. średnich). Możesz to zrobić, jeśli dane są tabelą, ale musisz napisać TSQL; analiza danych w interfejsie użytkownika jest łatwiejsza i szybsza.
Zmiana sesji XEvent Profiler
Możesz modyfikować sesje zdarzeń Standard i TSQL, a wprowadzone zmiany będą utrwalane po ponownym uruchomieniu instancji. Jeśli jednak sesje zdarzeń zostaną porzucone (po wprowadzeniu modyfikacji), zostaną przywrócone do ustawień domyślnych. Jeśli zauważysz, że ciągle wprowadzasz te same zmiany, sugeruję, abyś opisał zmiany i utworzył nową sesję zdarzeń, która będzie trwała również po ponownym uruchomieniu. Na przykład, jeśli spojrzymy na dotychczas przechwycone dane wyjściowe, zobaczymy, że zarówno zapytania adhoc, jak i procedury składowane zostały wykonane. I chociaż to wspaniałe, że widzę różne parametry wejściowe dla procedur składowanych, nie widzę poszczególnych instrukcji wykonywanych z tym zestawem zdarzeń. Aby uzyskać te informacje, musiałbym dodać zdarzenie sp_statement_completed.
Zrozum, że zarówno sesje zdarzeń Standard, jak i TSQL są zaprojektowane tak, aby były lekkie. Zdarzenia statement_completed będą uruchamiane częściej niż zdarzenia wsadowe i RPC, więc może być więcej narzutów, gdy te zdarzenia są częścią sesji zdarzeń. Używając zdarzeń dotyczących wyciągów, bardzo zaleca uwzględnienie dodatkowych predykatów. Przypominamy, że zdarzenia RPC i Batch tylko odfiltrowują zapytania systemowe – nie ma innego predykatu. Ogólnie zalecam również dodatkowe predykaty dla tych zdarzeń, szczególnie w przypadku dużego obciążenia pracą.
Jeśli martwisz się, czy uruchomienie sesji Standard lub TSQL spowoduje spadek wydajności systemu, zrozum, że przeglądarka danych na żywo rozłączy się, jeśli spowoduje zbyt duże obciążenie systemu. To duże bezpieczeństwo, ale nadal byłbym rozważny podczas korzystania z tych sesji. Uważam, że są one fantastycznym pierwszym krokiem do rozwiązywania problemów, szczególnie dla tych, którzy są nowicjuszami w SQL Server lub Extended Events. Jeśli jednak masz otwartą przeglądarkę danych na żywo i odejdziesz od swojego komputera, sesja zdarzeń będzie nadal działać . Zatrzymanie lub zamknięcie przeglądarki danych na żywo spowoduje zatrzymanie sesji zdarzenia, co zalecam po zakończeniu gromadzenia danych lub rozwiązywania problemów.
W przypadku sesji zdarzeń, które mają być uruchamiane przez dłuższy czas, utwórz oddzielne sesje zdarzeń, które zapisują do obiektu docelowego event_file i mają odpowiednie predykaty. Jeśli potrzebujesz więcej informacji na temat rozpoczęcia pracy z wydarzeniami rozszerzonymi, zapoznaj się z sesją, którą przeprowadziłem w zeszłym roku na SQLBits na temat migracji z programu Profiler do wydarzeń rozszerzonych.
