ora_qu,
ora_quв таблицу в цикле insert ста тысяч простых строк по одной. Процесс занимает около минуты, на втором сервере таблица наполняется через 2 минуты с лишнем. На 1 млн. строк соотношение 10 мин. к 23 мин., т.е. похожее.
После каждого insert-а идет commit или это все одна большая транзакция?

Посмотри лаг экстракта на экстракции данных - https://docs.oracle.com/goldengate/c1221/gg-winux/GWURF/lag-extract.htm#GWURF156
И скорость stats e*, reportrate sec

В целом, путь репликации длинен и тернист, online, пока, не предвидится.
Примерная схема:

user's commit -> redo log -> extract -> local trail files -> local pump -> network -> remote trail files -> remote replicat -> sql

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

На мой взгляд, большинство проблем проявляются на репликате, чаще всего встречаются:
Отсутствие uniq индексов, PK.
Множество лишних индексов, на обновление которых может уходить до почти все времени.
Множество fk.
Множество мелких транзакций.
Слишком большие транзакции(проблемы с памятью и т.п.).
Однопоточность репликата(один воркер - один запрос изменения).
Блокировки, конкурентность и т.п.

Однотипные, множественные изменения можно пробовать группировать с batchsql.
Однопоточность можно нивелировать через распараллеливание репликата(если ТЗ позволяет).

Начни с поиска lag-а.
Посмотри на чем висит репликат, в бд, что делает, какие вейты.