Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
Сервер
Microsoft SQL Server 2005 - 9.00.3257.00 (X64)   Jun 12 2008 16:47:07   Copyright (c) 1988-2005 Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2) 
репликация слиянием, push
на таблицу повешен SQL Server DATETIME (Later Wins) Conflict Resolver, указано поле с датой.
При этом все равно появляются данные в списке конфликтов
The same row was updated at both 'xx.h1' and 'xxx.h2'. The resolver chose the update from 'xx.h1' as the winner.
поле с датой, которое указано в conflict resolver, отличается для winner и loser, хотя winner и правильный, но откуда вообще вылазит конфликт, если указанный conflict resolver должен без проблем его разрулить ?
13 ноя 09, 11:25    [7924587]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
ап.
Неужели никто с таким не сталкивался? :(
17 ноя 09, 16:42    [7940983]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
На издателе и подписчике повесил триггер на update, который пишет в лог табличку кто и когда обновлял данные.
Вот что выяснилось:
в 11:15:25 данные обновились на подписчике. В 11:15:45 стартовала, в 11:15:51 завершилась репликация. В 11:15:49 данные обновились на издателе (судя по данным, залились с подписчика), в результате в replication monitor видим
upload changes on publisher - 20 строк и 20 конфликтов
download changes to subscriber - 20 строк
Откуда взялось
download changes to subscriber и конфликты, если на издателе ничего не обновлялось?
Если бы на издателе одновременно с репликацией происходил какой-то свой update, то в лог записалось бы как минимум 2 записи (было бы 2 транзакции на одну строку). Но в логе запись только одна, следовательно только пришло обновление с подписчика, или я совсем ничего не понимаю :(
PS. И такие конфликты вылазят хотя бы раз в день (данные в таблицах обновляются гораздо чаще).
18 ноя 09, 15:39    [7945912]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
?
20 ноя 09, 10:31    [7954855]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
Такое чувство, что только у меня конфликты непонятные возникают в реплике :(
26 ноя 09, 11:04    [7980863]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
up
30 ноя 09, 14:07    [7996713]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
И по прежнему жду помощи :-[
10 дек 09, 11:48    [8045508]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
gallam
Member

Откуда:
Сообщений: 178
ABV,
В таблицах конфликтов посмотрите причину конфликта?
11 дек 09, 13:20    [8052920]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
gallam,

В таблицах конфликтов причина - одновременное редактирование подписчике и издателе:

The same row was updated at both 'xx.h1' and 'xxx.h2'. The resolver chose the update from 'xx.h1' as the winner.
Реально такого не происходит, в 3-м посте я описал ситуацию. Еще уточню, одни и те же таблицы участвуют в нескольких публикациях, у каждой из которых один подписчик (так сделано из-за фильтров), но данные реально правятся на одном из подписчиков, одновременного редактирования не происходит.
14 дек 09, 14:47    [8063775]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
gallam
Member

Откуда:
Сообщений: 178
ABV,
Я бы поставил триггер свой на события update к таблице на издателе и писал лог, потом лог можно посмотреть.
Заодно увидели бы, почему изменяются данные, тем более, что раз в сутки события подобные появляются.
Только триггер с хинтом NOT FOR REPLICATION
15 дек 09, 11:19    [8067691]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
ABV
Member

Откуда: Minsk
Сообщений: 88
gallam,
да это мне давно уже в голову пришло, делал, смотри 3-й пост сверху. Только триггер как раз не должен быть not for replication, потому что на издатель данные приходят только по реплике.
Никто на нем ничего не апдейтит, то есть триггер срабатывает только при выполнении репликации (данные апдейтятся с подписчика, и сразу же возникает конфликт), в том-то и прикол.
На форуме MSDN мне отписали, что это может быть системный апдейт, и на этом тоже все заглохло :(
Куда копать - не представляю. Пока при появлении конфликтов высылается письмо по электронке и кто-нибудь их разруливает, но не все время ведь этим заниматься :(
15 дек 09, 12:12    [8068135]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
Петр
Member

Откуда: Москва
Сообщений: 793
Аналогичная ситуация. также не знаю почему это происходит....
4 фев 10, 11:51    [8293880]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Не отрабатывает conflict resolver в репликации  [new]
Proga
Member

Откуда: МО
Сообщений: 3042
Подыму, может кто-то уже накопал почему сей момент происходит.
20 май 11, 15:57    [10685469]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
Proga
Member

Откуда: МО
Сообщений: 3042
Сервер Microsoft SQL Server 2008 (SP2) - 10.0.4000.0 (X64)
Sep 16 2010 19:43:16
Copyright (c) 1988-2008 Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
20 май 11, 16:04    [10685546]     Ответить | Цитировать Сообщить модератору
 Re: Не отрабатывает conflict resolver в репликации  [new]
Proga
Member

Откуда: МО
Сообщений: 3042
Накопал только это
автор
We have been experiencing some similar problems with false conflicts causing the loss of data changes originated at subscribers in favor of the "unchanged" record at the publisher.

We do use parameter filters and joins on theses bidirectional publications. After several tests we were able to reproduce and isolate the processing order of the articles as the cause of at least some of these false conflicts.

Once we could reproduce the case we opened an incident with MS and the explanation they gave us was approximately the following:

By default, if you don't specify a value for the processing_order parameter of an article within a bidirectional publication, the article id (nickname) is used as the ordering criterion. If precomputed partitions are defined (as in our case via parameter filters for the parent table combined with joins for the children tables in the publication), whenever a partition realigment is produced (e.g. updating the column used on the join or deleting the row) at any level of the join hierarchy, a dummy update is executed on each row located at a lower level in the join hierarchy. This is done so that the DB "knows" to which partitions a row is belonging at any time. These dummy updates produce the subsequent records in MSmerge_contents and MSmerge_genhistory but only update the partition information (MSmerge_current_partition_mappings, MSmerge_past_partition_mappings) for the subscriber causing the dummy update.

The problem here is that if the processing order of the articles is such that a parent table is processed before some of its children tables, and the column or columns involved on the filtering (therefore on the partition definition) have been updated (or the row itself has been deleted, for instance), this will produce a dummy update on the rows of its child table at the publisher. Thus, when the child table is processed if it must upload to the publisher an actual update performed at the subscriber, it will conflict with the dummy update due to the partition realigment already executed at the publisher, thus causing the loss of the actual changes in favor of the "dummy" updated version.

Fortunately the processing order can be manually modified using the sp_changemergearticle stored procedure to set the processing_order property of each article in the publication. In order to avoid this issue, the processing order should be set in ascending order from the bottom of your join hierarchy to the top (root), so that the first articles to be processed are those at the leaves of your tree structure defined by the joins (deletes will be processed in the reverse order automatically). To change the processing order of the articles, just execute on the publisher DB:

exec sp_changemergearticle @publication = 'YourPublication' , @article = 'YourArticle', @property = 'processing_order', @value = 10, @force_invalidate_snapshot = 0, @force_reinit_subscription = 0

Please note that this change will be replicated to the subscribers as a schema change and might impact a little on the duration of its first synchronisation.

I hope this helps.

Edited byAngel del Rio Friday, March 04, 2011 12:42 PMFixed a typo on how the processing order must be set (bottom to top)


Кто уже пробовал этот метод, отпишитесь. Времени впритык.
20 май 11, 16:27    [10685787]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить