Репликация работет чере почту. При малом объеме (мелкие транзакции) все работает прекрасно. При выполнении в удаленной, да и в центральной БД, например хранимой процедуры, которая добавляет достаточно много данных и естественно транзакция завершается после выполнения процедуры после 30 посылки получаю:
I. 10/20 09:09:58. 1: -m
I. 10/20 09:09:58. 2: 50m
I. 10/20 09:09:58. 3: -v
I. 10/20 09:09:58. 4: -q
I. 10/20 09:09:58. 5: -c
I. 10/20 09:09:58. 6: ***************************************************************************************************
I. 10/20 09:09:58. SQL Remote Message Agent Version 9.0.2.3198
I. 10/20 09:09:58.
I. 10/20 09:09:58. Copyright © 1989-2004 Sybase, Inc.
Portions Copyright © 2002-2004, iAnywhere Solutions, Inc.
I. 10/20 09:09:58. All rights reserved. All unpublished rights reserved.
I. 10/20 09:09:58.
I. 10/20 09:09:58. This software contains confidential and trade secret information of
I. 10/20 09:09:58. iAnywhere Solutions, Inc.
Use, duplication or disclosure of the software and documentation
I. 10/20 09:09:58. by the U.S. Government is subject to restrictions set forth in a license
I. 10/20 09:09:58. agreement between the Government and iAnywhere Solutions, Inc. or
I. 10/20 09:09:58. other written agreement specifying the Government's rights to use the
I. 10/20 09:09:58. software and any applicable FAR provisions, for example, FAR 52.227-19.
I. 10/20 09:09:58.
I. 10/20 09:09:58. iAnywhere Solutions, Inc., One Sybase Drive, Dublin, CA 94568, USA
I. 10/20 09:09:58.
I. 10/20 09:09:59. Scanning logs starting at offset 0151369261
I. 10/20 09:09:59. Processing transaction logs from directory "c:\DB_SYBASE\MAIN_SPB\"
I. 10/20 09:09:59. Processing transactions from active transaction log
I. 10/20 09:10:07. Sending message to "Filial_29A" (5-0152290393-0152290393-0)
I. 10/20 09:10:07. Resend requests are being queued
I. 10/20 09:10:08. Sending message to "Filial_85A" (0-0152291182-0152291182-0)
I. 10/20 09:10:08. Hovering at end of active log
I. 10/20 09:12:19. Scanning logs starting at offset 0151369261
I. 10/20 09:12:19. Processing transaction logs from directory "c:\DB_SYBASE\MAIN_SPB\"
I. 10/20 09:12:19. Processing transactions from active transaction log
I. 10/20 09:12:27. Sending message to "Filial_29A" (5-0152290393-0152290393-0)
I. 10/20 09:12:27. Sending message to "Filial_29A" (5-0152290393-0152290393-1)
I. 10/20 09:12:27. Sending message to "Filial_29A" (5-0152290393-0152290393-2)
I. 10/20 09:12:27. Sending message to "Filial_29A" (5-0152290393-0152290393-3)
I. 10/20 09:12:28. Sending message to "Filial_29A" (5-0152290393-0152290393-4)
I. 10/20 09:12:28. Sending message to "Filial_29A" (5-0152290393-0152290393-5)
I. 10/20 09:12:28. Sending message to "Filial_29A" (5-0152290393-0152290393-6)
I. 10/20 09:12:28. Sending message to "Filial_29A" (5-0152290393-0152290393-7)
I. 10/20 09:12:28. Sending message to "Filial_29A" (5-0152290393-0152290393-8)
I. 10/20 09:12:28. Sending message to "Filial_29A" (5-0152290393-0152290393-9)
I. 10/20 09:12:29. Sending message to "Filial_29A" (5-0152290393-0152290393-10)
I. 10/20 09:12:29. Sending message to "Filial_29A" (5-0152290393-0152290393-11)
I. 10/20 09:12:29. Sending message to "Filial_29A" (5-0152290393-0152290393-12)
I. 10/20 09:12:29. Sending message to "Filial_29A" (5-0152290393-0152290393-13)
I. 10/20 09:12:29. Sending message to "Filial_29A" (5-0152290393-0152290393-14)
I. 10/20 09:12:29. Sending message to "Filial_29A" (5-0152290393-0152290393-15)
I. 10/20 09:12:30. Sending message to "Filial_29A" (5-0152290393-0152290393-16)
I. 10/20 09:12:30. Sending message to "Filial_29A" (5-0152290393-0152290393-17)
I. 10/20 09:12:30. Sending message to "Filial_29A" (5-0152290393-0152290393-18)
I. 10/20 09:12:30. Sending message to "Filial_29A" (5-0152290393-0152290393-19)
I. 10/20 09:12:30. Sending message to "Filial_29A" (5-0152290393-0152290393-20)
I. 10/20 09:12:30. Sending message to "Filial_29A" (5-0152290393-0152290393-21)
I. 10/20 09:12:31. Sending message to "Filial_29A" (5-0152290393-0152290393-22)
I. 10/20 09:12:31. Sending message to "Filial_29A" (5-0152290393-0152290393-23)
I. 10/20 09:12:31. Sending message to "Filial_29A" (5-0152290393-0152290393-24)
I. 10/20 09:12:31. Sending message to "Filial_29A" (5-0152290393-0152290393-25)
I. 10/20 09:12:31. Sending message to "Filial_29A" (5-0152290393-0152290393-26)
I. 10/20 09:12:31. Sending message to "Filial_29A" (5-0152290393-0152290393-27)
I. 10/20 09:12:31. Sending message to "Filial_29A" (5-0152290393-0152290393-28)
I. 10/20 09:12:32. Sending message to "Filial_29A" (5-0152290393-0152290393-29)
I. 10/20 09:12:32. Sending message to "Filial_29A" (5-0152290393-0152290393-30)
I. 10/20 09:12:32. Resend requests are being queued
I. 10/20 09:12:33. Hovering at end of active log
I. 10/20 09:14:43. Scanning logs starting at offset 0151369261
I. 10/20 09:14:43. Processing transaction logs from directory "c:\DB_SYBASE\MAIN_SPB\"
I. 10/20 09:14:43. Processing transactions from active transaction log

