MS SQL Server дело тонкое...: Диагностика проблем с производительностью репликации транзакций

Автор: VinaySarangam, Troubleshooting Replication Performance Issues

Этот документ помогает диагностировать или решать проблемы, связанные с производительностью репликации.

Получение информации о «Полной картине топологии»:

Прежде чем погрузиться в решение любой проблемы, вам необходимо полностью понять тип среды, с которой вы имеете дело, поскольку могли произойти изменения, о которых вы не знаете. Простой способ сделать это — запустить ReplScripts/Replication Topology Script.sql at master · ReplTalk/ReplScripts, который даёт вывод, подобный приведённому ниже.

Просмотрите вывод для получения подробностей об издателях, публикациях и подписках.

1. Проверка проблем репликации с помощью трассировочных токенов:

Назначение трассировочных токенов:

Измерение задержки: Измерение времени, которое требуется данным для перемещения от издателя → распространителю → подписчику.
Проверка подключения: Проверка того, правильно ли функционируют соединения репликации между компонентами.
Диагностика: Выявление узких мест или задержек в процессе репликации.

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

На изображении ниже показано, как данные передаются от Издателя к Подписчику через Распространитель после применения начального моментального снимка.

Как упомянуто на изображении ниже:

Если задержка между издателем → распространителем, то проблема может быть либо в:
- Потоке чтения агента чтения журнала (LogReader-Reader Thread)
- Потоке записи агента чтения журнала (LogReader-Writer Thread)
Если задержка между распространителем → подписчиком, то проблема может быть либо в:

Потоке чтения агента распространителя (Distribution-Reader Thread)
Потоке записи агента распространителя (Distribution-Writer Thread)

2. Инструменты статистики производительности:

Статистика производительности была добавлена в таблицы mslogreader_history и msdistribution_history в базе данных распространителя в Microsoft SQL Server. Вы можете использовать эту статистику для просмотра недавней истории производительности агента чтения журнала репликации и агента распространителя репликации.

Каждые пять минут статистика производительности для агентов чтения журнала и распространителя записывается в таблицы истории. По умолчанию сохраняются только данные за последние 48 часов. Процесс очистки удаляет данные старше 48 часов. Значение по умолчанию можно изменить, выполнив хранимую процедуру sp_changedistributiondb и указав новое значение для параметра history_retention.

Ниже приведён пример выходных данных производительности из таблицы истории для агента чтения журнала:

<stats state="1" work="9" idle="295"> <reader fetch="8" wait="0"/> <writer write="9" wait="0"/> <sincelaststats elapsedtime="304" work="9" cmds="52596" cmdspersec="5753.000000"> <reader fetch="8" wait="0"/> <writer write="9" wait="0"/> </sincelaststats> </stats>

Могут записываться три состояния событий:

Состояние	Описание
1	Обычные события, описывающие производительность как потока чтения, так и потока записи.
2	Повышенные события, которые происходят, когда поток чтения агента ожидает дольше времени `-messageinterval` агента (по умолчанию 60 секунд). Если вы заметите события состояния 2, записанные для агента, это указывает, что агенту требуется много времени для записи изменений в место назначения.
3	Повышенные события, генерируемые только агентом чтения журнала, когда поток записи ожидает дольше времени `-messageinterval`. Если вы заметите события состояния 3, записанные для агента чтения журнала, это указывает, что агенту требуется много времени для сканирования реплицируемых изменений из журнала транзакций.

2.1. Поток чтения агента чтения журнала:

Следующая статистика производительности демонстрирует ситуацию с задержкой в топологии репликации, где узким местом является поток чтения агента чтения журнала. Поток чтения агента чтения журнала сканирует журнал транзакций опубликованной базы данных в поисках команд для передачи в базу данных распространителя (<Distribution server>..MSlogreader_history.Comments).

<stats state="1" work="301" idle="0" >
    <reader fetch="278" wait="0"/>
    <writer write="12" wait="288"/>
    <sincelaststats elapsedtime="301" work="301" cmds="104500" cmdspersec="347.000000">
    <reader fetch="278" wait="0"/>
    <writer write="12" wait="288"/>
    </sincelaststats>
</stats>

Статистика sincelaststats writer wait в 288 секунд кажется высокой. Это время, которое поток записи ожидает, пока поток чтения предоставит буферы для применения. Поток чтения агента чтения журнала выполняет хранимую процедуру sp_replcmds. Если вы заметите высокие значения ожидания потока записи в статистике производительности агента чтения журнала, вам следует исследовать производительность выполнения агента чтения журнала на сервере публикации (что означает поток чтения агента чтения журнала) и базы данных, а затем изучить время выполнения хранимой процедуры sp_replcmds.

