Сеансы расширенных событий

Применимо к:SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

Сеанс расширенных событий создается в процессе SQL Server ядро СУБД, где размещается подсистема расширенных событий. Следующие аспекты сеанса расширенных событий предоставляют контекст для понимания инфраструктуры расширенных событий и обработки, которая выполняется:

• Состояния сеанса. Различные состояния сеанса расширенных событий находятся в том случае, когда CREATE EVENT SESSION выполняются ALTER EVENT SESSION инструкции.

• Содержимое и характеристики сеанса. Содержимое сеанса расширенных событий, таких как целевые объекты и события, и как эти объекты связаны в сеансе или между сеансами.

Состояния сеанса

На следующем рисунке показаны различные состояния сеанса расширенных событий.

На приведенном выше рисунке обратите внимание, что состояние сеанса изменяется в виде различных команд языка определения данных (DDL) для сеанса событий. В следующей таблице описаны эти изменения состояния.

Метка рисунка	Инструкция DDL	Description
Создание	CREATE EVENT SESSION	Процесс узла создает объект сеанса, содержащий метаданные, предоставляемые CREATE EVENT SESSION. Процесс узла проверяет определение сеанса, проверяет уровень разрешений пользователя и сохраняет метаданные в master базе данных. На этом этапе сеанс не активен.
Alter	ALTER EVENT SESSION, STATE=START	Процесс запускает сеанс. Процесс считывает сохраненные метаданные, проверяет определение сеанса, уровень разрешений пользователя и создает сеанс. Загружаются такие объекты сеанса, как события и цели, и сеанс становится активным.
Alter	ALTER EVENT SESSION, STATE=STOP	Процесс останавливает активный сеанс, но сохраняет метаданные.
Drop	DROP EVENT SESSION	В зависимости от того, является ли сеанс активным, drop (DROP SESSION) удаляет метаданные и закрывает активный сеанс или удаляет метаданные сеанса.

Содержимое сеанса и характеристики

Сеансы расширенных событий имеют подразумеваемые границы в том, что конфигурация одного сеанса не изменяет конфигурацию другого сеанса. Однако эти границы не препятствуют использованию события или целевого типа в нескольких сеансах.

На следующем рисунке показано содержимое сеанса и связь между пакетами и сеансами.

Обратите внимание на предыдущий рисунок, имейте в виду следующее:

• Сопоставление между объектами пакета и сеансами много ко многим, что означает, что объект определенного типа может отображаться в нескольких сеансах, а сеанс может содержать несколько объектов.
• Одно и то же событие (событие 1) или целевой тип (target 1) можно использовать в нескольких сеансах.

Сеансы имеют следующие характеристики.

• Действия и предикаты привязаны к событиям по сеансам. Если у вас есть событие 1 в сеансе A с действием 1 и предикатом Z, это не влияет на событие 1 в сеансе B с действием 2 и действием 3 без предиката.
• Политики прикрепляются к сеансам для обработки буферизации и диспетчеризации, а также для отслеживания причинно-следственных связей.

Буферизация относится к хранению данных событий во время выполнения сеанса событий. Политики буферизации задают объем памяти для данных события и метод обработки потерь для событий. Диспетчеризация относится к длительности времени пребывания в буферах, прежде чем обслуживаться целевым объектам для обработки.

Отслеживание причин отслеживает работу в нескольких задачах. Если включено отслеживание причинно-следственных связей, каждое запущенное событие получает уникальный в системе идентификатор активности. Идентификатор активности является сочетанием значения идентификатора GUID, который остается неизменным для всех операций в задаче, и порядкового номера, возрастающего при каждом запуске события. Если одна задача вызывает действия в другой задаче, родительский идентификатор активности сообщается дочерней задаче. Дочерняя задача регистрирует родительский идентификатор активности при первом запуске события.

Связанный контент

• Обзор расширенных событий