Сеансы расширенных событий
Область применения:
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, который остается неизменным для всех операций в задаче, и порядкового номера, возрастающего при каждом запуске события. Если одна задача вызывает действия в другой задаче, родительский идентификатор активности сообщается дочерней задаче. Дочерняя задача регистрирует родительский идентификатор активности при первом запуске события.