Почему появляется сообщение
I. 10/20 09:12:32. Resend requests are being queued

и как с этим бороться
Заранее спасибо

Рыжий Котвы наверное передаете большие объемы, поля типа long binary.
например, в одно поле запихнули 1 мегабайт.
По почте пришло 900 кб, разбитое на куски, причем первый кусок не прошел, или задержался где-то. Удаленный филиал, подумал-подумал и послал заново resend request, а они опять пролезают черти как, и вот так по кругу. Особенно весело, когда удаленная сторона высылает подряд скажем 10 раз resend request в то время как консолидированная база уже начала высылать пакеты :)

Нет никаких long binary. Совершенно простая БД. Но даже выполненная команда в центральной БД Update одного поля в 36 0000 записях приводит к описанному эффекту

Sergey Orlov Рыжий Кот vinogradov Рыжий Котвы наверное передаете большие объемы, поля типа long binary.
например, в одно поле запихнули 1 мегабайт.
По почте пришло 900 кб, разбитое на куски, причем первый кусок не прошел, или задержался где-то. Удаленный филиал, подумал-подумал и послал заново resend request, а они опять пролезают черти как, и вот так по кругу. Особенно весело, когда удаленная сторона высылает подряд скажем 10 раз resend request в то время как консолидированная база уже начала высылать пакеты :)

Нет никаких long binary. Совершенно простая БД. Но даже выполненная команда в центральной БД Update одного поля в 36 0000 записях приводит к описанному эффекту

тогда все ясно...
делайте короткие транзакции, если это возможно по логике.
сделайте цикл и после каждых, например, 100 записей (update top 100...) вставляйте commit. Тогда dbremote будет, как и раньше, высылать короткие транзакции.
Можно еще изменить/увеличить размер посылки, ключик -l, у меня не справлялся почтовый сервак с отдачей/приемом посылаемых сервером SQL сообщений, по умолчанию кажется 50кб, сейчас установлен в 1М


Всем спасибо за рекомендации. Справился.
По поводу параметра -L. в 2001 году в удаленной точке я ставил больший размер посылки, но не поставил этот параметр у агента репликации в центральной БД. В Центре шли ошибки о том что сообщение разрушено.
Обнаружено это было через 20 дней. После удаления параметра -L в удаленном узле система сама справилась и все синхронизировала.
Потом, после чтения докуметации стало ясно, что блоки должны быть одинаковые.
Вопрос:
А можно в центре поставить параметр -L 1M, а в удаленных точках постепенно менять (филиалов много). В документации
–l length Maximum message length
Можно сделать вывод, что это максимальная длина и следовательно,
если в центре поставить -L 1M, то при приходе сообщений в 50кб из удаленной точки агент репликации центральной БД должен такие сообщения принять.
Или я не прав, необходимо везде иметь одинаковое значение параметра -L
Заранее спасибо