Отслеживание DOP Feedback с помощью Extended Events

Автор: Vivek Janakiraman, SQL Server 2025 Series : Degree Of Parallelism (DOP) Feedback Explained with Real-Time Demo!

Настройка параллелизма всегда была одной из самых сложных задач оптимизации производительности SQL Server. Администраторы баз данных часто тратят часы на точную настройку параметров MAXDOP, пытаясь найти идеальный баланс между производительностью и потреблением ресурсов.

С выходом SQL Server 2025 эта задача значительно упрощается благодаря обратной связи по степени параллелизма (Degree of Parallelism Feedback, DOP Feedback) — мощной функции интеллектуальной обработки запросов, которая автоматически оптимизирует выполнение параллельных запросов.

В этой статье мы рассмотрим:

• Что такое DOP Feedback
• Как отслеживать её с помощью расширенных событий (Extended Events)
• Демонстрацию в реальном времени с несколькими сценариями
• Как проверить, работает ли DOP Feedback на вашем сервере

Что такое DOP Feedback?

Обратная связь по степени параллелизма позволяет SQL Server самостоятельно корректировать степень параллелизма для повторяющихся запросов. Вместо того чтобы полагаться на статические настройки MAXDOP, SQL Server анализирует производительность во время выполнения (использование ЦП, время выполнения, ожидания) и динамически изменяет степень параллелизма для последующих выполнений.

Это помогает:

• Снизить чрезмерное использование ЦП
• Улучшить производительность запросов
• Устранить необходимость ручной настройки

Отслеживание DOP Feedback с помощью Extended Events

Чтобы понять, как SQL Server применяет DOP Feedback, мы можем фиксировать внутренние решения движка с помощью расширенных событий.

Настройка отслеживания DOP Feedback

IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = 'DOPFeedbackWatch')
    DROP EVENT SESSION DOPFeedbackWatch ON SERVER;
GO

