Вы когда-нибудь задавались вопросом, насколько Extended Events влияют на производительность вашей рабочей нагрузки (workload)? Я много писал о Extended Events и был активным сторонником их использования в качестве альтернативы SQL Trace даже дольше, чем я работаю на SQLskills.com. Но хоть Extended Events и дают нам множество преимуществ при сборе данных с минимальными накладными расходами, все же бывают случаи, когда нам не обойтись без дополнительных накладных расходов на наблюдение (observation overheads) даже при использовании Extended Events.

Измерение “накладных расходов на наблюдение” в SQL Trace и Extended Events — SQLPerformance.com

SQL Server 2022 предлагает новое расширение функционала Extended Events, благодаря которому мы теперь можем отслеживать производительность и ряд других метрик публикации событий, которые были включены в сеанс, запущенный на сервере. В SQL Server 2022 в DMV sys.dm_xe_session_events были добавлены четыре новых столбца, которые предоставляют дополнительные сведения о показателях производительности публикации событий запущенного сеанса:

Новые столбцы, добавленные в sys.dm_xe_session_events в SQL Server 2022.

Два новых столбца, event_fire_count и event_fire_average_time, требуют от вас включения флага трассировки 9708 для сбора данных. Это отражено в следующей электронной документации:

Флаги трассировки (Transact-SQL) — SQL Server | Microsoft Learn

Эти столбцы не будут заполняться, если вы не включите указанный флаг трассировки. Этот флаг трассировки является global only, поэтому его необходимо включать с помощью DBCC TRACEON(9708, -1). Я решил посмотреть на результат следующего запроса сначала без включения флага, а затем с включенным флагом:

SELECT s.name AS session_name, 
	event_name,
	event_fire_count,
	event_fire_average_time, 
	event_fire_min_time, 
	event_fire_max_time
FROM sys.dm_xe_sessions AS s 
INNER JOIN sys.dm_xe_session_events AS xse
	ON s.address = xse.event_session_address
ORDER BY event_fire_max_time DESC

Показатели производительности дефолтных extended events без флага трассировки 9708.

Показатели производительности дефолтных extended events с включенным флагом трассировки 9708.

Флаг трассировки является global only, поэтому я включил его с помощью DBCC TRACEON(9708, -1). Хоть эта система не может похвастаться постоянной огромной рабочей нагрузкой, приятно видеть, что общее влияние на производительность дефолтных сеансов довольно низкое.

Однако я был настроен на эксперименты и хотел сделать что-то невероятно глупое с этим флагом трассировки, поэтому я создал на том же сервере сеанс под именем CrazyEvents, выполнил SELECT ALL в пользовательском интерфейсе, добавил в сеанс каждый недебажный канала событий и запустил его. Я не буду демонстрировать в этом блогпосте скрипт, который я использовал, чтобы сделать это, ведь в первую очередь это глупая идея, и вы сами легко можете воспроизвести этот сеанс в пользовательском интерфейсе, если захотите присоединиться ко мне в психушке. Вам придется подождать от нескольких секунд до минут, пока такое количество событий будут добавлены к сеансу. Я должен ответить, что редактирования определения этого сеанса чуть позже в SSMS было достаточно, чтобы запустить кулеры моего ноутбука.

Для относительно стабилизированной системы, где выполнялись лишь запросы, связанные с этим блогпоста, результаты меня немного удивили. Я не ожидал, что 4.5 мс времени запуска для события wait_info выплывет как самое продолжительное событие по запуску из относительно стабилизированной системы.

Показатели производительности запуска extended event сеанса CrazyEvents

Хоть мне пока непонятно, стоит ли включать флаг трассировки для двух дополнительных столбцов, я очень рад, что Microsoft продолжает вкладывать средства в усовершенствования Extended Events, которые позволяют лучше диагностировать влияние на производительность вызванные определенными сеансами и собираемыми событиями. До добавления этих усовершенствований не существовало точных способов определения того, оказывает ли событие негативное влияние на производительность и, если да, то в какой степени, кроме банального наблюдения за поведением с запущенным сеансом события и без него. Теперь в нашем арсенале есть полноценное средство определения для оценки влияет событие на производительность.

Иногда так сложно разобраться, какие есть варианты переноса данных между разными серверами БД, какой способ выбрать и в чем разница. Приглашаем всех желающих на открытый урок, на котором поговорим о том, какие возможности есть в MS SQL server, в чем их различия и для каких задач каждый способ подходит лучше.

Урок состоится в рамках онлайн-курса "MS SQL Server Developer". Успевайте зарегистрироваться — урок пройдет уже сегодня вечером.