Sesje zdarzeń rozszerzonych

Dotyczy:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceBaza danych SQL w usłudze Microsoft Fabric

Sesja zdarzeń rozszerzonych jest tworzona w procesie aparatu bazy danych SQL Server, który hostuje aparat zdarzeń rozszerzonych. Następujące aspekty sesji zdarzeń rozszerzonych zapewniają kontekst do zrozumienia infrastruktury zdarzeń rozszerzonych i przetwarzania, które ma miejsce:

• Stany sesji. Różne stany, w których znajduje się sesja zdarzeń rozszerzonych podczas wykonywania instrukcji CREATE EVENT SESSION i ALTER EVENT SESSION.

• Zawartość i cechy sesji. Zawartość sesji zdarzeń rozszerzonych, takich jak obiekty docelowe i zdarzenia, oraz sposób, w jaki te obiekty są powiązane w sesji lub między sesjami.

Stany sesji

Na poniższej ilustracji przedstawiono różne stany sesji zdarzeń rozszerzonych.

Odnosząc się do poprzedniej ilustracji, zwróć uwagę, że stan sesji zmienia się, ponieważ dla sesji zdarzeń są wydawane różne polecenia języka definicji danych (DDL). W poniższej tabeli opisano te zmiany w stanie.

Etykieta ilustracji	Instrukcja DDL	Description
Create	CREATE EVENT SESSION	Proces hosta tworzy obiekt sesji zawierający metadane dostarczone przez CREATE EVENT SESSION. Proces hosta weryfikuje definicję sesji, weryfikuje poziom uprawnień użytkownika i przechowuje metadane w master bazie danych. W tym momencie sesja nie jest aktywna.
Alter	ALTER EVENT SESSION, STATE=START	Proces hosta rozpoczyna sesję. Proces hosta odczytuje przechowywane metadane, weryfikuje definicję sesji, weryfikuje poziom uprawnień użytkownika i tworzy sesję. Obiekty sesji, takie jak zdarzenia i obiekty docelowe, są ładowane, a obsługa zdarzeń jest aktywna.
Alter	ALTER EVENT SESSION, STATE=STOP	Proces hosta zatrzymuje aktywną sesję, ale zachowuje metadane.
Drop	DROP EVENT SESSION	W zależności od tego, czy sesja jest aktywna, funkcja Drop (DROP SESSION) usuwa metadane i zamyka aktywną sesję lub usuwa metadane sesji.

Zawartość i cechy sesji

Sesje zdarzeń rozszerzonych mają określone granice, ponieważ konfiguracja jednej sesji nie zmienia konfiguracji innej sesji. Jednak te granice nie uniemożliwiają użycia zdarzenia ani typu docelowego w więcej niż jednej sesji.

Poniższa ilustracja przedstawia zawartość sesji i relację między pakietami i sesjami.

Odnosząc się do powyższej ilustracji, należy pamiętać, że:

• Mapowanie między obiektami pakietu a sesjami ma charakter wielomiany, co oznacza, że obiekt określonego typu może pojawić się w kilku sesjach, a sesja może zawierać kilka obiektów.
• To samo zdarzenie (zdarzenie 1) lub typ docelowy (Target 1) może być używane w więcej niż jednej sesji.

Sesje mają następujące cechy:

• Akcje i predykaty są powiązane ze zdarzeniami w ramach pojedynczej sesji. Jeśli masz zdarzenie 1 w sesji A z akcją 1 i predykatem Z, to w żaden sposób nie wpływa to na posiadanie zdarzenia 1 w sesji B z akcją 2 i akcją 3 bez predykatu.
• Zasady są dołączane do sesji w celu zarządzania buforowaniem, dystrybucją oraz śledzeniem przyczynowości.

Buforowanie odnosi się do sposobu przechowywania danych zdarzeń podczas działania sesji zdarzeń. Zasady buforowania określają ilość pamięci do użycia dla danych zdarzeń oraz zasady utraty dla zdarzeń. Dispatch odnosi się do czasu, przez jaki zdarzenia pozostają w buforach, zanim zostaną przetworzone na cele przetwarzania.

Śledzenie przyczynowości śledzi pracę w wielu zadaniach. Po włączeniu śledzenia przyczynowości każde zdarzenie ma unikatowy identyfikator aktywności w całym systemie. Identyfikator działania to połączenie wartości identyfikatora GUID, która pozostaje stała we wszystkich zdarzeniach dla zadania, oraz numeru sekwencji, który jest zwiększany za każdym razem, gdy uruchamiane jest zdarzenie. Gdy jedno zadanie powoduje wykonanie pracy przez inne zadanie, identyfikator aktywności zadania nadrzędnego jest wysyłany do zadania podrzędnego. Zadanie podrzędne zwraca identyfikator działania elementu nadrzędnego przy pierwszym uruchomieniu zdarzenia.

Sesje zdarzeń związanych z czasem

Począwszy od programu SQL Server 2025 (17.x), można utworzyć sesję zdarzeń, która zatrzymuje się automatycznie po upływie określonego czasu. Pomaga to uniknąć sytuacji, w których sesje mogą być pozostawione na czas nieokreślony przez pomyłkę, zużywając zasoby i potencjalnie generując dużą ilość danych.

Gdy dane zdarzenia generowane przez sesję są obszerne, sesje zdarzeń ograniczone czasowo umożliwiają przechwytywanie bardziej ukierunkowanych, mniejszych danych diagnostycznych przez określony, konkretny czas. Możesz ręcznie uruchomić sesję zdarzeń ograniczoną czasem lub skorzystać z zaplanowanego zadania, wykonując to w dogodnym momencie i mając pewność, że sesja nie będzie działać w nieskończoność.

Aby ograniczyć czas trwania sesji zdarzenia, określ MAX_DURATION argument podczas tworzenia lub modyfikowania sesji. Aby uzyskać więcej informacji, zobacz CREATE EVENT SESSION (Tworzenie sesji zdarzeń) i ALTER EVENT SESSION (Modyfikowanie sesji zdarzeń).

Podobnie jak w przypadku każdej sesji zdarzeń, można zatrzymać sesję o ograniczonym czasie trwania przed upływem maksymalnego czasu trwania przy użyciu instrukcji ALTER EVENT SESSION ... STATE = STOP. Jeśli sesja zostanie uruchomiona ponownie, cały czas określony przez MAX_DURATION musi ponownie minąć, zanim sesja zostanie zatrzymana automatycznie.

Możesz również zmodyfikować istniejącą sesję zdarzeń przy użyciu polecenia ALTER EVENT SESSION i określić inny maksymalny czas trwania lub usunąć ją, określając wartość MAX_DURATION = UNLIMITED. Aby zmodyfikować MAX_DURATION to ustawienie, sesja musi zostać zatrzymana.

Jeśli sesja zdarzeń jest powiązana czasowo, kolumna max_duration w widoku wykazu sys.server_event_sessions pokazuje maksymalny czas trwania sesji w sekundach. Sesja zdarzeń ma nieograniczony czas trwania, jeśli wartość jest równa zero.

Treści powiązane

• Omówienie zdarzeń rozszerzonych