CREATE EVENT SESSION DOPFeedbackWatch ON SERVER
ADD EVENT sqlserver.dop_feedback_eligible_query(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_provided(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_validation(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_stabilized(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_reverted(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_analysis_stopped(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_reassessment_failed(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash))
ADD TARGET package0.ring_buffer;
GO

ALTER EVENT SESSION DOPFeedbackWatch ON SERVER STATE = START;
GO

Что это фиксирует:

Этот сеанс помогает отслеживать:

• Когда запрос становится подходящим для DOP Feedback
• Когда SQL Server корректирует степень параллелизма
• Подтверждена ли обратная связь или отменена
• Когда система стабилизируется на оптимальной степени параллелизма

Это обеспечивает видимость в реальном времени за поведением механизма самонастройки.

Демонстрация DOP Feedback (пошагово)

Давайте смоделируем рабочие нагрузки, чтобы наблюдать DOP Feedback в действии.

Сценарий 1: Высокообъёмный параллельный запрос (обратная связь скорректирована)

CREATE DATABASE jbdb;
GO

USE jbdb;
GO

-- Создание таблицы и загрузка данных
CREATE TABLE [dbo].[Table1](
    [Col1] [int] IDENTITY(1,1) NOT NULL,
    [Col2] [int] NULL,
    [Col3] [varchar](max) NULL,
    [Col4] [int] NULL,
    [Col5] [int] NULL,
    CONSTRAINT [PK_Table1] PRIMARY KEY CLUSTERED ([Col1] ASC)
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY];
GO

SET NOCOUNT ON;

INSERT INTO Table1 (Col2, Col3, Col4, Col5) VALUES (1, REPLICATE('a',4000), 10, 100);
GO 999

INSERT INTO Table1 (Col2, Col3, Col4, Col5) VALUES (2, REPLICATE('z',4000), 11, 100);
GO 99999

INSERT INTO Table1 (Col2, Col3, Col4, Col5) VALUES (3, REPLICATE('f',4000), 12, 100);
GO 8965

INSERT INTO Table1 (Col2, Col3, Col4, Col5) VALUES (4, REPLICATE('g',4000), 13, 100);
GO 7844

INSERT INTO Table1 (Col2, Col3, Col4, Col5) VALUES (5, REPLICATE('u',4000), 14, 100);
GO 4567

INSERT INTO Table1 (Col2, Col3, Col4, Col5) VALUES (2, REPLICATE('z',4000), 11, 100);
GO 751049

-- Хранимая процедура для запроса к таблице
CREATE OR ALTER PROCEDURE [dbo].[usp_GetDetails] @Col2 int
AS
BEGIN
    SELECT TOP (50000)
        [Col1], 
        [Col2], 
        [Col3], 
        [Col4], 
        [Col5]
    FROM dbo.Table1
    WHERE [Col2] = @Col2
    ORDER BY [Col3];
END;
GO

-- Выполнение хранимой процедуры
EXEC [dbo].[usp_GetDetails] @Col2 = 2;
GO

-- OSTRESS (инструмент для нагрузки)
-- C:\Program Files\Microsoft Corporation\RMLUtils>ostress -S"ВАШ_СЕРВЕР" -E -Q"EXEC usp_GetDetails @Col2 = 2;" -n1 -r100 -q -djbdb

В этом сценарии:

• Запрос выполняется многократно под нагрузкой
• SQL Server выявляет неэффективность в параллелизме
• Степень параллелизма корректируется для лучшей производительности

Сценарий 2: Неравномерный параллелизм (оценка обратной связи)

USE jbdb;
GO

-- Предполагается, что процедура usp_SkewedParallelReport уже создана
-- ostress -S"ВАШ_СЕРВЕР" -E -Q"EXEC usp_SkewedParallelReport;" -n1 -r100 -q -djbdb

Здесь:

• SQL Server оценивает неравномерные рабочие нагрузки
• Определяет, улучшит ли снижение степени параллелизма эффективность
• Может подтвердить или отклонить обратную связь

Мониторинг активной рабочей нагрузки

Чтобы увидеть, что выполняется в данный момент:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

-- Какие SQL-операторы выполняются в данный момент?
SELECT 
    [Spid] = session_id,
    ecid,
    [Database] = DB_NAME(sp.dbid),
    [User] = nt_username,
    [Status] = er.status,
    [Wait] = wait_type,
    [Individual Query] = SUBSTRING(
        qt.text,
        er.statement_start_offset/2,
        (CASE WHEN er.statement_end_offset = -1
              THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
              ELSE er.statement_end_offset
         END - er.statement_start_offset)/2
    ),
    [Parent Query] = qt.text,
    Program = program_name,
    Hostname,
    nt_domain,
    start_time
FROM sys.dm_exec_requests er
INNER JOIN sys.sysprocesses sp ON er.session_id = sp.spid
CROSS APPLY sys.dm_exec_sql_text(er.sql_handle) AS qt
WHERE session_id NOT IN (@@SPID)   -- Игнорировать текущий оператор
ORDER BY 1, 2;
GO

Это помогает:

• Определить активные запросы
• Проверить параллельные рабочие нагрузки
• Сопоставить с выводом Extended Events

Ключевые выводы из демонстрации

Из приведённых выше сценариев вы обычно заметите:

• DOP Feedback успешно применена — SQL Server снижает или корректирует степень параллелизма; производительность улучшается при повторных выполнениях.
• Оптимальная степень параллелизма определена — изменения не требуются; система подтверждает, что текущая степень параллелизма эффективна.
• Запрос не подходит для обратной связи — некоторые запросы исключаются в зависимости от шаблона выполнения и рабочей нагрузки.

Почему это важно

Обратная связь по степени параллелизма фундаментально меняет подход администраторов баз данных к настройке:

Традиционный подход	Подход SQL Server 2025
Ручная настройка MAXDOP	Автоматическая настройка для каждого запроса
Метод проб и ошибок	Решения, основанные на данных
Статическая конфигурация	Адаптивная оптимизация

Заключительные мысли

С SQL Server 2025 ядро базы данных становится умнее и более автономным. DOP Feedback:

• Устраняет догадки
• Улучшает стабильность производительности
• Снижает конкуренцию за ЦП
• Адаптируется динамически к изменениям рабочей нагрузки

Для администраторов баз данных и инженеров по производительности это означает меньше времени на настройку и больше времени на создание ценности.

Если вы тестируете SQL Server 2025 в своей среде, я настоятельно рекомендую посмотреть эту демонстрацию и понаблюдать за выводом Extended Events — это даёт невероятное представление о том, как движок учится и адаптируется в реальном времени.