SQL SERVER 2008SP2. Имеется много лет работающая репликация.
Настолько много. что уже и забывается что там и как там. Но вот проявилась такая ошибка при запуске агента репликации слиянием. 2019-07-11 08:25:00.307 (C) Корпорация Майкрософт, 2008
2019-07-11 08:25:00.307 Агент репликации Microsoft SQL Server: replmerg
2019-07-11 08:25:00.307
2019-07-11 08:25:00.307 The timestamps prepended to the output lines are expressed in terms of UTC time.
2019-07-11 08:25:00.307 User-specified agent parameter values:
-Publisher SERVER-MO
-PublisherDB VS_ShEn
-Publication VS_PUBLICATION
-Subscriber SBS-SERVER
-SubscriberDB VS_ChNew
-Distributor SERVER-MO
-DistributorSecurityMode 1
-XJOBID 0x92DE30BD221DA2418D002AA1BED9E81D
-XJOBNAME SERVER-MO-VS_ShEn-VS_PUBLICATION-SBS-SERVER-10
-XSTEPID 2
-XSUBSYSTEM Merge
-XSERVER SERVER-MO
-XCMDLINE 0
-XCancelEventHandle 0000000000000C6C
-XParentProcessHandle 0000000000000BF4
2019-07-11 08:25:00.331 Соединение с Распространитель "SERVER-MO"
2019-07-11 08:25:00.406 Инициализация
2019-07-11 08:25:00.408 Соединение с Издатель "SERVER-MO"
2019-07-11 08:25:00.841 Соединение с Подписчик "SBS-SERVER"
2019-07-11 08:25:00.877 Получение сведений о публикации
2019-07-11 08:25:00.915 Получение сведений о подписках.
2019-07-11 08:25:10.217 Передача изменений данных на издатель
2019-07-11 08:25:11.468 Перечисление удалений во всех статьях (пакет поколения 1)
2019-07-11 08:25:11.595 Перечисление вставок и обновлений статьи "Registration" (пакет поколения 1)
2019-07-11 08:25:11.810 Перечисление вставок и обновлений статьи "Графиты Изготовление" (пакет поколения 1)
2019-07-11 08:25:11.953 Перечисление вставок и обновлений статьи "Графиты Паспорта" (пакет поколения 1)
2019-07-11 08:25:12.153 Перечисление вставок и обновлений статьи "ЖурналОтгрузок" (пакет поколения 1)
2019-07-11 08:25:12.361 Перечисление вставок и обновлений статьи "ЖурналПодСпецификаций" (пакет поколения 1)
2019-07-11 08:25:12.501 Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения 1)

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

Вопросы: можно ли и нужно ли запустить опцию "Проверка подписки" и как пользоваться ее результатами?

Опция не помню точно как называется - типа "подгрузить данные с подписчика перед применением моментального снимка при повторной синхронизации" - именно так и сработает? У нас пуш-репликация и при реинициализации я так понимаю данные могут пропасть у подписчика. Эта опция поможет избежать потери данных?

в последние 2 дня мне пришлось несколько раз перегружать сервер - публикатор из-за установки обновлений WINDOW SERVER 2008R. Кроме этого я сделал попытку установить и SQL SERVER 2008 SP3 через этот же механизм обновлений WINDOWS. Но по нему был статус - отказ. Не тут ли причины кроются? Что до памяти - то несколько месяцев назад были похожие проблемы (неожиданная перегрузка WINDOWS сервера на котором установлен SQL) из-за памяти. Причиной была попытка очистки сервера от пыли при помощи специального баллончика со сжатым газом. Никогда так не делайте! Вручную вынул, почистил и установил планки обратно - прошло. Но это к слову. А что все таки рационально делать сейчас с репликацией - пользователи брюзжат и объем информации который может потеряться наростает?

В мониторе репликации все время спотыкается на этом: Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения 1). Очевидно что то с этой таблицей. Как проверить что именно? И еще - я попросил проверить подписку. В хэлпе написано что результаты проверки будут видны в мониторе. Но там все по прежнему
.

Борения за восстановление подписки продолжаются. Пометил подписку на повторную инициализацию с загрузкой несинхронизированных данных с подписчика. Теперь в журнале синхронизации выдается такое сообщение Не удается распространить сценарий схемы "exec sp_repldropcolumn '[dbo].[ЖурналОтгрузок]', 'НазванияОС', 1" на подписчика. (Источник: MSSQL_REPL, номер ошибки: MSSQL_REPL-2147201001)

Не удалось выполнить этот шаг, так как таблица "[dbo].[ЖурналОтгрузок]" не является частью ни одной публикации. (Источник: MSSQLServer, номер ошибки: 21246)

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

В итоге удалил и по новой создал подписку. Проработала пару часов нормально и опять то же самое: Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения 1). На этом все обрывается. Команда DBCC CHECKDB(N'__') WITH ALL_ERRORMSGS в базе издателе и в базе подписчике а также системных базах ошибки не выдает. Тупик. Подскажите что делать дальше.

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

Наверное надо запустить профайлер. Подскажите - запускать на издателе и подписчике? Что искать? Какие события выставлять?

прикладываю файл трассировки. См. в районе 900 строка и далее - может кому что понятно что - или какие то еще события надо отлавливать?

Тяп-ляп, да уже этот момент проехали - я пересоздал подписку. Но нет? там этого не было. Пjдписка эта работала без каких либо остановок несколько лет.Все rowguidы были уже на местах. Просто периодически по мере потребности добавлялись новые удалялись старые столбцы в схему репликации через sp_repladdcolumn sp_repldropColumn.

Спасибо за хитрости - может и пригодится когда. Но сейчас проблема не в rowguid. А не может это быть в слишком большой истории. Это может помочь? . Там речь идет похоже об SQL SERVER 2000. E vtyz 2008.

все же полез проверять эти показатели. Установил что в свойствах подписок в публикации стоит опция "Срок действия подписок никогда не истекает". Соответственно таблицы эти не чистятся и содержат уже ого-го сколько строк. В среднем по 1.5 млн. каждая. Хочу их почистить. В этой связи вопросы - могу я сейчас сменить этот параметр на "Срок действия подписок завершится ... и т.д." При работающих подписках это пройдет? Надо ли запускать процедуру sp_mergemetadataretentioncleanup или все произойдет автоматом?

Собственно стал смотреть строку из профайлера на которой все стопорится:
Declare @p1 int
set @p1=1147038
exec sys.sp_MSadd_merge_history90 @p1 output,12,3,N'Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения 1)',0,1,0,0,1,N'',0,0,0,0,0,0,0,0,29,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,NULL,0
select @p1

И по поиску sys.sp_MSadd_merge_history90 нашел на SQL.ru что репликация слиянием может не проходить на этой процедуре из за обилия метаданных