dismay2) OGG Studio (fmw_12.2.1.4.0_oggstudio.jar)
3) GG Data Integrator (fmw_12.2.1.4.0_odi.jar)
3) RCU (Запускаю из Data Integrator-> bin -> rcu_internal.bat)
Не нужно для достижения озвученной цели.

Со стороны GG требуется:
1) manager; Configuring Manager and Network Communications
2) extract;
3) trail;
4) replicat;

2-4) Configuring Online Change Synchronization

Со стороны БД нужен пользователь для extract и replicat. Может быть один и тот же. Права указаны тут: Granting the Appropriate User Privileges

Пошаговая инструкция, например: Using Oracle GoldenGate with Amazon RDS (RDS вызовы нужно конвертировать).
На Windows может быть своя специфика с сервисами.

andrey_anonymous,

andrey_anonymousExtract среди различных режимов взаимодействия с БД-источником может быть сконфигурирован в режиме ALO (Archive Log mode Only), вообще не требующем подключения к БД-источнику.
Я бы добавил downstream, т.к. там можно использовать integrated extract. ALO не поддерживает integrated: https://docs.oracle.com/en/middleware/goldengate/core/19.1/oracle-db/configuring-classic-capture-archived-log-only-mode.html
А также parallel replicat, который, как правило, оказывается самым быстрым: https://docs.oracle.com/en/middleware/goldengate/core/19.1/admin/configuring-online-change-synchronization.html#GUID-585D553E-6DFC-41C0-A50D-93229AFECEDD

В целом, моя рекомендуемая конфигурация OGG, это всегда hub. hub в кластере (XAG) или primary/standby. Если hub нельзя по каким-то причинам, то ставить extract/replicat на сервера с целевыми БД.

Основная причина, по которой я ставлю их с целевыми, это производительность . Это особенно критично в bi-directional(BDR) и multi-master конфигурациях, где нужно минимизировать задержки.
Вторая причина, это сеть, если приемник/источник распределены. Pump имеет больше сетевых опций и справляется с различными network glitch гораздо лучше.
Ну и для hub pump не нужен, что тоже избавляет от некоторых проблем, например, не требуется наличие VIP на той стороне, куда передает pump. on-premise это не проблема, но вот в облаках с VIP есть некоторые сложности.

Основная причина, по которой я НЕ ставлю их с целевыми, это производительность . Memory, CPU, I/O, network. Сейчас стало все больше OGG для BigData для репликации во всякие Kafka, что также приводит к новым проблемам.

Из интересных нововведений в последних версиях, это в первую очередь: Cross Endian Support for Remote Integrated Extract . К сожалению, не все еще на Linux, что встречаются и AIX, и Solaris SPARC. Ранее для таких конфигураций приходилось ставить GoldenGate того же endian format. Сейчас это не требуется.

Из новых проектов, все больше проектов по миграции с Oracle на PostgreSQL (импортозамещение). Там есть определенные проблемы с типами данных, что ожидаемо.