Настройка и устранение неполадок с параметром SubscriptionStreams агент распространения в SQL Server

Исходная версия продукта: SQL Server (все поддерживаемые версии)
Исходный номер базы знаний: 953199

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

Введение

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

При указании значения 2 или больше для параметра SubscriptionStreamsпорядок получения транзакций на подписчике может отличаться от порядка, в котором они были сделаны на издателе. Если это поведение вызывает нарушения ограничений во время синхронизации, следует использовать NOT FOR REPLICATION параметр, чтобы отключить принудительное применение ограничений во время синхронизации. Дополнительные сведения см. в разделе "Управление поведением триггеров и ограничений в синхронизации".

Факторы, которые следует учитывать перед включением SubscriptionStreams

SubscriptionStreams в основном заботится о задержке от распространителя к подписчику, поэтому перед решением перейти SubscriptionStreamsк ней, убедитесь, что вы действительно работаете с задержкой от распространителя к подписчику. Маркеры трассировки можно использовать в мониторе репликации или Монитор производительности счетчиках, таких как SQLServer:Replication Dist.>Dist:Delivery Latency, чтобы иметь представление о уровне задержки.

Задержка от распространителя к подписчику может быть вызвана многими причинами, например, но не ограничивается следующими:

  • Блокировка на распространителю или подписчике
  • Любое узкое место на распространителе или подписчике, например медленные диски, низкая пропускная способность сети и устаревшие статистические данные
  • Массовые транзакции, поступающие от издателя
  • Скорость входящих транзакций от издателя слишком высока
  • Триггеры или ненужные индексы в подписанной базе данных

Администратор базы данных (DBA) должен позвонить и проверить, будет ли SubscriptionStreams помочь им или нет. Например, в случае блокировки на подписчике увеличение числа одновременных подключений не поможет, но может привести к ухудшит ситуацию. В то время как в таких ситуациях, как частота входящих транзакций от издателя, слишком высока, и вы чувствуете, что один поток для агент распространения не может справиться с входящей нагрузкой, можно рассмотреть возможность увеличения значения параметра SubscriptionStreams до >=2. Это также может помочь в медленных сетевых и медленных ситуациях с дисками. В идеале максимальное значение для этого параметра равно 64, но рекомендуемое значение (или хорошее значение для начала) равно количеству физических процессоров на целевом (подписчике).

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

SubscriptionStreams— это один из этих параметров, которые не отображаются в профиле агент распространения в мониторе репликации. Значение этого параметра агента можно указать с помощью @subscriptionstreams sp_addsubscription (Transact-SQL) или добавить этот параметр в раздел команды задания агента распространителя с помощью следующей процедуры:

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

  2. Щелкните правой кнопкой мыши подписчик, который требуется включить параметр SubscriptionStreams , и выберите пункт "Просмотреть сведения". Откроется новое окно с сведениями о сеансе агент распространения.

  3. В этом новом окне выберите "Действие" в строке меню вверху и выберите агент распространения свойства задания. Откроется окно свойств задания для агент распространения.

  4. Выберите "Шаги " в левом окне панели, а затем выберите "Запустить агент " в правом окне панели и нажмите кнопку "Изменить". Откроется новое окно.

  5. Прокрутите страницу до конца раздела команды (справа) и добавьте этот параметр -SubscriptionStreams 6.

  6. Сохраните параметры и перезапустите задание агент распространения. Для реализации изменений требуется перезапуск агент распространения.

Примечание.

В приведенном выше примере задано значение 6, что означает, SubscriptionStreams что мы ищем шесть параллельных подключений для агент распространения на подписчике. Это число можно задать в вашей среде и тестировании.

Определение количества потоков

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

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

  • Не используйте параметр SubscriptionStreams.
  • Задайте значение SubscriptionStreams , равное количеству процессоров на сервере. Например, если сервер имеет восемь процессоров, задайте значение SubscriptionStreams 8.
  • Укажите разные значения для SubscriptionStreams получения оптимальной конфигурации.

При выполнении теста можно отслеживать следующие счетчики производительности агент распространения:

  • Dist: Доставленные cmds/с
  • Dist: задержка доставки

Поведение агент распространения после указания параметра SubscriptionStreams

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

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

Причины переключения агент распространения на использование только одного сеанса

Агент распространения может переключиться на использование только одного сеанса по многим причинам. Ниже приведены наиболее распространенные причины.

  • При применении изменений агент распространения один из сеансов вызывает ошибку.

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

  • Блокирующий поток монитора обнаруживает блокировку. Блокировка может возникать по одной из следующих причин:

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

    • На подписчике агент распространения выполняет инструкции языка обработки данных (DML) в нескольких таблицах. Если индексированные представления определены в этих таблицах, блокировка между двумя сеансами может возникать, когда индексированные представления обновляют ключи общего индекса.

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

