Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
После добавления подписчика срабатывает первый раз Merge Agent и за один раз не успевает синхронизовать его с паблишером. В хистори пишет:

Initializing

Connecting to Publisher
Connecting to Subscriber
Applied script ...
...
No data needed to be merged
Downloaded 100 data changes
...
(много раз по 100 data changes)
The process is running and is waiting for a response from one of the backend connections. The process could not deliver insert(s) at the Subscriber

Сообщение об ошибке - "The merge process timed out
while executing a query. Reconfigure the QueryTimeout
parameter and retry the operation."


И останавливается. Ладно, увеличиваю вышеупомянутый QueryTimeout и запускаю агента снова.
Он больше изменений не скачивает :-(((((( "No data needed to be merged" - и все!
Почему он считает, что данные синхронизованы???? Как его переубедить?

Причем если сейчас что-то менять в данных, то изменения честно приходят. Все, кроме тех, что не успели влезть в первую синхронизацию :-(
9 дек 03, 11:39    [452584]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Cooper
Member

Откуда: Фром Москоу
Сообщений: 3939
А если вместо 100 указать бОльшее количество?

===============================
Qper
9 дек 03, 11:50    [452612]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Да оно-то можно... Меня интересует не столько вопрос "как бы сделать так, чтобы за первую синхронизацию все до конца приходило", сколько вопрос "почему merge agent потом не видит тех изменений, которые он не успел докачать".

Плохо то, что никакой ошибки по сути нет. После перезапуска агента все выглядит чисто и красиво. Вот только данных нет.
9 дек 03, 12:10    [452669]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
злой шаман
Member

Откуда: Питер
Сообщений: 1253
А подписка push или pull?
9 дек 03, 12:13    [452681]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
lvv
Member

Откуда:
Сообщений: 226
а точно данных нет? Или это предположение такое после сообщения об ошибке?
9 дек 03, 12:13    [452683]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
злой шаман
Member

Откуда: Питер
Сообщений: 1253
И везде ли стоит 818 апдэйт? Он несколько багов фиксит.
9 дек 03, 12:15    [452686]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
lvv
Member

Откуда:
Сообщений: 226
а что такое 818 апдейт?
9 дек 03, 12:29    [452729]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Crip
Member

Откуда:
Сообщений: 2490
sp3a
9 дек 03, 12:39    [452764]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Cooper
Member

Откуда: Фром Москоу
Сообщений: 3939
автор
Ладно, увеличиваю вышеупомянутый QueryTimeout и запускаю агента снова

Какого агента запускаете снова? Snapshot?

Я собственно не знаю, но может быть вот этот параметр имеет значение? тут

===============================
Qper
9 дек 03, 12:40    [452766]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
А подписка push или pull?
push

а точно данных нет? Или это предположение такое после сообщения об ошибке?
Что "предположение"? Данные реально не пришли (проверяется select'ом на одном сервере и на другом), в хистори merge agent'а также только записи "No data needed to be merged".

На паблишере (дистрибьютор локальный) и подписчике стоит sp3 просто. Билд 8.00.760

В статье INF: List of Bugs Fixed by SQL Server 2000 Service Packs пишется, что sp3a отличается от sp3 на ровно три FIX'а. Среди них ничего про репликацию нет.

Какого агента запускаете снова? Snapshot?
Конечно, нет. Merge Agent'а, поскольку до конца не отрабатывает именно он. Снапшот создается совершенно нормально.

Насчет этого конкретного параметра посмотрю, но повторю: мне бы хотелось знать, не как заставить Merge Agent'а отработать сразу и целиком. Когда придут изменения, в первый сеанс или позже - это неважно. Меня беспокоит то, что он их просто теряет. Больше не пытается скачивать эти данные.
9 дек 03, 13:07    [452853]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
Используете динамические фильтры?
Иначе бы просто снапшот применился.
9 дек 03, 13:28    [452925]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
статические
9 дек 03, 13:32    [452939]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
т.е. снапшот нормально применился, а потом происходит много модификаций на паблишере, которые не передаются подписчику?
9 дек 03, 13:34    [452952]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10752
Блог
Сочувствую автору вопроса, сам постоянно на такое напарываюсь... :( Это похоже на баг. Вот только вчера из-за расхождений пришлось ресинхронизировать очередного подписчика. Нельзя давать агенту отваливаться по таймауту на запрос...

2 GreenSunrise - может быть все-таки чаще синхронизироваться, похоже трафик у вас постоянно растет и изменений приходится передавать всё больше и больше...
9 дек 03, 14:09    [453079]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Ха... При создании публикации был указан параметр @dynamic_filters = N'true', а реально фильтры заданы статические. Будет задействован механизм применения именно динамических фильтров?
9 дек 03, 14:10    [453087]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Изменений немного. В тестовой среде вообще воссоздана ситуация такая - снапшот на паблишере создан, после чего изменений не было совсем. Подключаем подписчика. Merge Agent в первый раз скачивает часть изменений и подыхает (насколько я понимаю, скачивает именно изменения вместо снапшота, потому что указана опция "dynamic filters"). Во все последующие разы он скачивает только те изменения, которые происходили позже. Те, которые соответствуют снапшоту (не знаю, как правильно выразиться) уже не приходят.

Ладно, решение еще поищу... Но вот слабая детектируемость этой ситуации меня напрягает. Слишком легко не заметить проблему. Пока юзеры носом не ткнут - вот тут у меня 100000 записей, а тут 10 :-/
9 дек 03, 14:16    [453111]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
С изменением параметра @dynamic_filters на N'false' (реально заданы все равно только статические фильтры) жизнь стала легче. Merge Agent не срубается на первом запуске (он копирует все данные через bulk copy) и потом в связи с малым объемом накапливающихся изменений никаких проблем не возникает.

Скажем так, для определенного набора условий и данных задача успешно решена.

Остался смутно грызущий вопрос, почему же при останове агента по таймауту и последующем запуске не происходит докачки изменений...

Но в любом случае всем участникам большое спасибо :-)
9 дек 03, 14:57    [453259]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
2 GreenSunrise

Знакомая ситуация :) проблема в динамических фильтрах :)

Саша Гладченко недавно с ними разбирался, вот здесь его статья на эту тему.
9 дек 03, 15:19    [453345]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Угумс...

Жизнь практически удалась, остался еще только один вопрос ;-)) У bulk copy есть такая опция - FIRE_TRIGGERS. При работе Merge Agent'а со статическими фильтрами используется как раз bulk copy. Но среди параметров агента нет возможности установить хинты для bulk copy. Мож кто обходной путь знает?
9 дек 03, 16:28    [453541]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
При работе Merge Agent'а со статическими фильтрами используется как раз bulk copy.

Bulk copy используется для заливки снапшота, а далее если в триггерах не стоит not for replication, то они и будут себе спокойно срабатывать.
Беспокоится же о снапшоте тоже по моему нет необходимости, если данные находятся в целостном состоянии на паблишере, то и на подписчик прийдут в целостном состоянии. :)
9 дек 03, 17:02    [453621]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
злой шаман
Member

Откуда: Питер
Сообщений: 1253
818 апдэйт это не SP3a, это SQL Server 2000 (32-bit) Security Patch MS03-031.

Лично контролировал, как он пофиксил один из багов репликации, который чуть не заставил меня поседеть.
9 дек 03, 17:11    [453644]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Извините, что-то я сегодня мутно выражаюсь... Моя оставшаяся проблема именно в том, что меня интересует срабатывание триггеров в момент применения снапшота. На последующие изменения триггера отлично срабатывают, это без сомнения :-)

Упрощенно говоря, есть логгинг, построенный на триггерах. При добавлении подписчика в его лог не попадают изменения, пришедшие со снапшотом. Вот и хочется как-то пнуть merge agent, чтобы он пнул используемый внутри себя bulk copy, установив опцию FIRE_TRIGGERS.
9 дек 03, 17:14    [453651]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
При добавлении подписчика в его лог не попадают изменения, пришедшие со снапшотом.

А какие изменения могут прийти со снапшотом?
Все что было на паблишере то и придет, ну ессно за исключением того что ограничивается фильтром.
9 дек 03, 17:18    [453665]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
можно запросом стянуть данные с паблишера на момент применения снапшота.
можно в джоб синхронизации вставить шаги с запуском процедур по вычислению разницы. :)
9 дек 03, 17:22    [453672]     Ответить | Цитировать Сообщить модератору
 Re: Merge replication и большой объем данных  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
2злой шаман: не очень представляю, как security patch может мне помочь в описываемой ситуации, но ради всеобщего спокойствия завтра его накачу.

2Genady: попробую еще раз победить свое косноязычие :-) Итак.

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

Рассмотрим ситуацию на подписчике. Он только что добавлен к паблишеру. Какие данные к нему приходят?
1) на него накатывается снапшот
2) те изменения, которые были на паблишере с момента последнего снапшота.

В логе подписчика имеем только п.2 (потому что триггера на первом не срабатывают). А хочется и первый тоже :-/
9 дек 03, 17:27    [453687]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить