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

Откуда:
Сообщений: 245
Народ, делал кто выкладки - принципиально чепм эти вещи отличаются. Табличка какая бы - что может это и не может то. Буквально в паре абзацев. А то анализировать бравые статьи как гугу настраивает CT, не найдя толком ЗАЧЕМ, не хочется. Вариант только - более легковесный движок для несерверных едишенов + возможность выгружать в оффлайн данные репликации и переносить внешними носителями. А.. Ну еще если стандартная репликация не позволяет какие-нить особенные наногексасекунды изменений расчитывать.
18 авг 09, 17:32    [7553074]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Crimean
Member

Откуда:
Сообщений: 13148
репликация (а их несколько, да еще и с опциями) - готовое решение, которое дает копии базы, более или менее операбельные
sf - набор для разработчика строить чо-то типа репликации, но пока еще не готовое решение
ct - просто синтаксическая конструкция t-sql, применять можно и в целях репликации и в других целях
18 авг 09, 19:35    [7553581]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Гм... Я достаточно неплохо понимаю, чем они отличаются ТЕХНИЧЕСКИ. Проясню суть вопроса, признаю, что он может быть неточен для полного понимания:

Чем принципиально отличаются СЦЕНАРИИ, при которых можно/нельзя, рекомендуется/нерекомендуется использовать тот или иной инструмент.

Вот в это какое принципиальное отличие. Да - именно в сценариях, а не в технологиях - в этом неточность первого вопроса - сорри. С ними все в общем понятно и не в этом суть. Но из темы топика тоже можно было бы это понять ))
В общем, народ, я пока что сделал вывод основной - CT и SF в отличие от стандартной репликации позволят настроить более гибкие схемы типа

- При конфликтах главное изменение расчитывается по условию "Х" (сейчас я вижу, что это зависит от времени проведение слияния с сервером - остальные слившиеся позже будут в проигрыше из-за более высокого приоритета сервера даже при клиентской подписке), а можно, например, настроить так, что реплика будет идти только в случае, если у тебя в такой-то такбличке такой-то селл меет такое-то значение.

- Сама репликация может осуществляться целиком механизмом БД - то есть не придется даже на SQL Express запусть виндовую утилиту синхронизации или юзать RepAPI

- Выгрузить данные в любой внешний формат, тем самым организовав оффлайн-реплику.

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

Есть и еще один неприятный момент у стандартной репликаци, который я успел накопать - она по сути не позволяет гарантированно занести ПОСЛЕДНИЕ сделанные изменения. Механизм стандартно репликации при любом типе подписке, видимо, предполагает высший приоритет у сервера - то есть пока клиент не синхронизируется с базой он не сможет спокойно без конйликта залить свои последние данные, но в том то и дело что с момента последней синхронизации и до момента следующей (при заливке СВОИХ данных) он может попасть в состояние рассинхронизации. И он опять проиграет серверу. То есть гарантировать применение последних синхронизированных (не последних внесенных в саму схему, а именно - последних залитых на сервер физически) можно только косвенно, путем наката из истории конфликтов РУЧКАМИ. Что не есть всегда приемлемо.. Такие вот печальные размышления. Печальные, потому что пока не накопал, как бы стандартную реплику можно настроить на более высокий приоритет клиента, по отношению к серверу, чтобы, допустим, гарантированно залить последние изменения. Может кто обрадует... Прошу подтвердить или опровергнуть....
19 авг 09, 17:28    [7558022]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Совсем туго со свободными спецами-аналитиками? :(
20 авг 09, 13:47    [7561676]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Crimean
Member

Откуда:
Сообщений: 13148
просто трындеть на тупиковую тему времени / желания нет, а для флуда давно своя конфа вроде как
20 авг 09, 15:09    [7562271]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Говорить без аргументов, что тема тупиковая - это как бы просто неуважение к собеседнику, минимум. Пока же путного от тебя лично ничего не прочитал.
20 авг 09, 17:07    [7563161]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
позвольте прояснить, форумчане - я не спрашиваю про какой-то там ключ какой-то там утилиты - это технический момент, не имеющий значения главного - для этого я бы сюда не полез. Меня интересуют конкретные четкие различия в модялх использования технологий. Я полагаю, что гамотный сец, который технологии юзал и не просто для "Я УМЕЮ", а именно разбирался когда и в каких случаях пригодны те или иные технологии - так вот такой спец вполне сможет в паре абзацев на 5-6 строк каждый сформулировать принципы технологий.. Я попытался это сделать - у меня куча задач, и к сожалению нет времени на раскопку именно ЭТИХ деталей. А ответ нужен. Посему, если кому по делу ответить нечего - желательно не встревать с репликами типа последней у Crimean (первая вподне отвечала духу развития топика).
20 авг 09, 17:11    [7563187]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Crimean
репликация (а их несколько, да еще и с опциями) - готовое решение, которое дает копии базы, более или менее операбельные
sf - набор для разработчика строить чо-то типа репликации, но пока еще не готовое решение
ct - просто синтаксическая конструкция t-sql, применять можно и в целях репликации и в других целях

так вроде готовій ответ,как ві и хотели
Если нужно гарантирование решение синхронизауции данных то репликация или мирроринг
Если охота чет савсем свое самописное +есть время на разгребание кучи багов от тех что внутри классов,до того что не учли забыли сами - то вуаля второе решение, рекомендовал бы для минимальных задач, ноникак не для "нормальной" полновестной синхронизации настроное в реальные сроки
Третье - как по мне,все таки лутше второго, но все равно для массовых операций с большой загрузкойяб не делал.
20 авг 09, 17:32    [7563320]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Maxx
так вроде готовій ответ,как ві и хотели


ktv
Гм... Я достаточно неплохо понимаю, чем они отличаются ТЕХНИЧЕСКИ. Проясню суть вопроса, признаю, что он может быть неточен для полного понимания:
20 авг 09, 18:08    [7563597]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10715
Блог
Если где то репликацией назвали синхронизацию или тиражирование данных, то это ещё не значит, что корректно сравнивать эти технологии...
Чтобы понять фундаментальную разницу, рекомендую прочитать начало этой статьи из книги: http://msmvps.com/blogs/gladchenko/archive/2009/01/13/1662288.aspx

По поводу разрешения конфликтов на основе приоритетов или иных правил - попробуйте сформулировать вопрос более конкретно, т.е. что именно у Вас не получилось и как Вы этого пытались достичь? ...не думаю, что Вы не нашли где указать победителя в стандартном резольвере...
20 авг 09, 18:19    [7563670]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Отчего же - нашел вполне - мастер с кучей конфликтов - ручками все решается. Дело тут вот в чем - я не нашел в стандартном резольвере какие-то гибкие условия автомтаического разрешения конфликтов. То есть просто тупо по мастерам - есть серверные и клиентски подписки. Но они не дают атоматически к примеру применять последние слитые данные в стандартном виде. То есть слил первый клиент изменения на сервер, остальные клиенты будут проигрывать ему, даже если их изменения были и сделаны позже и отосланы так же позже - насколько я понял - это от того, чо первое изменение как бы начинает выступать от имени сервера. То же самое будет если я вручную внесу изменение на сервере - ему проиграют все последующие изменения со всех клиентов. Такой вот момент. За ссылку - благодарю - пройдусь.
21 авг 09, 14:51    [7567214]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
поколупался специально с пунктом 3 - ну не надо из етого механизма пытаться делать репликацию,от лукавого ето
-------------------------------------
Jedem Das Seine
21 авг 09, 14:56    [7567249]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Maxx, я не колупался, но меня как-то страшит ваять мегабайты кода )

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

- Если понадобится автоматически без конфликтов вносить последние слитые изменения при наличии рассинхронизации клиентов - покаэтого в стандартной реплике, настроенной тыком по мастерам сделать нельзя - клиентские и серверные подписки не решают эту проблему

