Записи не реплицируются при вставке с помощью настраиваемой хранимой процедуры репликации

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

Моя проблема возникает при попытке реплицировать таблицу журнала обратно в основную базу данных публикации. Вот что я сделал:

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

А теперь самое странное: если я вручную добавлю запись в таблицу журнала с помощью SQL Server Management Studio, запись будет реплицирована нормально. Если запись добавлена ​​настраиваемой хранимой процедурой репликации, этого не произойдет. Статус всегда будет отображать «Реплицированные транзакции недоступны».

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

Может кто-нибудь объяснить, что я сделал не так?

ОБНОВЛЕНИЕ: у меня наконец-то есть ответ на эту проблему несколько месяцев назад, просто у меня не было времени обновить этот вопрос. Нам нужно зарегистрировать звонок в службу поддержки Microsoft, но у нас есть рабочее решение.


ОТВЕТ: Для решения проблемы при добавлении подписки вам необходимо запустить скрипт, как показано ниже:

sp_addsubscription @publication = 'TEST', ..., @loopback_detection = 'false'

Ключ к решению - последний параметр, показанный выше. По умолчанию сгенерированный скрипт подписки не имеет этого параметра.


person alextansc    schedule 11.10.2008    source источник


Ответы (2)


У меня наконец-то есть ответ на эту проблему несколько месяцев назад, просто я никогда не удосужился обновить этот вопрос. Нам нужно зарегистрировать звонок в службу поддержки Microsoft, но у нас есть рабочее решение.

Для решения проблемы при добавлении подписки необходимо запустить скрипт, как показано ниже:

sp_addsubscription @publication = 'TEST', ..., @loopback_detection = 'false'

Ключом к решению является последний параметр, показанный выше: @loopback_detection = 'false'. По умолчанию сгенерированный скрипт подписки не имеет этого параметра.

person alextansc    schedule 16.03.2009

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

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

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

Если вы давно это решили, мне было бы интересно услышать решение.

Редактировать:

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

person Timbo    schedule 09.02.2009