По материалам статьи Andy Warren на SWYNK.COM: "Transactional Replication - Running in Non-Continous Mode"

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

Push Subscription Wizard/Set Distribution Agent Sedule/Using the following shedule:

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

-Publisher [ANDY] -PublisherDB [DEADLOCK] -Distributor [ANDY] -DistributorSecurityMode 1 -Continuous

Обратите внимание на параметр '-Continuous'. Это означает, что после того, когда Вы определили подписку, чтобы распределить транзакции подписчику, log reader не перестанет контролировать журнал транзакций и записывать транзакции базы данных дистрибутора (издателя). Каждый log reader агент (logread.exe, один на публикацию) использует приблизительно 1700КБ памяти. Это - не большое отвлечение ресурсов, но высвобождение их положительно скажется на распределение памяти и уменьшит загрузку сервера.
При запуске log reader потери транзакций не происходит. Даже если зарегистрированные в журнале записи будут усекаться в результате прохождения контрольной точки, транзакции относящиеся к репликации остаются в журнале, пока log reader не сможет их обработать.
Если Вы можете позволить какое то время распределяемым транзакциям подождать, просто отредактируйте каждое задание для log reader, и удалите '-Continuous' в конце второго шага. После этого можете проследить за вашим log reader и агентом дистрибуции, которые уже не будут выполняться непрерывно. В идеале Вам нужно откорректировать график так, чтобы log reader выполнялись поочерёдно, один за другим. Таким образом Вы добьетесь самой низкой загрузки сервера при сохранении обслуживания ваших подписчиков, модифицируемых довольно часто но не немедленно.