Александр Тарасенко,

Размеры - это, в общем-то, копейки.

1. Где живёт Apply - на "веб" или на сервере базы-источника?
2. _Manual_ full refresh - чего б его не сделать (через export/load), если надо (требует определённой аккуратности и или остановки приложений, или по хорошему поднятия снапшота БД на некоторый заданный момент времени где-нибудь рядом).

Но я бы при имеющейся картине стал бы разбираться, чего оно так медленно идёт.

PS Там есть ещё параметр, заставляющий использовать исходную разбивку по транзакциям, не объединяя их на target системе в блоки. Этот параметр может сильно замедлять SQL репликацию на слабых каналах (если Apply живёт на источнике) и на слабом target сервере, но, вероятно, не в этом случае.

Александр Тарасенко,

2.
Не совсем "просто".
Перегонять их нужно ровно между двумя страницами диалога Replication Center при старте Manual full refresh.
1. В диалоге RC стартуем Manual Full refresh.
2. В некоторый момент попадаем в часть диалога "сохраните такие-то таблицы из источника". Делаем export.
3. Следующая страница диалога - "загрузите таблицы в приёмник". Загружаем (или import'ом, или load'ом, соблюдая необходимые правила осторожности - NONRECOVERABLE или с COPY YES, проверив потом состояние CHECK INTEGRITY PENDING).
4. Идём по диалогу дальше, запуская репликацию.

Стартовав, репликатор начнёт вычитывать изменения с момента старта Manual Full Refresh, но фактически пропустит изменения, уже попавшие в target, и донакатит непопавшие.
В особо хитрых случаях (одновременные сложные изменения разных строк таблицы в одной транзакции) - или export делать на Repeatable Read, или рядом с основной БД роллфорвардную копию, стопнуть её на момент t1 (появление диалога "сохраните таблицы") + небольшая дельта.

Механика всего этого станет совершенно понятна, если попросить Replication Center генерить на все действия скрипты, а не просто выполнять их. Плюс редбуку по репликации почитать.


PS Но надо иразбираться в причине.