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

Репликация простых транзакций

Начнем с простого случая. Предположим, у нас есть транзакция, которая добавляет 4 записи на издателе:

set xact_abort on
begin tran
insert 1
insert 2
insert 3
insert 4
commit tran

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

Сбой транзакций на издателе

Что происходит, если транзакция не выполняется на издателе? Предположим, мы выполняем ту же транзакцию, что и выше, но “Command4” не выполняется. В этом случае транзакция откатывается на издателе и ни одна строка не добавляется. В результате ни одна из этих команд не реплицируется на подписчике. В транзакционной репликации реплицируются только подтвержденные транзакции.

Сбой транзакций на подписчике

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

Большие транзакции и проблемы с таймаутом

Еще одна проблема в транзакционной репликации – работа с большими транзакциями. Если оператор обновления затрагивает большое количество строк, это может вызвать проблемы с таймаутом для агента чтения журнала. Это может привести к ошибкам, таким как “Истекло время ожидания” или “Во время ожидания ресурсов памяти произошел таймаут выполнения запроса”.

Для решения этих проблем с таймаутом можно изменить несколько параметров профиля:

• QueryTimeout: Увеличение таймаута запроса может помочь решить проблемы с таймаутом, вызванные большими транзакциями.
• MaxCmdsInTran: Этот параметр позволяет разделить большую транзакцию на несколько меньших транзакций. Однако будьте осторожны, так как это может нарушить свойства ACID исходной транзакции, если команда внутри транзакции не выполняется.
• ReadBatchSize: Этот параметр определяет количество транзакций, считываемых агентом чтения журнала в каждом цикле обработки. Установка его в меньшее значение может помочь очистить отставку от небольших транзакций и предотвратить проблемы с таймаутом.
• ReadBatchThreshold: Подобно параметру ReadBatchSize, этот параметр относится к количеству команд репликации, которые должны быть считаны из журнала транзакций в пакете обработки. Изменение его вместе с QueryTimeout может помочь устранить отставку, вызванную большими транзакциями.

Таймауты или замедление агента распределения

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

• CommitBatchSize: Этот параметр определяет количество транзакций, передаваемых подписчику, прежде чем будет выполнено оператор COMMIT. Он может использоваться для настройки пропускной способности агента распределения.
• CommitBatchThreshold: Этот параметр относится к количеству команд репликации, передаваемых подписчику, прежде чем будет выполнено оператор COMMIT. Как и CommitBatchSize, он может использоваться для оптимизации пропускной способности агента распределения.

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

Заключение

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

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