2.2. Поток чтения агента распространителя:

Следующая статистика производительности демонстрирует ситуацию с задержкой в топологии репликации, где узким местом является поток чтения агента распространителя. Этот поток запрашивает базу данных распространителя (таблица <Distribution server>..MSdistribution_history.Comments) для получения команд, применяемых у подписчика.

<stats state="1" work="14798" idle="2035">
  <reader fetch="14798" wait="193"/>
  <writer write="12373" wait="9888"/>
<sincelaststats elapsedtime="424" work="415" cmds="296900" cmdspersec="713.000000">
    <reader fetch="415" wait="7"/>
    <writer write="377" wait="212"/>
</sincelaststats>
</stats>

Время ожидания sincelaststats writer wait (212 секунд) кажется высоким. Это время, которое поток записи ожидает, пока поток чтения предоставит буферы, которые поток записи может применить в базе данных подписчика. Поток чтения агента распространителя выполняет хранимую процедуру sp_MSget_repl_commands.

Если вы заметите высокое время ожидания записи в статистике производительности агента распространителя, вам следует исследовать производительность выполнения агента распространителя на сервере и базе данных распространителя. В частности, вам следует изучить время выполнения хранимой процедуры sp_MSget_repl_commands.

2.3. Поток записи агента распространителя:

Примечание: Состояние — 2, и вывод несколько отличается от статистики состояния 1. Данные состояния 2 указывают, что поток чтения должен был ждать дольше, чем настроенное значение -messageinterval агента распространителя. По умолчанию значение -messageinterval равно 60 секундам.

<stats state="2" fetch="48" wait="384" cmds="1028" callstogetreplcmds="321">
<sincelaststats elapsedtime="312" fetch="47" wait="284" cmds="1028" cmdspersec="3.000000"/>
</stats>

Если значение -messageinterval увеличено, вы можете снова получать статистику состояния 1, напоминающую следующую:

<stats state="1" work="1941" idle="0">
    <reader fetch="717" wait="1225"/>
    <writer write="1941" wait="134"/>
    <sincelaststats elapsedtime="764" work="764" cmds="1170730" cmdspersec="1530.000000">
        <reader fetch="258" wait="505"/>
        <writer write="764" wait="50"/>
    </sincelaststats>
</stats>

Примечание: Время ожидания получения sincelaststats fetch в 505 секунд очень высоко.

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

sp_MSupd_<ownertablename>
sp_MSins_<ownertablename>
sp_MSdel_<ownertablename>

Кроме того, чтобы определить, связано ли узкое место с аппаратным обеспечением или системой, используйте системный монитор для отслеживания производительности системы. Например, используйте системный монитор для отслеживания счётчиков физического диска.

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

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

3. Другие проблемы и решения:

Проблема 1: В среде, где есть много публикаций: некоторые продвигаются вперёд, некоторые не продвигаются, некоторые продвигаются медленно.

Наблюдения 1: Из подробного журнала распространителя мы наблюдаем следующее сообщение об ошибке: «2025-03-05 12:54:20.538 Параллельный моментальный снимок для публикации '<PublicationName>' недоступен, потому что он не был полностью сгенерирован, или агент чтения журнала не запущен для его активации. Если создание параллельного моментального снимка было прервано...»

Это исходит из процедуры «sys.sp_MSsubscription_status». Это происходит потому, что статус подписки равен 3 («инициировано»), а тип синхронизации — автоматический. Агент чтения журнала должен прочитать, когда агент моментальных снимков начал и завершил работу из журнала, после чего он обновит таблицу MSsubscription.

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

Проблема 2: Транзакционная репликация для передачи данных на виртуальную машину Azure SQL клиента в их тенанте/подписке. Данные медленно завершают свою отправку в пиковые периоды.

Наблюдения 2: Мы не можем найти проблему с нашей виртуальной машиной распространителя (эта виртуальная машина), и у их виртуальной машины нет явной проблемы.