Настоятельно рекомендуется не использовать следующие объекты базы данных в базе данных подписчика:

  • Ограничения внешнего ключа
  • Уникальные некластеризованные индексы
  • Индексированные представления
  • Триггеры DML, которые могут вызвать блокировку между сеансами

Как определить, переключился ли агент распространения на использование только одного сеанса

Для этого используйте один из следующих методов.

Примечание.

Хотя вы можете подтвердить, что агент распространения не переключился на один сеанс с помощью метода 1, необходимо использовать метод 2 или метод 3, чтобы убедиться, что агент распространения переключился на использование одного сеанса.

  • Метод 1

    Запросите sys.dm_exec_sessions динамического административного представления (DMV) для сеансов подключения к базе данных подписки. Если вы видите только один сеанс подключения, агент распространения, возможно, переключились на один сеанс. Если отображается несколько сеансов подключения, агент распространения по-прежнему использует указанное количество сеансов.

    Чтобы убедиться, что агент распространения переключился на один сеанс, используйте метод 2 или метод 3.

  • Метод 2.

    Запросите столбец comments таблицы msdistribution_history в базе данных распространителя. Если результат запроса содержит следующую запись, агент распространения переключился на один сеанс:

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

  • Метод 3

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

    Следующий выходной файл является примером:

    Date/Time 100 transaction(s) with 1181 command(s) were delivered. 
Date/Time 100 transaction(s) with 2672 command(s) were delivered. 
Date/Time Bucket 6 aborted the wait for Ready To Commit event, deadlock found between spid 117 and 114 
Date/Time Bucket 1 aborted the wait for Ready To Commit event, deadlock found between spid 117 and 114 
Date/Time Bucket 3 aborted the wait for Ready To Commit event, deadlock found between spid 117 and 114 
Date/Time Bucket 0 aborted the wait for Ready To Commit event, deadlock found between spid 117 and 114 
Date/Time Bucket 5 aborted the wait for Ready To Commit event, deadlock found between spid 117 and 114 
Date/Time Bucket 2 aborted the wait for Ready To Commit event, deadlock found between spid 117 and 114 
Date/Time Bucket 7 aborted the wait for Ready To Commit event, deadlock found between spid 117 and 114 
Date/Time Bucket 4 aborted the wait for Ready To Commit event, due to thread shutdown event 
... 
Date/Time Number of subscription streams has been reset from 8 to 1, state 4. 
Date/Time Disconnecting from Subscriber 
SQLInstance 
Date/Time Disconnecting from Subscriber 
SQLInstance 

Date/Time Disconnecting from Subscriber 
SQLInstance 

Date/Time Disconnecting from Subscriber 
SQLInstance 

Date/Time Disconnecting from Subscriber 
SQLInstance 

Date/Time Disconnecting from Subscriber 
SQLInstance 

Date/Time Disconnecting from Subscriber 
SQLInstance 

Date/Time Disconnecting from Subscriber 
SQLInstance 


Date/Time Connecting to Subscriber 
SQLInstance 

Date/Time The process failed to complete last batch in multi-streaming mode, it has been reset to single connection mode and is retrying the operation. 
Date/Time 21 transaction(s) with 390 command(s) were delivered.

