Oracle GoldenGate Microservices: one-way Oracle → Oracle replication

Replicates a PDB schema to another database continuously (with a lag of seconds) using GoldenGate 21c or 23ai/26ai Microservices. At the end, Integrated Extract and a Distribution Path run on the source and a Parallel Replicat runs on the target; the target schema is populated with an initial load from a consistent SCN, and end-to-end lag is measured with heartbeat. The difference from Data Guard: this is row-level (logical) replication, not a physical copy; the target is open and writable and can be on a different version/platform. Source and target can be single instance or RAC; for day-to-day operations and failures use the GoldenGate operations guide.

Topology: Source DB server (OGG source deployment) + target DB server (OGG target deployment); on RAC, GoldenGate on node 1 (or as a cluster resource with XAG)

Before you start

• A GoldenGate license and access to My Oracle Support/eDelivery are in place. …/… (the Microservices software for Oracle Database) is ready on both servers; version certification (OGG version ↔ DB version ↔ operating system) has been verified in the MOS certification matrix.
• The servers run …Oracle Linux / RHEL 7.9…Oracle Linux / RHEL ……; the oracle user and the oinstall group exist (database server), and unzip is installed (if not, as root: … -y install unzip). There is at least 4 GB of free RAM for GoldenGate, ~2 GB for the software, and disk space for trail files sized by redo generation (redo generated per day × retention days).
• The source database is a CDB in ARCHIVELOG mode (if not, this guide enables it); archived logs must not be deleted until Extract has processed them (RMAN deletion policy). The source and target PDBs are open and their services are registered with the listener.
• The tables in the … schema to be replicated have a primary key (or a non-null unique key). On tables without a key, all columns are treated as the key; updates slow down and there is a risk of matching the wrong row.
• Data types/objects in the schema that GoldenGate does not support or that need special handling have been reviewed (DBA_GOLDENGATE_SUPPORT_MODE).
• …/tcp (Receiver Server) is open from source to target; for administration, …–…/tcp is open to the admin network on both servers. The servers resolve each other by name…, the SCAN names (…………, …………) resolve in DNS…; clocks are synchronized with NTP.
• There must be no long-running open transactions on the source during the Integrated Extract registration and the initial load; a quiet time window has been planned for the initial load.
• On the RAC side Clusterware is healthy and srvctl works as the oracle user; the GoldenGate software and deployment will be installed on one node (…………, …………). If automatic takeover on node loss is required, XAG + a shared (ACFS) directory has been planned (see notes).

Phases of the guide

• Source database preparation — Check the state of the source database · Enable ARCHIVELOG mode (if needed) · Database settings for GoldenGate (source) · Create the GoldenGate capture user (source) · Create the GoldenGate service (source RAC) · Define the Data Pump directory (source PDB)
• Target database preparation — Database settings for GoldenGate (target) · Create the ggadmin user (target PDB) · Create the GoldenGate service (target RAC) · Define the Data Pump directory (target PDB)
• GoldenGate software installation (both servers) — Create the directories · Extract the installation media · Prepare oggcore.rsp from the template · Install the GoldenGate software (silent) · Define the OGG_HOME environment variable
• Service Manager and deployments (oggca) — Write the oggca response file (source) · Create the deployment (oggca, source) · Register the Service Manager as a systemd service (source) · Write the oggca response file (target) · Create the deployment (oggca, target) · Register the Service Manager as a systemd service (target) …
• Source: credentials, trandata, heartbeat, Extract, Distribution Path — Prepare the credential store and the database connection (source) · Enable schema-level supplemental logging · Create the heartbeat table (source) · Register and add the Integrated Extract · Write the Extract parameter file · Start the Extract …
• Target: credentials, checkpoint, Parallel Replicat — Prepare the credential store and the database connection (target) · Create the heartbeat and checkpoint tables (target) · Add the Parallel Replicat · Write the Replicat parameter file
• Initial load and starting the Replicat — Check for open transactions (source) · Get the initial load SCN and export (expdp) · Copy the dump files to the target · Import into the target (impdp) · Start the Replicat after the SCN · Start the Replicat
• Verification and monitoring — Check the state of all processes (source) · Check the state of all processes (target) · End-to-end test: insert rows (source) · End-to-end test: check the rows and the lag (target) · Monitoring and maintenance