Решение 2: Основная причина здесь заключается в том, что у вас есть две публикации, которые передают большие объёмы данных поздней ночью. Одна из этих таблиц на стороне подписчика очень большая. Большую часть пространства занимают индексы (более 50%). В ней примерно 13+ миллиардов строк. Когда мы отправляем данные в эту таблицу и другие большие таблицы, это вызывает чрезмерное количество операций чтения, приводящее к многопоточности и, как следствие, к задержке, которая не позволяет распространителю применять транзакции своевременно.

Удаление дублирующихся или неиспользуемых индексов
Архивация данных
Перестроение индексов
Создание отсутствующих индексов
Обновление статистики
Секционирование таблиц

Проблема 3: Задержка от издателя/распространителя к подписчикам.

Наблюдения 3:

В журнале ошибок SQL Server произошла перезагрузка службы SQL. Восстановление базы данных распространителя занимает много времени, после этого, кажется, задания начинают получать тайм-аут запросов.
Во время диагностики мы заметили проблемы с блокировками. Мы подтвердили, что заголовком блокировки была сессия агента чтения журнала. Сессия агента чтения журнала не зависла. Просто она обрабатывает огромную транзакцию, и это занимает много времени. Это вызвало блокировку.

Решение 3: Были изменены указанные ниже свойства профиля агента и выполнено обновление статистики, что помогло улучшить производительность агента чтения журнала.

MaxCmdsInTran 10000,
ReadBatchSize 5000,
LogScanTreshhold = 750000

Проблема 4: Задание слияния работает непрерывно, и мы видим нижеследующее сообщение в мониторе репликации: «Ожидание 60 секунд(ы) перед следующим опросом на наличие изменений».

Решение 4: Мы воспроизвели ту же проблему во внутренней лаборатории и подтвердили, что использование параметра –Continuous отображает это сообщение (если этот параметр добавлен, агент никогда не останавливается и постоянно проверяет наличие изменений).

-Continuous: Указывает, будет ли агент постоянно пытаться опрашивать реплицированные транзакции. Если указано, агент опрашивает реплицированные транзакции из источника с интервалами опроса, даже если нет ожидающих транзакций.

Ссылка: Агент слияния репликации

После удаления этого параметра мы не получали сообщение.
Кроме того, нам необходимо использовать параметр –QueryTimeout, чтобы мы могли контролировать длительные запросы.

-QueryTimeOut query_time_out_seconds — это количество секунд до тайм-аута запроса. По умолчанию — 300 секунд. Агент слияния также использует значение QueryTimeout, чтобы определить, как долго ждать создания секционированного моментального снимка, когда это значение больше 1800.

Проблема 5: Репликация данных занимает огромное количество времени.

Наблюдения 5: Мы наблюдали нижеследующее:

Виртуальная машина постоянно использовала 100% своей общей пропускной способности диска в течение последних 24 часов до сбора данных.
Лимит данных: У этой виртуальной машины лимит данных составляет 256 МБ/с. На сервере есть несколько дисков P30, способных достигать пропускной способности 200 МБ. Независимо от использования чередования, диски ограничены максимальной пропускной способностью виртуальной машины.
Отложенная запись в секунду: В идеале значение для отложенной записи в секунду должно быть близко к нулю.
Ожидаемое время жизни страницы (PLE): Более высокое значение PLE указывает на лучшую производительность, так как означает, что страницы дольше остаются в пуле буферов (кэше памяти). Это уменьшает необходимость чтения данных с жёсткого диска. В настоящее время значение PLE очень низкое.
Главные блокирующие: Существует значительное количество блокировок, в основном связанных с заданием очистки. Агент чтения журнала был главным блокирующим в двух случаях со средней продолжительностью менее 20 секунд.
Агент чтения журнала: Агент чтения журнала, кажется, блокирует некоторые задания операций с индексами. У него неактивный статус с открытыми транзакциями из-за непрерывного режима.
Большие пакеты транзакций: Когда агент чтения журнала обрабатывает большое количество команд или транзакций, это может привести к задержкам в процессе репликации, потенциально вызывая блокировки, так как другие процессы ожидают завершения работы агента. Агент чтения журнала может вызывать проблемы с блокировками в транзакционной репликации SQL Server в основном из-за больших пакетов реплицированных транзакций или высокого процента нереплицированных транзакций в журнале транзакций, что приводит к увеличению задержки и конкуренции за ресурсы.
Высокий процент нереплицированных транзакций: Если значительная часть журнала транзакций содержит транзакции, не помеченные для репликации, агенту чтения журнала необходимо просканировать эти транзакции, что приводит к увеличению задержки и потенциально вызывает блокировки.
Ограничения ресурсов: Если на сервере недостаточно ресурсов (ЦП, память, диск ввода-вывода), работа агента чтения журнала может задерживаться, что приводит к проблемам с блокировками.

Как обсуждалось ранее, последние два варианта выше наиболее вероятны для блокировок.

Решение 5:

Операции ETL в/из нереплицируемых баз данных: Как обсуждалось ранее, моя главная рекомендация — обратиться к команде разработчиков, чтобы узнать, могут ли они переместить свои операции ETL в другую базу данных без репликации. Если значительная часть журнала транзакций содержит транзакции, не помеченные для репликации, агенту чтения журнала необходимо просканировать эти транзакции, что приводит к увеличению задержки и потенциально вызывает блокировки.
Настройка ReadBatchSize: Ещё один вариант для уменьшения блокировок — настройка параметра ReadBatchSize. Хотя мы делали это в прошлом, стоит поэкспериментировать с разными значениями, пока мы не найдём оптимальную настройку. Обратите внимание, что большее значение не всегда улучшает производительность, особенно для рабочих нагрузок с большими транзакциями.
Обновление SKU виртуальной машины: Этот сервер постоянно достигает своей ёмкости. Я рекомендую обновить SKU виртуальной машины, чтобы лучше соответствовать вашей рабочей нагрузке.
Проблемы с блокировками: Если блокировки являются основной проблемой, другой вариант — создать отдельное задание, которое проверяет наличие блокировок. Если агентом чтения журнала будет идентифицирован как главный блокирующий, задание может перезапустить агента чтения журнала, как показано ниже.

Проблема 6: Проблемы с производительностью репликации.

Решение 6: Мы обнаружили, что конфигурация SQL Server и диска не настроена в соответствии с лучшими практиками. После следования лучшим практикам с точки зрения конфигурации диска и SQL проблема была решена. Пожалуйста, обратитесь к ссылке ниже для справки: Контрольный список: рекомендации для SQL Server на виртуальных машинах Azure.

Проблема 7: Задержка агента чтения журнала.

Наблюдения 7:

После перезапуска агента чтения журнала он снова начинает работать.
Мы переключали значение -ReadBatchSize между 500 и 5000 и сравнивали производительность, теперь используем 500 для обработки журнала.
Из истории агента чтения журнала видно, что журнал транзакций обрабатывается, но остаётся много необработанного журнала. Обработка, кажется, медленная. Из истории агента чтения журнала получаем следующую статистическую информацию.

По сути, на сервере издателя процесс чтения журнала имеет поток чтения, подключающийся к базе данных издателя для выполнения SP_REPLCMDS. На сервере распространителя процесс чтения журнала имеет поток записи, подключающийся к базе данных распространителя для записи команд в distribution.dbo.sp_MSadd_replcmds. Данные, прочитанные из базы данных издателя, должны быть записаны в распространитель. Из нижеследующего мы видим, что «reader fetch» составляет 2940 секунд с ожиданием 1 секунду, что означает, что поток чтения получал данные в течение 2940 секунд и ждал 1 секунду в последнем расчётном периоде. А поток записи писал 99 секунд с ожиданием 2439 секунд.

<stats state="1" work="2539" idle="0" ><reader fetch="2940" wait="1"/><writer write="99" wait="2439"/><sincelaststats elapsedtime="526" work="526" cmds="407220" cmdspersec="772.000000"><reader fetch="526" wait="0"/><writer write="13" wait="513"/></sincelaststats><message>Normal events that describe both the reader and writer thread performance.</message></stats>

Здесь длительное ожидание потока записи фактически означает ожидание поступления данных в буфер чтения, поэтому замедление происходит на этапе чтения данных.

На основе проверки производительности диска виртуальной машины, логические блоки (LUN), принадлежащие файлу журнала, не имеют задержек.

В истории агента чтения журнала мы заметили множество сообщений типа «Приблизительно xxx записей журнала было просканировано в проходе xx, 0 из которых были помечены для репликации». Эти сообщения означают, что просканированные записи журнала не предназначены для репликации, поэтому они пропускаются. Если есть слишком много несвязанных записей журнала, агенту чтения журнала придётся тратить много времени на сканирование несвязанных журналов, что замедлит синхронизацию транзакций репликации.

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

Решение 7: Нет задержки диска на диске журнала. Замедление работы агента чтения журнала в основном связано с слишком большим количеством транзакций, не связанных с репликацией, и большим количеством накапливаемых пакетов. Лучшие практики в этом сценарии:

