SQL Server 2025: параметр Availability Group Commit Time

Автор: Nathan Courtine. SQL Server 2025 – AG Commit Time

В этом материале я хочу выделить одну функцию движка для высокой доступности (HA) — Availability Group Commit Time.

Функция Always On Availability Group (AG) появилась в SQL Server 2012. За годы эта технология HA получила множество улучшений, особенно в SQL Server 2016 (автоматическая инициализация, реплики только для чтения, поддержка DTC, проверка состояния БД, распределённые AG и т. д.).

Для решения проблем с производительностью в SQL Server 2016 был введён параметр AG Commit Time. Для узлов в синхронном режиме он уменьшает задержку, задавая время, после которого транзакция должна быть отправлена на реплики.

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

Однако в некоторых сценариях значение по умолчанию (10 мс) может быть слишком большим и не соответствовать бизнес-требованиям. В SQL Server 2025 этот параметр теперь можно настроить на уровне сервера через конфигурацию availability group commit time.

Настройка параметра

Проверим текущее значение в конфигурации:

SELECT name, value, value_in_use, is_advanced, is_dynamic
FROM sys.configurations 
WHERE name = 'availability group commit time (ms)';

Значение 0 означает использование значения по умолчанию — 10 мс. Чтобы изменить его (например, на 1 мс), используем sp_configure:

EXEC sp_configure 'show advanced options', '1';
RECONFIGURE;

EXEC sp_configure 'availability group commit time (ms)', '1';
RECONFIGURE;

EXEC sp_configure 'show advanced options', '0';
RECONFIGURE;

SELECT name, value, value_in_use, is_advanced, is_dynamic
FROM sys.configurations
WHERE name = 'availability group commit time (ms)';

Мониторинг влияния

Чтобы оценить время commit между Primary и Secondary, можно использовать DMV:

SELECT 
    database_id,
    is_primary_replica,
    synchronization_state_desc,
    last_commit_time,
    last_hardened_time,
    last_received_time,
    last_sent_time
FROM sys.dm_hadr_database_replica_states;

Также можно вычислить время между отправкой блока журнала и его подтверждением. Для этого настроим сессию Extended Events:

CREATE EVENT SESSION [AG_Commit_Latency_Tracking] ON SERVER
ADD EVENT sqlserver.hadr_log_block_send_complete(
    ACTION(sqlserver.sql_text)
),
ADD EVENT sqlserver.hadr_receive_harden_lsn_message(
    ACTION(sqlserver.sql_text)
),
ADD EVENT sqlserver.hadr_log_block_group_commit(
    ACTION(sqlserver.sql_text)
)
ADD TARGET package0.event_file (
    SET filename = N'C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\AG_Commit_Latency.xel', 
        max_file_size = 50, 
        max_rollover_files = 5
)
WITH (STARTUP_STATE = ON);
GO

ALTER EVENT SESSION [AG_Commit_Latency_Tracking] ON SERVER STATE = START;

SELECT 
    event_data.value('(event/@name)[1]', 'varchar(100)') AS event_name,
    event_data.value('(event/@timestamp)[1]', 'datetime2') AS [timestamp],
    event_data.value('(event/action[@name="sql_text"]/value)[1]', 'nvarchar(max)') AS sql_text
FROM 
(
    SELECT CAST(event_data AS XML) AS event_data
    FROM sys.fn_xe_file_target_read_file(
        'C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\AG_Commit_Latency*.xel', 
        NULL, NULL, NULL
    )
) AS events
ORDER BY [timestamp] DESC;

Полученное сообщение не всегда точно соответствует моменту обработки на вторичной реплике, но даёт хорошее представление, выдерживается ли заданная продолжительность.