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

Откуда:
Сообщений: 57
Озаботились тут выбором репликации.
1. Написали прогу, попробовали в филиале поработать через туннель - долго.
2. Сделали repl transacion, immediate update. Работали, только код стал изощренным, чтобы не возникало "row was not found" и т.п. И при обрыве связи в филиале ничего нельзя изменить.
3. Убрали immediate update, читаем с локального пишем на издатель - несогласованности нет, год уже так работает. Озаботились автономностью работы филиалов, опять же трафик надо бы уменьшить, филиалы и на 256К не очень хорошо себя чувствуют, в центре надо минимум 1М.
4. Сейчас думаем. Хотели сделать свою репликацию - чем дальше, тем больше merge получается ;), тестим стандартный merge. Плохо, что прога под merge не писалась. Допустим есть склад, два клиента апдейтят остаток - снимают в заказе каждый 1 ед. При разрешении конфликта в merge вместо правильных 10-2 = 8 останется 9, а один из заказов отменится. В идеале, надо бы каждому подписчику свои данные (таблицы) редактировать, сейчас уже не переделаешь прогу. Да и пишут, что merge ресурсов требует, а в tran можно включить процедуры - будет "репликация процедур" - трафик меньше.

Поделитесь опытом, пожалуйста. С merge не работал, наверняка есть и подводные камни и ограничения. А что по поводу tran repl + queue update vs merge думаете?
16 июн 04, 14:12    [745254]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
Вербняков Александр
Member

Откуда: г.Таганрог, Ростовская область
Сообщений: 498
тут на самом деле проблема именно в оперативном внесении информации, при любой двусторонней репликации в результате апдейта будет нет 10 - 1 -1 а только 10 - 1 т.е. 8 не будет. Можно добиться 8 только если первый апдей оперативно прибудет на издателя и так же оперативно передасться другому подписчику чтобы на момент апдейта там было уже значение 9 а не 10 только тогда будет работать. Иначе будет либо merge конфликт, либо просто примениться последняя транзация при транзакционной репликации.
16 июн 04, 15:08    [745513]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Что касается вычисления остатка, то, возможно, вам надо посмотреть на один из стандартных Conflict Resolver'ов - "Microsoft SQL Server Additive Conflict Resolver".

Также стоит посмотреть на структуру базы. Мало ли как вы храните данные и работаете с ними. Например, можно поспорить с утверждением
dbo
В идеале, надо бы каждому подписчику свои данные (таблицы) редактировать, сейчас уже не переделаешь прогу
16 июн 04, 15:09    [745521]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Насколько я понимаю, Additive Conflict Resolver как раз и сделает так, что будет 10 - 1 - 1 = 8.
16 июн 04, 15:10    [745523]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
Вербняков Александр
Member

Откуда: г.Таганрог, Ростовская область
Сообщений: 498
2GreenSunrise

Возможно ручной резолвер не выход. Ведь конфликт будет уже между издетелем и подписчиком а не между двумя подписчиками т.е. будет конфликт 9 издателя и 9 подписчика т.к. первая транзакция пройдёт на издеталя без конфликта. На основе чего принимать решение? Откуда резолвер будет знать что было раньше 10 и надо вообще поставить 8?
16 июн 04, 15:28    [745621]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
dbo
Member

Откуда:
Сообщений: 57
1. Сейчас запись идет на издатель, есть триггер который пересчитывает остаток (вычитая из текущего нужное кол-во позиций). Так, что остается 8!, СКЛ просто блокирует в момент апдейта соответствующие таблицы, никаких конфликтов нет.
2. Additive Conflict Resolver делает суммирование значений и вообще, эти резольверы нельзя совместно назначать, для разных столбцов. Можно потом зайти в тупик и потерять время.
3. Описанная ситуация с разделением таблиц на общие (чтение) и отдельные для подписчиков позволяют свести конфликты к минимуму, иначе начинаются характерные для merge пляски с диапазонами identity и т.п. Я не говорю, что так должно быть, но - желательно.
4. Кстати tran update никакая не подойдет из-за реализации ее МС - сейчас стоят и нужны фильтры, под каждого подписчика разные, т.е. под каждого подписчика своя публикация с одной базы. Да и хорошо, что с MSDTC не надо связываться - глючный он :).
16 июн 04, 15:34    [745651]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
Лентяй
Member

Откуда:
Сообщений: 2804
Я извиняюсь, с MS SQL знаком поверхностно, а вот на IB репликацию писать приходилось. С такими проблемами не сталкивался потому что остатки изменялись в триггере (точнее в хранимой процедуре, вызываемой из триггера)
Что-то типа Update Ost Set Kol = Kol + new.Kol . А в MS SQL при репликации триггеры, я так понимаю, не работают? Или можно этим управлять?

Удачи.
16 июн 04, 15:48    [745715]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
Вербняков Александр
Member

Откуда: г.Таганрог, Ростовская область
Сообщений: 498
Наоборот они противные работаю если им не указать NOT FOR REPLICATION :)
16 июн 04, 15:54    [745746]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
Лентяй
Member

Откуда:
Сообщений: 2804

Наоборот они противные работаю если им не указать NOT FOR REPLICATION :)


А, Тогда лагче ...
16 июн 04, 16:14    [745841]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Пока автор не расскажет о структуре хранения данных вместе с триггерами и используемыми процедурами (хотя бы вкратце, полный скрипт может и не надо выкладывать), обсуждение выглядит бессмысленным. Применение резолверов, равно как и выбор метода репликации, неотрывно связан с представлением данных.
16 июн 04, 16:20    [745871]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
Лентяй
Member

Откуда:
Сообщений: 2804

Пока автор не расскажет о структуре хранения данных вместе с триггерами и используемыми процедурами (хотя бы вкратце, полный скрипт может и не надо выкладывать), обсуждение выглядит бессмысленным. Применение резолверов, равно как и выбор метода репликации, неотрывно связан с представлением данных.

Поддерживаю.
Процитирую приятеля:
Произвольная структура бесконфликтно не реплицируется, мысель о
репликации должна быть в неё заложена.
Удачи.
16 июн 04, 16:48    [745992]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
Вербняков Александр
Member

Откуда: г.Таганрог, Ростовская область
Сообщений: 498
Согласен с вами обоими :)
16 июн 04, 16:58    [746036]     Ответить | Цитировать Сообщить модератору
 Re: merge, tran и т.п. А как у Вас?  [new]
lesha
Member

Откуда:
Сообщений: 157
Доброго дня.

я так понимаю по структуре филиал не имеет своего склада...

у нас конечно проще..филиалы имеют свои склады, и с них торгуют...merge работает просто замечательно... :-)
6 авг 04, 16:53    [865571]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить