Репликация идет по check-point'ам, которые в логе помечаются, когда все изменения в базе commit и все грязные страницы очищены....
Вот например сейчас мы знаем, что у нас отправлено все вплоть до чекпоинта А.
Начинаем формировать сообщение от этого чекпоинта до следующего ближайшего чекпоинта. Сообщение пишется на фтп в файл с именем ".RemoteUserId" Если все прошло успешно и все данные вплоть до ближайшего чекпоинта ушли - этот файл будет переименнован в "RemoteUserId.N" Где N - очередной номер сообщения. Если связь была оборвана посередине передачи сообщения - оно будет послано заново, от чекпоинта A. Это общее правило.

А вот теперь мы подходим к очень большим сообщениям: Если два чекпоинта находятся очень далеко друг от друга, либо между ними находится BLOB, это ведет к тому, что одно сообщение в которое по идее должны попасть все изменения превысит максимально разрешенный размер. Значит dbremote будет резать это сообщение на несколько файлов. Которые все будут пересланы как отдельные сообщения, но с пометкой что мол это "сообщение является частью одного длинного". В логе dbremote это будет видно упоминается что посылается сообщение "N-AAAAAA-BBBBBBB-XX" здесь AAAA - стартовый чекпоинт, BBBB - конечный чекпоинт, XX - номер сегмента в сообщении. (N - номер вторичной посылки).
Предположим что был обрыв связи во время посылки сообещения с XX=10. При следующем старте dbremote он должен будет увидеть что последний подтвержденный отправленый checkpoint по прежнему AAAAAA и по идее, должен заново сформировать все сегменты сообщения "AAAAAA-BBBBBBB" и отправить их заново (с увеличеным N, но насчет последнего не уверен).

Получатель должен увидеть все сегменты одного длинного сообщения и попытаться наложить их. Если получены не все сегменты - он переспросит у получателя о повторной пересылке начиная с AAAAAA. Вот тогда N точно будет увеличен....

вот.... надеюсь я никого не потерял по пути? :) В общем, такова теория.

У меня таких проблем никогда не было. Просто в нашей фирме репликация идет раз в сутки и в основном по направлению филалы->главный офис. А консолидированная база и ftp-сервер находятся на расстоянии пары метров, в одной локальной сети :) А в филиалы уходит максимум одно-два сообщения в сутки. Поэтому я не очень хорошо представляю масштаб ваших проблем. Ну раз вопрос возникает, то наверное проблемы есть :)

Можно сделать так: создаем на локальном диске полную копию ФТПшной структуры каталогов. И при большом объеме входящих сообщений делаем ручное перемещение файлов с ФТП в эти локальные каталоги. Тогда получение большого количества сообщений будет идти немножко веселее.
Есть правда несколько сложностей с этим:
1) Если в нашей базе зарегестрированы FTP-юзера и нету ни одного FILE-юзера - dbremote вообще не будет проверять локальные каталоги. Это можно вылечить создав хотя бы одного remote юзера с репликацией через файлы. Этого фиктивного юзера можно никуда не подписывать или подписать на что-нибудь, но не стартовать подписку.
2) Если remote юзер зарегестрирован как FTP юзер, dbremote будет принимать сообщения от него через любой входящий протокол - FTP/FILE/etc. Но неважно откуда прийдет сообщение, ответ этому юзеру будет послан через FTP всегда.

Думаю что таким образом можно слегка облегчить нагрузку на сеть, но только на базах которые должны принимать большое количество сообщений. И делать копирование с FTP на локальный хард-драйв делать тоже должен достаточно опытный человек. Я еще могу представить такую схему на консолидированной базе, но на удаленных базах это уже не очень реально. В первую очередь из-за отсутствия там опытных администраторов.

Ну я бы сказал что ВОТ ЭТО УЖЕ сложная схема :)
Может проще будет сократить частоту сеансов репликации, чтобы не скапливалось такое большое количество сообщений? Пусть они (сообщения) будут толще, но их будет меньше. Проблема то как я понимаю именно в количестве сообщений? Подуймайте, а действительно ли вам надо пересылать данные так часто?

Рыжий КотПроблема в том, что введенные данные сливаются в один "веб-портал", в который постоянно входят клиенты. Клиенту также отсылается отчет по электронной почте. Если делать репликацию редко, то будут вопросы: как же так у меня тут 300, а у вас 200 (еще пока) :). Кроме того, офисы и клиенты в разных часовых поясах...
У меня примерно так же было... А сейчас...
При нужде печатается отчет построеный на основе select Time_Received from SYS.SYSREMOTEUSER.
А всем пользователям выдано утверждение: "Цифры в консолидированой базе даются по состоянию на вчерашний вечер. Если вы видите более новые данные по каком-то филиалу - это неожиданный бонус, но не более того." И все. Вот если какой-то филиал отстал более чем на два дня - тогда начинаем тревогу поднимать. Некоторые сидят на диалапе, так что задержки вполне легальны.
С технической точки зрения, я стараюсь делать сеансы репликации не реже чем раз в час. Но бухгалтерия знает: обновления идут раз в сутки и не чирикать!

Поначалу тоже весело было - бухгалтер подключется через VNC к филиальскому компьютеру, исправляет там платежи какие-то. А потом бежит к большому шефу: "Я только что исправила там цифры, а офисные отчеты не изменились! Давайте накажем админа, он цифры обратно поменял!"