Сжать файл журнала перед настройкой репликации.
Настроить репликацию в часы наименьшей нагрузки.

4. Повышение производительности транзакционной репликации:

1. Уровень проектирования:

a. Проектирование базы данных:

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

b. Конфигурация распространителя:

Настройте распространителя на выделенном сервере. Вы можете уменьшить нагрузку на обработку на издателе, настроив удалённого распространителя. Для получения дополнительной информации см. Настройка распространения.
Правильно определите размер базы данных распространителя. Протестируйте репликацию с типичной нагрузкой для вашей системы, чтобы определить, сколько места требуется для хранения команд. Убедитесь, что база данных достаточно велика для хранения команд без необходимости частого автоматического увеличения. Для получения дополнительной информации об изменении размера базы данных см. ALTER DATABASE (Transact-SQL).

c. Проектирование публикации:

Реплицируйте выполнение хранимых процедур при выполнении пакетных обновлений опубликованных таблиц. Если у вас есть пакетные обновления, которые иногда затрагивают большое количество строк у подписчика, вам следует рассмотреть возможность обновления опубликованной таблицы с помощью хранимой процедуры и публикации выполнения этой хранимой процедуры. Вместо отправки обновления или удаления для каждой затронутой строки агент распространителя выполняет ту же процедуру у подписчика с теми же значениями параметров. Для получения дополнительной информации см. Публикация выполнения хранимых процедур в репликации транзакций.
Распределяйте статьи по нескольким публикациям. Если вы не можете использовать параметр -SubscriptionStreams, рассмотрите возможность создания нескольких публикаций. Распределение статей по этим публикациям позволяет репликации применять изменения к подписчикам параллельно.

d. Вопросы подписки:

Используйте независимых агентов вместо общих агентов, если у вас есть несколько публикаций на одном издателе (это значение по умолчанию в мастере создания публикаций).
Запускайте агентов непрерывно вместо частого выполнения по расписанию.

SQL Server Management Studio:Указание расписаний синхронизации.

Настройка агентов на непрерывный запуск вместо создания частых расписаний (например, каждую минуту) улучшает производительность репликации, потому что агенту не нужно запускаться и останавливаться. Когда вы настраиваете агента распространителя на непрерывный запуск, изменения распространяются с низкой задержкой на другие серверы, подключённые в топологии.

2. Уровень свойств агента:

a. Агент чтения журнала:

ReadBatchSize: Увеличьте значение параметра -ReadBatchSize для агента чтения журнала.
Описание: Агент чтения журнала и агент распространителя поддерживают размеры пакетов для операций чтения и фиксации транзакций. Размер пакетов по умолчанию составляет 500 транзакций. Агент чтения журнала читает определённое количество транзакций из журнала, независимо от того, помечены они для репликации или нет. Когда в базу данных публикации записывается большое количество транзакций, но только небольшая их часть помечена для репликации, вам следует использовать параметр -ReadBatchSize для увеличения размера пакета чтения агента чтения журнала. Этот параметр не применяется к издателям Oracle. Рабочие нагрузки с небольшими транзакциями (менее 500 команд) видят увеличение количества обрабатываемых команд в секунду при увеличении ReadBatchSize до 5000. Для больших рабочих нагрузок (транзакции с 500 до 1000 команд) увеличение ReadBatchSize даёт небольшое улучшение производительности. Увеличение ReadBatchSize приводит к записи большего количества транзакций в базу данных распространителя за один цикл обмена данными. Это увеличивает время видимости транзакций и команд для агента распространителя и вносит задержку в процесс репликации.
PollingInterval: Уменьшите значение параметра -PollingInterval для агента чтения журнала.
Описание: Параметр -PollingInterval определяет, как часто опрашивается журнал транзакций опубликованной базы данных на наличие транзакций для репликации. Значение по умолчанию — 5 секунд. Если вы уменьшите это значение, журнал будет опрашиваться чаще, что может привести к снижению задержки доставки транзакций из базы данных публикации в базу данных распространителя. Однако вам следует сбалансировать необходимость более низкой задержки с возросшей нагрузкой на сервер из-за более частого опроса.
MaxCmdsInTran: Для устранения случайных, разовых узких мест используйте параметр –MaxCmdsInTran для агента чтения журнала.
Описание: Параметр –MaxCmdsInTran определяет максимальное количество операторов, группируемых в транзакцию, когда агент чтения журнала записывает команды в базу данных распространителя. Использование этого параметра позволяет агенту чтения журнала и агенту распространителя разделить большие транзакции (состоящие из многих команд) на издателе на несколько меньших транзакций при применении команд у подписчика. Указание этого параметра может уменьшить конфликты на распространителе и снизить задержку между издателем и подписчиком. Поскольку исходная транзакция применяется меньшими единицами, подписчик может получить доступ к строкам большой логической транзакции издателя до завершения исходной транзакции, нарушая строгую атомарность транзакций. Значение по умолчанию — 0, что сохраняет границы транзакций издателя. Этот параметр не применяется к издателям Oracle.
Примечание: MaxCmdsInTran не был разработан для постоянного включения. Он существует для обхода случаев, когда кто-то случайно выполнил большое количество операций DML в одной транзакции (вызывая задержку в распределении команд, пока вся транзакция не окажется в базе данных распространителя, удерживая блокировки и т.д.). Если вы регулярно попадаете в такую ситуацию, пересмотрите свои приложения и найдите способы уменьшить размер транзакций. MaxCmdsInTran не поддерживается, если данная база данных публикации включена как для отслеживания изменений данных (CDC), так и для репликации. Использование MaxCmdsInTran в этой конфигурации может привести к потере данных в таблицах изменений CDC. Это также может вызвать ошибки первичного ключа (PK), если параметр MaxCmdsInTran добавляется и удаляется во время репликации большой транзакции.

