Oracle GoldenGate supports two types of capture:

Classic Capture
Integrated Capture

Classic capture is a recent name for the original GoldenGate capture mechanism which reads
data directly from the online redo logs and/or archived redo logs where possible. Additional
data may be fetched from the database file where necessary.

Integrated capture was introduced in Oracle GoldenGate 11.2.1. It was initially available for
Oracle 11.2.0.3 with the 11.2.0.3 Database specific bundle patch for Integrated Extract 11.2.x
(MOS Note 1411356.1)

Integrated capture uses a log mining server on the source system or in a downstream Oracle
database, similar to a Data Guard logical standby or Oracle Streams.

Where possible, data is captured from the redo log. However, for some data types the redo data
is incomplete and it is necessary to fetch additional data from the database. Where additional
data is fetched as part of a separate transaction, there is a possibility of inconsistency

Virtual Columns

Tables with virtual columns are supported. Data is not captured from or applied to virtual
columns

Changes to virtual columns are not logged in the online redo log and therefore cannot be
extracted by GoldenGate.

Initial load data cannot be applied to a virtual column.

Virtual source columns can be mapped to non-virtual target columns

Virtual columns in unique keys and indexes are ignored

If a virtual column is the only unique identifier for a table, the remaining columns will be used
for row identification. This can lead to table corruption if the remaining columns do not ensure
uniqueness.

Having Primary key or unique columns on table would good for OGG configuration. In absence
of unique columns OGG still try to manage uniqueness of data by constructing pseudo key. Or
you can define Key columns in extract and replicate so which could drive the OGG as per data
choosed by specified columns.

Bellow given will explains it in detail.

Oracle GoldenGate selects a row identifier to use in the following order of priority
1. Primary key
2. First unique key alphanumerically that does not contain a timestamp or non-
materialized computed column.
 3. If none of the preceding key types exist (even though there might be other types of keys
defined on the table) Oracle GoldenGate constructs a pseudo key of all columns that the
database allows to be used in a unique key,

If a table does not have one of the preceding types of row identifiers, or if you prefer those
identifiers not to be used, you can define a substitute key if the table has columns that always
contain unique values. You define this substitute key by including a KEYCOLS clause within the
ExtractTABLEparameter and the Replicat MAP parameter. The specified key overrides any
existing primary or unique key that Oracle GoldenGate finds.

For example
extract
TABLE CMB_FZ01.MTF, KEYCOLS( p_mid )

replicat
MAP CMB_FRZ01.MTF, TARGET CMB_FRZ02.MTF_STAB, FILTER (@RANGE (1 , 2,
P_MID)), KEYCOLS ( p_mid )

ROW_ID column has a unique index in it. I know that Goldengate cannot replicate tables
without primary keys. But what about the above table with Unique index but no Primary key or
Unique key in it ? Can Goldengate replicate these kind of tables without any issues ?

It is good to have Primary key but not mandatory or even unique key. Golden gate would
replicate in absence of these also. As you have Unique index on ROW_ID column that is
also enough for maintaining the OGG uniqueness.

Below given is the one of the article explaining the same but it is specific to oracle.

In the earlier classic capture mode, the Oracle GoldenGate Extract process captures data
changes from the Oracle redo or archive log files on the source system.

In integrated capture mode, the Oracle GoldenGate Extract process interacts directly with the
database log mining server which mines or reads the database redo log files and captures the
changes in the form of Logical Change Records (LCRs) which are from there written to the
GoldenGate trail files.

The basic difference is that in the Integrated Capture mode, the extract process does not directly
read the redo log files. That part of the job is done by the logmining server residing in the Oracle
database.
Broad
GoldenGate Bidirectional network configuration

This configuration enables forward data flow from source to target, and backward data flow
from target to source systems. Because Oracle GoldenGate extract and replicate groups are
configured on both systems, it's important to handle data conflict as business case scenarios.
Oracle GoldenGate supports common data conflict resolutions, for more details
regarding data conflict resolutions, refer to chapter 4.
GoldenGate Active-active

Oracle GoldenGate delivers real-time data replication with sub-second latency. Bi-directional
active-active setup promotes high availability with customized application scalability, users are
able to connect to either system for conducting transactions.

GoldenGate Active-passive

When implementing Oracle GoldenGate for disaster recovery solution, it's configured as active-
passive setup.

CLASSIC: In classic capture mode, the Oracle GoldenGate Extract process captures data
changes from the Oracle redo or archive log files on the source system or from shipped archive
logs on a standby system.
 INTEGRATED: In integrated capture mode, the Oracle GoldenGate Extract process interacts
directly with a database log mining server to receive data changes in the form of logical change
records (LCR).

Trail Files
Trails Files are the Operating system files which GoldenGate uses to keep records extracted from
the source objects by the extract process. Trail files can be created on the source system, target
system and/or intermediate system depending on the GoldenGate replication setup. Trail Files
on the source system are called Extract Trails or Local Trails and on the target system called as
Remote Trails. By using trail file, GoldenGate minimize load on the source database as once the
transaction logs/online logs/redo logs/ archive logs are extracted and loaded by the extract
process to trail files, all the operations like filtering, conversions, mapping happens out of the
source database. Use of trail file also make the extraction and replication process independent of
each other.

How Lag was reduced from 40 min to near-real-time

We implemented unidirectional conditional replication using goldengate classic method for one
of the major client in US. The replication business logic was based on filtering & data
transformation. Several parameters viz-INSERTMISSINGUPDATES, IGNOREDELETES,
REPERROR were used for data transformation. There were typical challenges we faced during
golden gate implementation. Somehow, Conditional replication was not working on version
11.2.1.0.10. We upgraded goldengate to version 11.2.1.0.27 and conditional replication started
working.
There were millions of records to be replicated every minute and we observed lag of 40-45 minutes
on the target side during replication. We used BATCHSQL parameter to increase the performance
of Replicate. BATCHSQL causes Replicate to organize similar SQL statements into arrays and
apply them at an accelerated rate. We gained some performance improvement using this but still
it wasnt within the accepted timeframe.
We then explored the concept of multiple replicats. Typical problem with multiple replicat is that
data set has to be divided amongst them which might cause consistency issue as transactions
might not be applied in the same order which happened on source. However, as per business logic,
transactions were to be applied serially. We then used multiple replicats along with range
function. In this, we were not grouping different tables in replicats but we were dividing data set
into equally parts based on range. This means that if we are using 3 replicats then we are diving
the data of all replicated tables in 3 equal parts wherein each replicat only works on 1/3 of data of
all tables. This not only ensured that each transactions happens in same way as it happened on
source, but it reduced lag drastically and we were able to perform a near-real time replication and
it took less than 2 minutes to replicate 6+ million records.
Another issue that surfaced was that at source side whenever data was inserted in a new partition
of table, it failed on target side and caused golden gate to abend. Though, interval partitioning was
enabled on both sides, but still issue persisted. We enabled DDL replication to fix this. As per the
requirement, drop and truncate operation were excluded from DDL replication to maintain