Устранение неполадок с агент распространения, которая переключается на использование только одного сеанса

  1. Запустите SQL Server Profiler на подписчике, чтобы записать событие отчета о заблокированных процессах и событие исключения. Эти события записывают блокировку и ошибки, возникающие при применении изменений агент распространения.

    Примечание.

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

  2. Используйте один из методов в разделе "Как определить, переключился ли агент распространения на использование только одного раздела сеанса для мониторинга агент распространения.

  3. Если агент распространения переключился на один сеанс, остановите трассировку.

  4. Из выходного файла агент распространения или из столбца start_time таблицы msdistribution_history получите метку времени следующей записи:

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

  5. Откройте файл трассировки (TRC) из подписчика. Найдите скрипт блокировки или событие исключения, метка времени которого совпадает или очень близко к метке времени, полученной на шаге 4.

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

    Если вы заметили сценарий блокировки, проблема возникает из-за блокировки. Ниже приведен пример сценария блокировки:

    <blocked-process-report monitorLoop="41589"> 
    <blocked-process> 
        <process id="process3a6d438" taskpriority="0" logused="24592" waitresource="KEY: 6:72057594375700480 (0100e420fa5a)" waittime="9937" ownerId="568644832" transactionname="user_transaction" lasttranstarted="2008-05-05T04:55:04.430" XDES="0xa5619e370" lockMode="X" schedulerid="11" kpid="6104" status="suspended" spid="58" sbid="0" ecid="0" priority="0" transcount="2" lastbatchstarted="2008-05-05T04:55:04.553" lastbatchcompleted="2008-05-05T04:55:04.430" clientapp=<DistributionAgentProgram> hostname=<servername> hostpid="3980" loginname=<SQLAgentAcct>  isolationlevel="read committed (2)" xactid="568644832" currentdb="6" lockTimeout="4294967295" clientoption1="671090784" clientoption2="128056"> 
            <executionStack> 
            <frame line="5" stmtstart="642" stmtend="1600" sqlhandle="0x0300060057a14477a8c6dd00609a00000100000000000000"/> 
            </executionStack> 
            <inputbuf> 
            Proc [Database Id = 6 Object Id = 2000986455]
            </inputbuf> 
        </process> 
    </blocked-process> 
    <blocking-process> 
        <process status="sleeping" spid="68" sbid="0" ecid="0" priority="0" transcount="1" lastbatchstarted="2008-05-05T04:55:04.570" lastbatchcompleted="2008-05-05T04:55:05.103" clientapp=<DistributionAgentProgram> hostname=<servername> hostpid="3980" loginname=<SQLAgentAcct> isolationlevel="read committed (2)" xactid="568644998" currentdb="6" lockTimeout="4294967295" clientoption1="671090784" clientoption2="128056"> 
        <executionStack/> 
        <inputbuf> 
        Proc [Database Id = 6 Object Id = 1172459501]
        </inputbuf> 
        </process> 
    </blocking-process> 
</blocked-process-report>

    Скрипт блокировки записывает заблокированный сеанс и блокирующий сеанс. Заблокированный сеанс начинается с тега <blocked-process>. Сеанс блокировки начинается с тега <blocking-process>.

  7. Object Id Найдите объект Proc в заблокированном сеансе и в сеансе блокировки.

    В примере сценария Object Id Proc блокировки используется 2000986455заблокированный сеанс. Proc В Object Id сеансе блокировки задано 1172459501значение .

  8. В базе данных подписки запросите представление sys.objects , указав столбец object_id , равный идентификаторам объектов, полученным на шаге 7. При этом можно определить имена объектов.

    Например, выполните следующий запрос в контексте базы данных подписки:

    USE <SubDBName> 
GO 
SELECT name FROM sys.objects 
WHERE object_id = 1172459501 OR object_id = 2000986455

    Примечание.

    • Заполнитель <SubDBName> представляет имя базы данных подписки.
    • Обычно эти объекты являются хранимыми процедурами, которые используются в репликации.

  9. Определите индекс или индексированное представление, вызывающее блокировку. Для этого выполните следующие шаги.

    1. В скрипте блокировки найдите значение свойства waitresource.

      В примере сценария блокировки значение waitresource равно 72057594375700480.

    2. Запросите представление sys.partitions , чтобы получить идентификатор объекта и идентификатор индекса, указав столбец PARTITION_ID , равный значению waitresource , полученному на шаге 9a.

      Например, выполните следующий запрос:

      SELECT object_id, index_id FROM SYS.PARTITIONS WHERE PARTITION_ID=72057594375700480

    3. В базе данных подписки запросите представление sys.indexes , чтобы определить индекс с помощью идентификатора объекта и идентификатора индекса, полученного на шаге 9b.

      Например, выполните следующий запрос:

      USE <SubDBName> 
GO 
SELECT name, type_desc, is_unique FROM sys.indexes 
WHERE object_id = <objID> and index_id = <idxID>

      Примечание.

      • Заполнитель <objID> представляет идентификатор объекта, полученный на шаге 9b.
      • Заполнитель <idxID> представляет идентификатор индекса, полученный на шаге 9b.

  10. Если блокировка вызвана индексируемым представлением, рекомендуется удалить индексированное представление. Если блокировка вызвана уникальным некластеризованным индексом, рекомендуется удалить индекс, а затем повторно создать неукластеризованный индекс.

Описание потока монитора блокировки

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

Дополнительные сведения о потоке блокирующего монитора см. в разделе "Блокирующий поток монитора".

Возобновление нескольких сеансов агент распространения

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

Чтобы отслеживать весь процесс, изучите выходной файл агент распространения.

  • Last updated on