Ответ

Для передачи больших объемов данных между SQL-серверами применяются несколько стратегий, включая bulk insert, ETL-процессы (Extract-Transform-Load), репликацию, а также механизмы бэкап/восстановления, db-link`ов и встроенных средств экспорта-импорта.

Оптимально использовать батчевые (пакетные) механизмы передачи. Пример на SQL Server — это BULK INSERT для загрузки больших файлов, или SSIS/Integration Services для сложных сценариев ETL. В более переносимых вариантах используются скрипты с логикой LIMIT/OFFSET и фиксацией позиции передачи. Для надежности часто применяют:

Передачу данных порциями с контрольными суммами,
Временные staging-таблицы с последующим контролем целостности (check constraints, hash'и),
Журналирование этапов передачи.

Пример

-- Передача данных порциями между базами (PostgreSQL)
INSERT INTO target_db.public.data_table (col1, col2)
SELECT col1, col2 FROM source_db.public.data_table
WHERE transferred = FALSE
LIMIT 10000;

Вопрос с подвохом

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

Ответ: Репликация поддерживает синхронизацию актуальных изменений и работает эффективно для "живых" данных. Для миграции исторических архивов репликация может быть недостаточно быстрой и гибкой, так как не поддерживает кастомную трансформацию и не решает проблему однократной массовой передачи — здесь чаще используют ETL.

Примеры реальных ошибок

История

Компания интегрировала несколько региональных баз в единую хранилище. При массовом импорте без батчей система "зависала" из-за нехватки оперативной памяти, приводя к partial commit и полуручному восстановлению состояния. Исправлено переходом на пакетную выгрузку с логированием прогресса через staging-таблицы.

История

Из-за некорректного контроля контрольных сумм при передаче больших файлов с помощью BULK INSERT часть информации была испорчена, однако этот факт обнаружили спустя несколько недель. Решением стал пересчет контрольных сумм до и после каждого батча с автоматическим повтором при несоответствии.

История

В попытке миграции 100+ млн строк через стандартный экспорт-импорт один разработчик не учел лок-менеджмент: блокировка таблиц на целевом сервере привела к простой бизнес-операций на несколько часов. Вывод — для таких задач использовать только ночные окна и поэтапное копирование с временной переиндексацией.