Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
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) после этого идет сообщение: Произошел сбой в агенте репликации. Дополнительные сведения см. в журнале в сообщении для предыдущего шага задания или в мониторе репликации. Шаг завершился с ошибкой. По предыдущим сеансам все тоже - останавливается на последних двух таблицах. Еще перед этим я нашел сообщение о неправильном завершении работы агента моментальных снимков, которое сейчас я почему то найти не могу. Поэтому и не могу привести точно сообщение. Подскажите в какую сторону копать, чтобы разрулить ситуацию. ПРодолжается уже дня три такое. Сразу не заметил так как в Мониторе репликации ни о каких ошибках не сообщается - просто обмен не идет. Как сейчас быть? Проще всего конечно инициализировать подписку, но боюсь что может пропасть уже какая то информация на подписчике? Прикладываю файл минидампа - не знаю как его читать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2019, 13:22 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Вопросы: можно ли и нужно ли запустить опцию "Проверка подписки" и как пользоваться ее результатами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2019, 13:27 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Опция не помню точно как называется - типа "подгрузить данные с подписчика перед применением моментального снимка при повторной синхронизации" - именно так и сработает? У нас пуш-репликация и при реинициализации я так понимаю данные могут пропасть у подписчика. Эта опция поможет избежать потери данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2019, 13:31 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Судя по ошибке в минидампе, было бы неплохо прогнать нормальный тест памяти. Например, memtest86+ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2019, 15:01 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
в последние 2 дня мне пришлось несколько раз перегружать сервер - публикатор из-за установки обновлений WINDOW SERVER 2008R. Кроме этого я сделал попытку установить и SQL SERVER 2008 SP3 через этот же механизм обновлений WINDOWS. Но по нему был статус - отказ. Не тут ли причины кроются? Что до памяти - то несколько месяцев назад были похожие проблемы (неожиданная перегрузка WINDOWS сервера на котором установлен SQL) из-за памяти. Причиной была попытка очистки сервера от пыли при помощи специального баллончика со сжатым газом. Никогда так не делайте! Вручную вынул, почистил и установил планки обратно - прошло. Но это к слову. А что все таки рационально делать сейчас с репликацией - пользователи брюзжат и объем информации который может потеряться наростает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2019, 15:38 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
В мониторе репликации все время спотыкается на этом: Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения 1). Очевидно что то с этой таблицей. Как проверить что именно? И еще - я попросил проверить подписку. В хэлпе написано что результаты проверки будут видны в мониторе. Но там все по прежнему . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2019, 16:00 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Борения за восстановление подписки продолжаются. Пометил подписку на повторную инициализацию с загрузкой несинхронизированных данных с подписчика. Теперь в журнале синхронизации выдается такое сообщение Не удается распространить сценарий схемы "exec sp_repldropcolumn '[dbo].[ЖурналОтгрузок]', 'НазванияОС', 1" на подписчика. (Источник: MSSQL_REPL, номер ошибки: MSSQL_REPL-2147201001) Не удалось выполнить этот шаг, так как таблица "[dbo].[ЖурналОтгрузок]" не является частью ни одной публикации. (Источник: MSSQLServer, номер ошибки: 21246) Полез в эту таблицу. В публикации она значится. С полем же такая проблема - на подписчике оно почему то оказалось предпоследним по счету, а в издателе - последним. Как такое могло произойти - непонятно. Все необходимые дополнительные поля уже много лет добавляются исключительно через процедуру sp_repladdcolumn, и порядок их следования всегда был одинаков. Попробовал на подписчике в конструкторе таблиц поменять поля местами - номер удался. После этого запустил синхронизацию с указанными выше последствиями. Имеет смысл где то ковыряться еще или лучше уж убить подписку и создать заново? Вопрос потери информации на подписчике уже не столь важен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2019, 14:13 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
garvy, проверьте базу, DBCC и так далее, если была внезапная остановка. Кэш не сбросился, не дописались метаданные, что угодно могло сломаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2019, 14:36 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
В итоге удалил и по новой создал подписку. Проработала пару часов нормально и опять то же самое: Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения 1). На этом все обрывается. Команда DBCC CHECKDB(N'__') WITH ALL_ERRORMSGS в базе издателе и в базе подписчике а также системных базах ошибки не выдает. Тупик. Подскажите что делать дальше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 09:54 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
параллельно с этой подпиской имеется другая, работает без проблем. Архитектура идентичная. Просто на другой сервер уходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 09:57 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Наверное надо запустить профайлер. Подскажите - запускать на издателе и подписчике? Что искать? Какие события выставлять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 10:23 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
авторС полем же такая проблема - на подписчике оно почему то оказалось предпоследним по счету А последний какой столбец? Наверняка добавленный репликацией со свойством ROWGUIDCOL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 10:54 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
прикладываю файл трассировки. См. в районе 900 строка и далее - может кому что понятно что - или какие то еще события надо отлавливать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:04 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Тяп-ляп, да уже этот момент проехали - я пересоздал подписку. Но нет? там этого не было. Пjдписка эта работала без каких либо остановок несколько лет.Все rowguidы были уже на местах. Просто периодически по мере потребности добавлялись новые удалялись старые столбцы в схему репликации через sp_repladdcolumn sp_repldropColumn. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:09 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Репликация слиянием чувствительна к порядку столбцов в таблицах на издателе и подсписчике. Именно в самих таблицах, а не в настройках публикации. Если порядок отличается, не будет работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:14 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Порядок нарушается по такой схеме: 1. на издателе создается публикация с таблицей, у которой нет столбца с ROWGUIDCOL 2. в процессе создания публикации репликация создает новый столбец с ROWGUIDCOL типа uniqueidentifier 3. на подписчике этот столбец также создается при создании подписки 4. все работает, жизнь идет - в таблицу добавляются столбцы 5. на подписчике удаляем подписку - столбец со свойством ROWGUIDCOL удаляется репликацией. Т.к. публикация осталась на издателе - там столбец остается. 6. снова на подписчике создаем эту подписку - столбец из п.2 появляется в таблице. Естественно, последним по номеру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:23 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Как этого избежать: 1. добавлять столбцы ROWGUIDCOL самому и на издателе, и на подписчиках до добавления таблицы в публикацию. в этом случае репликация не будет удалять столбец, т.к. не ею он создан. 2. для уже созданных публикаций изменить в системной таблице для описания таблиц в публикации флаг "создан публикацией" (имена таблиц и флага не помню уже, найти можно, они говорящие). сделать это и на издателе, и на подписчике 3. чтобы репликация при удалении подписки не удаляла столбец, создавать "фейковую" публикацию с этой таблицей и подписывать на нее. тогда при удалении рабочей подписки таблица останется неизменной. после удалить фейковую подписку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:30 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Спасибо за хитрости - может и пригодится когда. Но сейчас проблема не в rowguid. А не может это быть в слишком большой истории. Это может помочь? . Там речь идет похоже об SQL SERVER 2000. E vtyz 2008. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:51 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:51 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:52 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Я этот опыт получил на 2008 R2. Думаю, что это поведение не менялось никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 11:54 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Вряд ли проблема в количестве строк в таблицах MSmerge_contents, MSmerge_tombstone и MSmerge_genhistory. Когда данных там много, очень медленно начинает работать, но ошибок нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 12:03 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
все же полез проверять эти показатели. Установил что в свойствах подписок в публикации стоит опция "Срок действия подписок никогда не истекает". Соответственно таблицы эти не чистятся и содержат уже ого-го сколько строк. В среднем по 1.5 млн. каждая. Хочу их почистить. В этой связи вопросы - могу я сейчас сменить этот параметр на "Срок действия подписок завершится ... и т.д." При работающих подписках это пройдет? Надо ли запускать процедуру sp_mergemetadataretentioncleanup или все произойдет автоматом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 13:48 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Срок действия подписок - это не то, что нужно. После этого срока сама подписка протухнет и потребуется ее переинициализация. Другая срок там есть, только для хранения данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 14:08 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Собственно стал смотреть строку из профайлера на которой все стопорится: 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 что репликация слиянием может не проходить на этой процедуре из за обилия метаданных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 14:16 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Ошибся я немного. "Срок действия подписок" - это то, что нужно для регулирования кол-ва данных в таблицах MSmerge_contents, MSmerge_tombstone и MSmerge_genhistory. Поставь 14 дней. Тогда прописка протухнет и удалится через 14*2 дней. Тут описано: https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2005/ms151778(v=sql.90) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 14:23 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Добавлю: подписка протухнет, если не будет синхронизаций. Если обмен данными идет регулярно, то никаких протуханий не будет: A subscription to a merge publication expires if it has not synchronized with the Publisher within the publication retention period. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 14:39 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
метаданные почистил на издателе и обоих подписчиках. После запуска синхронизации все то же самое. Теперь буду наверное полностью уничтожать публикацию и воссоздавать ее заново. не знаю что еще сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 16:25 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Очистил метаданные на издателе и подписчиках. Все то же самое, синхронизация не идет с той же ошибкой. Теперь наверное уже надо удалить публикацию и создать ее заново? Не знаю что еще сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 16:27 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
авторЕще перед этим я нашел сообщение о неправильном завершении работы агента моментальных снимков Думаю, с этого начались проблемы. Я бы переподписал проблемного подписчика для начала. С контролем столбцов со свойством ROWGUIDCOL. Удалять публикацию - это слишком кардинально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2019, 16:38 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Все ходит по кругу. После вчерашних действий с очисткой метаданных накатил обновления WINDOWS SERVER 2008 на подписчике, перегрузил оба сервера (издатель и подписчик) и запустил подписку (с реинициализацией и подгрузкой несинхронизированных данных). Итог - ошибка: "Определение схемы целевой таблицы "dbo"."ЖурналОтгрузок" в базе данных подписки не соответствует определению схемы исходной таблицы в базе данных публикации. Инициализируйте подписку повторно без применения моментального снимка после того, как убедитесь в том, что определение схемы у целевой таблицы то же самое, что у исходной таблицы". Это уже было. Но я не понимаю - когда применяется снимок - ведь структура таблицы передается на подписчика? Откуда вообще это взялось - перепутанные два последних поля в этой таблице на подписчике? ROWGUID стоит в глубине, после него стоит целый перечень полей, которые были созданы уже в ходе работающей подписки. Да и вручную на подписчике я перед этим исправил. На издателе: CREATE TABLE [dbo].[ЖурналОтгрузок]( [№№] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, [Документ] [int] NULL, [ДатаОп] [datetime] NULL, [Операция] [varchar](50) NULL, [Кто] [varchar](14) NULL, [Проект] [varchar](50) NULL, [План] [bit] NULL, [Распоряжение] [varchar](250) NULL, [СпособОтгр] [varchar](50) NULL, [Примечание] [varchar](250) NULL, [Дата] [datetime] NULL, [Сотрудник] [varchar](14) NULL, [ДатаОтгр] [datetime] NULL, [GD] [varchar](50) NULL, [rowguid] [uniqueidentifier] ROWGUIDCOL NOT NULL, [КонтрТрансп] [bit] NULL, [КодТр] [int] NULL, [Паспорта] [tinyint] NULL, [ТоргМарка] [tinyint] NULL, [МестоОтгр] [varchar](50) NULL, [МеткаГр] [bit] NULL, [МеткаБЧ] [bit] NULL, [МеткаОС] [bit] NULL, [НазванияОС] [varchar](1000) NULL, [ДопФайл] [varchar](300) NULL На подписчике: CREATE TABLE [dbo].[ЖурналОтгрузок]( [№№] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, [Документ] [int] NULL, [ДатаОп] [datetime] NULL, [Операция] [varchar](50) NULL, [Кто] [varchar](14) NULL, [Проект] [varchar](50) NULL, [План] [bit] NULL, [Распоряжение] [varchar](250) NULL, [СпособОтгр] [varchar](50) NULL, [Примечание] [varchar](250) NULL, [Дата] [datetime] NULL, [Сотрудник] [varchar](14) NULL, [ДатаОтгр] [datetime] NULL, [GD] [varchar](50) NULL, [rowguid] [uniqueidentifier] ROWGUIDCOL NOT NULL, [КонтрТрансп] [bit] NULL, [КодТр] [int] NULL, [Паспорта] [tinyint] NULL, [ТоргМарка] [tinyint] NULL, [МестоОтгр] [varchar](50) NULL, [МеткаГр] [bit] NULL, [МеткаБЧ] [bit] NULL, [МеткаОС] [bit] NULL, [ДопФайл] [varchar](300) NULL, [НазванияОС] [varchar](1000) NULL, Отличается порядок следования двух последних полей. В воскресенье я уничтожил подписку и создал ее заново. Применил . Репликация пошла. Т.е. все было симметрично на подписчике и на издателе, если она пошла? Через 2 часа все прекратилось с ошибкой: Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения 1) ( и в профайлере своя - 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). После вчерашних действия с очистками метаданных, перегрузками серверов получил в итоге опять сообщение об этом несоответствии схем. Если я сейчас опять уничтожу подписку и опять ее запущу по новой - не получится ли снова та же ситуация? Ведь причина так и не понятна. Как мне быть: а) вручную исправить схему таблицы на подписчике и попытаться еще раз пересоздать подписку (уже делал так - все слетело), б) пометить подписку на реинициализацию с подгрузкой несинхронизированных данных - сделал так - и получил ошибку о несоответствии схем, в) вручную исправить схему таблицы на подписчике и пометить имеющуюся подписку на реинициализацию (без подгрузки несинхронизированных данных). Что то еще? "Инициализируйте подписку повторно без применения моментального снимка" - это как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2019, 15:26 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
авторкогда применяется снимок - ведь структура таблицы передается на подписчика только в том случае, если подписка имеет опцию "удалить (пересоздать) таблицы перед применением снимка". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2019, 11:21 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Посмотри данные в таблице sysmergeschemachange Справка по ней здесь: https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/sysmergeschemachange-transact-sql?view=sql-server-2017 Она есть и на издателе и на подписчике. В ней среди прочих операций регистрируются все изменения таблиц, в том числе и добавление столбцов. Найди в ней строки со скриптами добавления двух проблемных столбцов. Порядок строк (и порядок применения скиптов в них) определяется столбцом schemaversion, если не ошибаюсь. Возможно, порядок не совпадает на издателе и подписчике. Но это просто для интереса посмотреть. Для решения проблемы я бы изменил порядок столбцов в таблице на подписчике, сначала удалив подписку. Перед удалением подписки надо решить возможную проблему с удалением столбца ROWGUIDCOL, я уже писал ранее как это сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2019, 11:43 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
спасибо, так и сделал - удалил следы репликации на подписчике и поменял столбцы. вроде как работает. Правда перед этим еще немного покочевряжилась, выдавая всякие странные сообщения типа "Подписка не зарегистрирована на издателе" и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2019, 11:08 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
проработало успешно пол дня и опять слетела на то же самое - Перечисление вставок и обновлений в статье "Заказы Документы" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2019, 13:59 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Подробнее текст ошибки есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2019, 15:50 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Было в прошлый раз: Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения 1) ( и в профайлере своя - 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). Только сейчас без (пакет поколения 1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2019, 16:29 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Такой метод лечения подойдет? 1. Удаляю все подписки на издателе 2. Вношу необходимые изменения в свойства полей на издателе (давно назрело но из за работающей репликации не мог) 3. Добавляю статьи в публикацию (давно назрело но из за работающей репликации не мог) (или потребуется пересоздание публикации?) 4. Делаю резервную копию базы издателя 5. Восстанавливаю ее на подписчике без настроек репликации 6. Создаю подписку на издателе 7. Синхронизирую (без применения моментального снимка - кажется такая опция была?) 8. Наслаждаюсь следующие 5 лет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 09:15 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Без применения снимка не получится. В снимке не только пользовательские данные, но и триггеры, процедуры, системные данные и т.п. Можно не заливать на подписчика пользовательские данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 09:42 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
ОК. Попробую реализовать за выходные. База у нас сравнительно небольшая - каких то пару гигабайт так что можно себе позволить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 09:45 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Я бы все-таки профайлером нашел проблемной вызов. Вот это: авторexec sys.sp_MSadd_merge_history90 @p1 output,12,3,N'Перечисление вставок и обновлений статьи "Заказы Документы" (пакет поколения всего лишь запись в лог сообщения об ошибке. Проблемный вызов был раньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 09:45 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Не помню вот - получится ли изменять свойства таблиц на издателе при имеющейся публикации? Кажется что все таки нет. Тогда 1а. Скриптую публикацию. 1.б Удаляю публикацию. 1в (Нужно ли провести на всякий случай какие то очистительные процедуры от остатков репликации на издателе? (окуривание, молитвы)) 2а. Воссоздаю публикацию. В профайлере я ничего понятного мне до этого вызова не нашел. Не буду тратить время - лучше буду действовать по вновь утвержденному плану. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 09:53 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
В публикации можно менять все. Часть изменений требует переинициализацию подписчика, часть - нет. Т.к. причина проблем не ясна, что делать дополнительно тоже не ясно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 10:25 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
например, добавить ограничение уникальности данных в столбце без удаления публикации получится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 10:32 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Как мне помнится - да. Еще надо смотреть настройки в публикации - будет ли это ограничение передаваться по репликации и допустимо ли оно на подписчике для его данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 10:44 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
В субботу полностью остановил процесс репликации на издателе, убрал все подписки,убрал все публикации, провел DBCC CheckDB, заархивировал базу данных, перекинул ее на подписчика, разахивировал без настроек репликации. Создал обратно публикацию, создал обратно подписки - засинхронизировал и все пошло. Проработало воскресенье в условиях когда пользователей было минимум, фактически один. В понедельник, когда сотрудники вышли на работу - 2 часа работы и та же ошибка 2019-07-22 06:33:00.456 (C) Корпорация Майкрософт, 2008 2019-07-22 06:33:00.456 Агент репликации Microsoft SQL Server: replmerg 2019-07-22 06:33:00.456 2019-07-22 06:33:00.456 The timestamps prepended to the output lines are expressed in terms of UTC time. 2019-07-22 06:33:00.456 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 0x2C8461A7429D8C49B36B4FB1887FD3DB -XJOBNAME SERVER-MO-VS_ShEn-VS_PUBLICATION-SBS-SERVER-13 -XSTEPID 2 -XSUBSYSTEM Merge -XSERVER SERVER-MO -XCMDLINE 0 -XCancelEventHandle 0000000000000C20 -XParentProcessHandle 0000000000000BFC 2019-07-22 06:33:00.485 Соединение с Распространитель "SERVER-MO" 2019-07-22 06:33:00.574 Инициализация 2019-07-22 06:33:00.577 Соединение с Издатель "SERVER-MO" 2019-07-22 06:33:01.504 Соединение с Подписчик "SBS-SERVER" 2019-07-22 06:33:01.560 Получение сведений о публикации 2019-07-22 06:33:01.637 Получение сведений о подписках. 2019-07-22 06:33:24.967 Передача изменений данных на издатель 2019-07-22 06:33:27.023 Перечисление удалений во всех статьях 2019-07-22 06:33:27.087 Перечисление вставок и обновлений в статье "Registration" 2019-07-22 06:33:27.539 [3%] [секунд осталось: 52] Перечисление вставок и обновлений в статье "ЖурналПодСпецификаций" 2019-07-22 06:33:30.101 [3%] [секунд осталось: 52] Перечисление вставок и обновлений в статье "Заказы Документы" ******************************************************************************** Microsoft (R) SQL Server Replication Agent A replication agent encountered a fatal error and was shut down. A mini-dump has been generated at the following location: C:\Program Files\Microsoft SQL Server\100\Shared\ErrorDumps\ReplAgent20190722093327_0.mdmp Файл минидампа прилагаю. Также привожу последние строчки из лога дампа 1230:11C4) 07/22/19 10:36:33, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used (1230:11C4) 07/22/19 10:36:33, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used (1230:11C4) 07/22/19 10:36:34, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used (1230:11C4) 07/22/19 10:36:34, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files\Microsoft SQL Server\100\Shared\ErrorDumps\ReplAgent20190722103633_0.mdmp (1230:11C4) 07/22/19 10:36:34, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files\Microsoft SQL Server\100\Shared\dbghelp.dll' (1230:11C4) 07/22/19 10:36:34, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files\Microsoft SQL Server\100\Shared\dbghelp.dll' : '6.8:4.0' (1230:11C4) 07/22/19 10:36:34, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files\Microsoft SQL Server\100\Shared\dbghelp.dll' : '6.8:4.0' (1230:11C4) 07/22/19 10:36:34, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files\Microsoft SQL Server\100\Shared\SQLDUMPER.EXE' (1230:11C4) 07/22/19 10:36:34, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files\Microsoft SQL Server\100\Shared\SQLDUMPER.EXE' : '2007.100:1600.22' (1230:11C4) 07/22/19 10:36:34, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files\Microsoft SQL Server\100\Shared\SQLDUMPER.EXE' : '10.0:1600.22' (1230:11C4) 07/22/19 10:36:34, ACTION, replmerg.exe, Watson Invoke: No (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 1: 3744 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 2: 0 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 3: 0:0 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 4: 0000000000CF0DC8 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parsed parameters: (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 3744 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x0000000000CF0DC8 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL> (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x0000000000000000 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x0000000000000000 (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL> (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL> (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL> (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Dump is associated with file C:\Program Files\Microsoft SQL Server\100\Shared\ErrorDumps\ReplAgent20190722104327_0.mdmp (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files\Microsoft SQL Server\100\Shared\ErrorDumps\ReplAgent20190722104327_0.mdmp (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files\Microsoft SQL Server\100\Shared\dbghelp.dll' (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files\Microsoft SQL Server\100\Shared\dbghelp.dll' : '6.8:4.0' (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files\Microsoft SQL Server\100\Shared\dbghelp.dll' : '6.8:4.0' (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files\Microsoft SQL Server\100\Shared\SQLDUMPER.EXE' (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files\Microsoft SQL Server\100\Shared\SQLDUMPER.EXE' : '2007.100:1600.22' (AA8:5C8) 07/22/19 10:43:27, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files\Microsoft SQL Server\100\Shared\SQLDUMPER.EXE' : '10.0:1600.22' (AA8:5C8) 07/22/19 10:43:27, ACTION, replmerg.exe, Watson Invoke: No Профайлер сейчас не смотрел, но по видимости там все то же самое 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) Уже не знаю куда дальше двигаться. Подскажите что делать. Надо наверное как то профайлер подробнее настаивать. У меня такое ощущение что дело и не в репликации вовсе, а в чем то другом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2019, 10:56 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2019, 11:27 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Хо-хо! А ведь началостб то все после установки обновлений WINDOES!!!!! 2. Удаление установленных обновлений Если ошибка 0xc0000005 стала частым гостем после установки системных обновлений, можно попробовать удалить некоторые из них. Да, это не шутка, в данном случае сложности действительно могут возникать при наличии пакетов с номерами KB2872339, KB2859537 и KB2882822 в списке установленных. Также с аналогичной ошибкой сталкивались те пользователи, у которых на компьютерах появлялось обновление KB971033. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2019, 12:35 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
И еще из наблюдений - активности SQL SERVER на издателе Все время висит вот этот процесс - что это - не ясно. Может это причина? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2019, 13:20 |
|
||
|
сбой в агенте репиликации слиянием
|
|||
|---|---|---|---|
|
#18+
Проблема разрешилась откатом обновления MS SQL SERVER SP3 на издателе. При этом обновлении он не дружил с подписчиком, на котором стоял MS SQL SERVER 2008 в составе пакета MS SMALL BUSINESS SERVER 2008. На другом подписчике установлен SQL SERVER DEVELOPER EDITION 2008 и с ним что с обновлением что без подписка работала исправно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 12:39 |
|
||
|
|

start [/forum/topic.php?all=1&fid=46&tid=1687506]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
76ms |
get tp. blocked users: |
2ms |
| others: | 232ms |
| total: | 405ms |

| 0 / 0 |