- Если стандартная реплика этого сделать не позволяет - то есть там сервер ВСЕГДА будет выигрывать у любого клиента при конфликте - значит остается какой-то ручной режим с использованием тех же SF и СT - ну или как-то уже писать свой код к системным данным стандартной реплики сервера - но залазить пока не треба сюда..
21 авг 09, 15:06    [7567340]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Народ, прошу прощения за тупизм, но задача именно такая и была - не тратить время на раскопку и анализ мегабайт текста, в том числе и статью, вроде данной Алексеем. Ну она реально здоровая ) - просто хочется ответы на мои последние вопросы )
21 авг 09, 15:09    [7567371]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
статья Александра - реально толковая :)
-------------------------------------
Jedem Das Seine
21 авг 09, 15:19    [7567470]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Не спорю, Маxx )

Ответ только она мне дала. Насколько я понял из BOL - придется писать своего арбитра конфликтов и втыкать его в схему репликации.. я прав?
21 авг 09, 15:45    [7567711]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
честно,у вас чет скорее всего со схемой данных, была мерж с 20 филиалами , никогда не надо было своего арбитра честно... или я таки вашей задачи не догоняю :(
-------------------------------------
Jedem Das Seine
21 авг 09, 15:47    [7567736]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Проясню. Народ бегате по стране с буками и вбивает через клиента-дексктоп данные в локальную базу-подписчик на буке. Приезжает в родную контору и начинае заливать данные на сервер. То есть репликация (не буду спорить тут за чистоту терминов) в данном случае - двунаправленная. Так вот. Ситуация:
1. Приехал один и слил данные на сервер.
2. Приехал второй - бук у него не синхронизирован - он через RepAPI начинает переливать данные на сервер - и получает конфликт - и проигрывает его, потому что, по всей видимости, по стандартной репликации - сервер всегда прав.
3. Приезжает следующий - та же картина..
..
..
N Админ садится на машину и ручками выбирает не данные шага два, а данные шага N+1, поскольку они как бы более новые.

Во там мне пока что все видится, если действовать тупо на мастерах - не увидел я там что-то кроме интерактивного разрешения конфликта настройки автоматической, кроме серверного тип подписок - но и там 99 клиентских против 100 по умолчанию серверных как бы не катит..
ВРоде как BOL говорит - делайте своего арбитра и изменяйте статьи, сувая своего арбитра. Вот, видать, в этом арбитре - который содержит guid пользовательской строки конфликта + данные из системных таблиц публикатора - придется брать все конфликты данной строки, возвращать нужный кортеж да ещ еи указыывать, что выиграл клиент. По BOL так все выглядит.
21 авг 09, 16:00    [7567832]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
не злитесь только , но у вас таки аржитекруа БД скорее всего неправильная в таком случае :(
На центральной вся БД и все справочники (материалы,цены......)
На клиенте ,справочники (которые не радактируються) и база продаж,там счета ,накладные и все такое
При описаной выше схеме ,конфликты не должны возникать.
-------------------------------------
Jedem Das Seine
21 авг 09, 16:16    [7567936]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10715
Блог
ktv
Не спорю, Маxx )

Ответ только она мне дала. Насколько я понял из BOL - придется писать своего арбитра конфликтов и втыкать его в схему репликации.. я прав?


Если штатные арбитры не подходят, нужно писать своего. Или, как вариант, попытаться так изменить схему данных, чтобы исключить возможность возникновения подобных конфликтов.
21 авг 09, 16:31    [7568050]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
О.. благодарю за подтверждение.
21 авг 09, 16:46    [7568163]     Ответить | Цитировать Сообщить модератору
 Re: Стандартная репликация vs Sync Framework vs Change Tracking  [new]
ktv
Member

Откуда:
Сообщений: 245
Maxx, что тут злиться - у каждого свои схемы под конкретные задачи. Вот у меня - центральный сервер, на котором обрабатываются данные собранные с проектов по стране. Ну вот БИЗНЕС ТАК УСТРОЕН. Сеть "Магнит" так работает - со всей РФ данные сливаются в центральный узел. Просто у меня ГИПОТЕТИЧЕСКИ возможны конфликты. Я понимаю, что их при НОРМАЛЬНОМ бизнесе быть не должно. Но нормальности у нас мало, почему, мне ситуацию надо учесть, вот и все. Судя по всему - вопрос исчерпан. Благодарю за участие в дискуссии.
21 авг 09, 16:50    [7568192]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить