sennСпасибо за ответы. Про инкремент понятно думали, но нет явного признака для инкремента.
Считайте контрольную сумму полей таблицы. Конечно, желательно что-то типа MD5, но это очень уж ресурсоёмко, по моему опыту достаточно что-то типа BINARY_CHECKSUM.
Табличку "предыдущий слепок" (id, CHECKSUM) храните на том же сервере, с которого производилась выборка.
Она обычно получается небольшая, в смысле общего объема.
Соответственно, изменившиеся данные ищутся по сочетанию id + контрольная сумма, и на сервер передаются строки с теми id, которые не найдены при поиске по сочетанию (id + контрольная сумма) [это либо новые, либо изменившиеся] + отдельно перечень не найденных id при сопоставлении "предыдущего слепок" и копируемых данных [это удаленные id]. Второе, впрочем, не обязательно, если в хранилище хранятся все данные, с накоплением.
Если вы опасаетесь, что BINARY_CHECKSUM выдаст вам коллизию, а более ресурсоёмкий MD5 использовать не хотите, то совет - храните 2 BINARY_CHECKSUM, рассчитанные по двум, частично пересекающимся подмножествам полей одной записи. Вероятность коллизии снизится на величину, пропорциональную произведению длин контрольных сумм. Ну, точнее, снизится вплоть до, и т.д. Не будем впадать в маразм в этом вопросе :-)
Прелесть всего этого дела, что контрольную сумму можно (и нужно) либо хранить на источнике, как вычисляемое поле таблицы, либо же рассчитывать прямо перед импортом, в табличку "текущий слепок", т.е. не гонять всё это дело туда-сюда.

Всё это работает очень быстро, даже на выборках 100+ млн., т.к. сами по себе таблички с ключами и контрольными суммами - получаются компактными. Относительно.
Гм... надеюсь, что ключи у вас - что-то типа bigint, конечно...

Как вариант - завести поле timestamp во всех импортированных таблицах, и, соответственно, передавать все записи, timestamp которых больше, чем текущий timestamp базы на момент прошлого импорта.
Правда тут проблема с удаленными записями, их id тоже нужно как то определять (например - складывать триггером в соотв. табличку), и передавать на приемник для удаления соотв. записей. Если, конечно, вы не используете хранилище с накоплением [всякого мусора].

Впрочем, это всё для MSSQL, для Оракула могут еще способы найтись.

senniii2,

спасибо, но это все не про нас((... Способов реализаций инкрементального импорта много, но все они подразумевают (в нашем случае) вмешательство в БД-исходник (как я это поимаю).

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

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

Нужно не менять модель восстановления, а сокращать количество протоколируемых данных.

https://docs.microsoft.com/ru-ru/sql/relational-databases/import-export/prerequisites-for-minimal-logging-in-bulk-import
Вот. И далее по теме.