b. Агент распространителя:

SubscriptionStreams: Увеличьте параметр –SubscriptionStreams для агента распространителя.
Описание: Параметр –SubscriptionStreams может значительно повысить общую пропускную способность репликации. Он позволяет нескольким подключениям к подписчику применять пакеты изменений параллельно, сохраняя при этом многие транзакционные характеристики, присутствующие при использовании одного потока. Если одно из подключений не может выполнить или зафиксировать, все подключения прервут текущий пакет, и агент будет использовать один поток для повторной попытки выполнения неудачных пакетов. До завершения этой фазы повторной попытки у подписчика могут быть временные транзакционные несоответствия. После успешной фиксации неудачных пакетов подписчик возвращается в состояние транзакционной согласованности. Значение для этого параметра агента можно указать с помощью @subscriptionstreams в sp_addsubscription (Transact-SQL).
Поток монитора блокировок: Агент распространителя поддерживает поток монитора блокировок, который обнаруживает блокировки между сеансами. Если поток монитора блокировок обнаруживает блокировку между сеансами, агент распространителя переключается на использование одного сеанса для повторного применения текущего пакета команд, который не удалось применить ранее. Поток монитора блокировок может обнаруживать блокировки между сеансами агента распространителя. Однако поток монитора блокировок не может обнаруживать блокировки в следующих ситуациях:
- Один из сеансов, в котором происходит блокировка, не является сеансом агента распространителя.
- Взаимная блокировка сеансов замораживает деятельность агента распространителя.
В этой ситуации агент распространителя координирует все сеансы для совместной фиксации, как только их команды будут выполнены. Взаимная блокировка между сеансами происходит, если верны следующие условия:
- Блокировка происходит между сеансами агента распространителя и сеансом, который не является сеансом агента распространителя.
- Агент распространителя ожидает завершения выполнения команд всеми сеансами, прежде чем координировать все сеансы для совместной фиксации.
CommitBatchSize: Увеличьте значение параметра -CommitBatchSize для агента распространителя.
Описание: Фиксация набора транзакций имеет фиксированные накладные расходы; фиксируя большее количество транзакций реже, накладные расходы распределяются по большему объёму данных. Увеличение CommitBatchSize (до 200) может улучшить производительность, так как больше транзакций фиксируется у подписчика. Однако преимущество увеличения этого параметра снижается, когда стоимость применения изменений ограничивается другими факторами, такими как максимальная скорость ввода-вывода диска, содержащего журнал. Кроме того, следует учитывать компромисс: любой сбой, который заставляет агента распространителя начать заново, должен откатить и повторно применить большее количество транзакций. Для ненадёжных сетей меньшее значение может привести к меньшему количеству сбоев и меньшему количеству транзакций для отката и повторного применения в случае сбоя.

Обратитесь к ссылке ниже для получения подробностей: Повышение производительности репликации транзакций

MS SQL Server дело тонкое...

13.12.25

Диагностика проблем с производительностью репликации транзакций