Implementing Oracle GoldenGate High Availability on RAC Environments

Integrating Oracle databases with external big data platforms often necessitates robust data synchronization solutions. Oracle GoldenGate (OGG) is a common choice for this, but its high-availability (HA) configuration within an Oracle Real Application Clusters (RAC) environment can be complex. This guide outlines the steps to deploy OGG on an Oracle RAC setup and configure it for high availability using Oracle Clusterware.

Environment Overview

The following details describe the source and target environments used for this configuration:

Source Database: Oracle Database 12.1.0.1 RAC (SE)
RAC Nodes:
- dbnode1 (IP: 10.0.24.131)
- dbnode2 (IP: 10.0.24.132)
- SCAN VIPs: 10.0.24.135, 10.0.24.136, 10.0.24.137
Database/Schema: PRODDB/SALES
Oracle GoldenGate Version: OGG-12.2.0.1
Planned OGG Virtual IP (VIP): 10.0.24.138 (Named: gg_vip_svc)
Target System: OGG for Big Data
Target System Address: 10.18.0.41

Oracle GoldenGate Installation

1. Configure Shared Filesystem for OGG

The Oracle GoldenGate installation directory and its associated trail files must reside on a shared filesystem accessible by all RAC nodes. Oracle Automatic Storage Management Cluster File System (ACFS) or Network File System (NFS) are suitable options. For this setup, we assume /opt/oracle/goldengate is configured as a shared mount point.

Create the OGG installation directory and set appropriate permissions on all RAC nodes:

[root@dbnode1 ~]# mkdir -p /opt/oracle/goldengate
[root@dbnode1 ~]# chown -R oracle:oinstall /opt/oracle/goldengate
[root@dbnode1 ~]# chmod -R 755 /opt/oracle/goldengate

2. Configure Oracle User Environment Variables

Ensure the oracle user's environment on each RAC node includes the necessary paths for GoldenGate and Oracle Database binaries. Add the following to ~oracle/.bash_profile:

export GGS_HOME=/opt/oracle/goldengate/core
export PATH=$PATH:$HOME/bin:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$GGS_HOME
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:${GGS_HOME}:${LD_LIBRARY_PATH}

Apply the changes by sourcing the profile: source ~/.bash_profile.

3. Download and Extract OGG Software

Obtain the Oracle GoldenGate 12.2.0.1 installation package (e.g., V100692-01.zip) and upload it to a temporary software directory on one of the RAC nodes (e.g., /tmp/software_dist).

[oracle@dbnode1 ~]# mkdir -p /tmp/software_dist/ogg_install
[oracle@dbnode1 ~]# unzip /tmp/software_dist/V100692-01.zip -d /tmp/software_dist/ogg_install

4. Launch OGG Installer

Navigate to the extracted installation directory and run the installer using the oracle user with X11 forwarding enabled:

[oracle@dbnode1 ~]$ cd /tmp/software_dist/ogg_install/fbo_ggs_Linux_x64_shiphome/Disk1
[oracle@dbnode1 Disk1]$ ./runInstaller

During the installation, specify the Oracle GoldenGate Home as the shared directory /opt/oracle/goldengate/core.

Database Preparation

1. Enable Database-Level Supplemental Logging

Supplemental logging is essential for GoldenGate to capture all necessary change data. Connect to the database as SYSDBA and execute the following commands:

[oracle@dbnode1 ~]$ export ORACLE_SID=PRODDB1
[oracle@dbnode1 ~]$ sqlplus / as sysdba

SQL> ALTER DATABASE FORCE LOGGING;
Database altered.

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Database altered.

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
System altered.

SQL> SELECT name, open_mode, force_logging, supplemental_log_data_min FROM v$database;

NAME       OPEN_MODE  FORCE_LOGG SUPPLEMENTAL_LOG_DATA_MI
---------- ---------- ---------- ------------------------
PRODDB     READ WRITE YES        YES

2. Create TNS Entry for GoldenGate

To allow GoldenGate to connect to the Oracle RAC database instance, configure a TNS entry. This is particularly useful for managing multiple GoldenGate extracts connecting to different databases or services. Add the following to $ORACLE_HOME/network/admin/tnsnames.ora on the RAC nodes:

PRODDB_GGS =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.0.24.136)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PRODDB)
    )
  )

3. Create GoldenGate Administration User and Tablespace

Create a dedicated tablespace and user for GoldenGate metadata and checkpoint table. Use ASM disk groups for tablespace creation in a RAC environment:

SQL> CREATE TABLESPACE ggs_data DATAFILE '+DATA_DISKGRP' SIZE 1M AUTOEXTEND ON MAXSIZE 10G;
Tablespace created.

SQL> CREATE USER gguser DEFAULT TABLESPACE ggs_data IDENTIFIED BY gguser_pwd;
User created.

SQL> GRANT CONNECT, RESOURCE, DBA TO gguser;
Grant succeeded.

Oracle GoldenGate Configuration

1. Set Global Parameters

Configure the global parameters for GoldenGate, typically located in the GLOBALS file within the OGG installation directory. This specifies the schema used by GoldenGate for its internal tables.

[oracle@dbnode1 ~]$ cd /opt/oracle/goldengate/core
[oracle@dbnode1 core]$ ggsci

GGSCI (dbnode1) 1> EDIT PARAMS ./GLOBALS

Add the following line to the GLOBALS file:

GGSCHEMA gguser

2. Configure the Manager Process

The Manager proces controls all other GoldenGate processes. Configure its parameters to enable auto-startup, autorestart, and trail file purging.

GGSCI (dbnode1) 2> EDIT PARAM MGR

Add these parameters:

PORT 7809
AUTOSTART ER *
AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60
LAGREPORTHOURS 1
LAGINFOMINUTES 3
LAGCRITICALMINUTES 10
PURGEOLDEXTRACTS /opt/oracle/goldengate/dirdat/*, USECHECKPOINTS, MINKEEPDAYS 7

3. Log in to the Database and Create Checkpoint Table

Before configuring extracts, log in to the source database via GoldenGate and create the checkpoint table.

GGSCI (dbnode1) 8> DBLOGIN USERID gguser@PRODDB_GGS, PASSWORD gguser_pwd
Successfully logged into database.

GGSCI (dbnode1 as gguser@PRODDB_GGS) 9> ADD CHECKPOINTTABLE gguser.ggs_ckpt_tab
Successfully created checkpoint table gguser.ggs_ckpt_tab.

4. Enable Supplemental Logging for Tables

Enable supplemental logging for the specific tables or schemas that GoldenGate will capture changes from. This example tracks all tables within the SALES schema.

GGSCI (dbnode1 as gguser@PRODDB_GGS) 11> ADD TRANDATA SALES.*

5. Configure the Extract Process

The extract process captures transactional data from the source database. For a RAC environment, configure it with the THREADS parameter matching the number of RAC instances (or more). The TRANLOGOPTIONS DBLOGREADER parameter is crucial for RAC setups.

GGSCI (dbnode1) 1> ADD EXTRACT primary_extract, TRANLOG, BEGIN NOW, THREADS 2

GGSCI (dbnode1) 2> ADD EXTTRAIL /opt/oracle/goldengate/dirdat/pe, EXTRACT primary_extract, MEGABYTES 100

GGSCI (dbnode1 as gguser@PRODDB_GGS) 3> EDIT PARAMS primary_extract

Add these parameters for primary_extract:

EXTRACT primary_extract
USERID gguser@PRODDB_GGS, PASSWORD gguser_pwd
TRANLOGOPTIONS DBLOGREADER
EXTTRAIL /opt/oracle/goldengate/dirdat/pe
TABLE SALES.*;

6. Configure the Data Pump Process

The data pump extract process reads trail files generated by the primary extract and forwards them to the target system. This intermediate step provides fault tolerance and allows for data filtering or transformation.

GGSCI (dbnode1) 1> ADD EXTRACT pump_extract, EXTTRAILSOURCE /opt/oracle/goldengate/dirdat/pe
EXTRACT added.

GGSCI (dbnode1) 2> ADD RMTTRAIL /data/ogg_target/dirdat/re, EXTRACT pump_extract
RMTTRAIL added.

GGSCI (dbnode1) 3> EDIT PARAM pump_extract

Add these parameters for pump_extract:

EXTRACT pump_extract
USERID gguser@PRODDB_GGS, PASSWORD gguser_pwd
RMTHOST 10.18.0.41, MGRPORT 7809
RMTTRAIL /data/ogg_target/dirdat/re
TABLE SALES.*;

7. Start GoldenGate Processes

Start both the data pump and primary extract processes and verify their status.

GGSCI (dbnode1) 4> START EXTRACT pump_extract
GGSCI (dbnode1) 5> START EXTRACT primary_extract

GGSCI (dbnode1) 6> INFO ALL

Program     Status      Group             Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING                                           
EXTRACT     RUNNING     PRIMARY_EXTRACT   00:00:00      00:00:07
EXTRACT     RUNNING     PUMP_EXTRACT      00:00:00      00:00:02

Verify that trail files are being generated in the specified directory:

[oracle@dbnode1 dirdat]$ pwd
/opt/oracle/goldengate/dirdat
[oracle@dbnode1 dirdat]$ ls -lh
total 1.2M
-rw-r----- 1 oracle oinstall 1.1M Sep 10 10:15 pe000000000

High Availability Configurasion with Oracle Clusterware

To ensure GoldenGate processes are highly available and can fail over between RAC nodes, integrate them with Oracle Clusterware.

OGG VIP: 10.0.24.138 (Resource Name: gg_vip_svc)

1. Query Current RAC Network Information

Determine the active network resource and subnet managed by Clusterware:

[grid@dbnode1 ~]$ crsctl stat res -p | grep -E '.network|subnet|NAME'
NAME=ora.net1.network
USR_ORA_SUBNET=10.0.24.0

2. Add OGG VIP Resource to Clusterware

Create a dedicated application VIP resource for GoldenGate. This VIP will float between RAC nodes with the OGG processes.

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/appvipcfg create \
  -network=1 \
  -ip=10.0.24.138 \
  -vipname=gg_vip_svc \
  -user=root

# Output may show a resource type already exists, which is normal on subsequent runs.
# The critical part is the resource creation.

3. Grant Permissions for the OGG VIP Resource

Allow the oracle user to manage the newly created VIP resource.

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl setperm resource gg_vip_svc -u user:oracle:r-x

4. Verify and Start the OGG VIP

Check the VIP's status and start it:

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl status resource gg_vip_svc
NAME=gg_vip_svc
TYPE=app.appvip_net1.type
TARGET=OFFLINE
STATE=OFFLINE

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl start resource gg_vip_svc
CRS-2672: Attempting to start 'gg_vip_svc' on 'dbnode1'
CRS-2676: Start of 'gg_vip_svc' on 'dbnode1' succeeded

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl status resource gg_vip_svc
NAME=gg_vip_svc
TYPE=app.appvip_net1.type
TARGET=ONLINE
STATE=ONLINE on dbnode1

5. Create Clusterware Action Script for OGG

Develop a shell script that Oracle Clusterware will use to start, stop, and check the status of GoldenGate Manager and its associated processes. This script must be placed on the shared filesystem.

[oracle@dbnode1 ~]$ mkdir -p /opt/oracle/goldengate/core/scripts
[oracle@dbnode1 ~]$ vi /opt/oracle/goldengate/core/scripts/gg_crs_actions.sh

Paste the following content into gg_crs_actions.sh:

#!/bin/bash
# Oracle GoldenGate Clusterware Action Script for HA

# Set Oracle GoldenGate installation directory
export GGS_HOME="/opt/oracle/goldengate/core"

# Set Oracle Database Home (for GGSCI to connect to DB)
export DB_HOME="/u01/app/oracle/product/12.1.0/db_1" # Adjust to your actual DB_HOME

# Delay after start command before checking status
declare -r INITIAL_START_DELAY=5

# Include OGG Home in library path
export LD_LIBRARY_PATH="${DB_HOME}/lib:${GGS_HOME}:${LD_LIBRARY_PATH}"

# Function to execute GGSCI commands
execute_ggsci_cmd() {
  local command="$1"
  local output
  output=$(${GGS_HOME}/ggsci <<eof all="" case="" check="" check_manager_status="" e="" echo="" else="" eof="" er="" esac="" execute_ggsci_cmd="" exit="" extract="" fi="" force="" forcefully="" function="" goldengate="" grep="" healthy="" if="" in="" is="" kill="" local="" manager="" manager.="" manager...="" not="" processes="" processes...="" resource="" return="" running="" sleep="" start="" started="" status_output="" stop="" stopped.="" successfully.="" terminated.="" then="" to="" unhealthy="" up=""></eof>

Make the script executable:

[oracle@dbnode1 ~]$ chmod +x /opt/oracle/goldengate/core/scripts/gg_crs_actions.sh

6. Add GoldenGate Application Resource to Clusterware

Register the GoldenGate application (controlled by the script) as a Clusterware resource. This resource depends on the OGG VIP and ASM.

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl add resource gg_app_res \
  -type cluster_resource \
  -attr "ACTION_SCRIPT=/opt/oracle/goldengate/core/scripts/gg_crs_actions.sh, \
  CHECK_INTERVAL=30, \
  START_DEPENDENCIES='hard(gg_vip_svc,ora.asm) pullup(gg_vip_svc)', \
  STOP_DEPENDENCIES='hard(gg_vip_svc)'"

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl setperm resource gg_app_res -o oracle

7. Manage GoldenGate with Clusterware

Now, GoldenGate can be started, stopped, and monitored directly through Clusterware. Ensure the Clusterware resource group is online before starting the OGG components.

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl status resource gg_app_res
NAME=gg_app_res
TYPE=cluster_resource
TARGET=OFFLINE
STATE=OFFLINE

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl start resource gg_app_res
CRS-2679: Attempting to clean 'gg_app_res' on 'dbnode1'
CRS-2681: Clean of 'gg_app_res' on 'dbnode1' succeeded
CRS-2672: Attempting to start 'gg_app_res' on 'dbnode1'
CRS-2676: Start of 'gg_app_res' on 'dbnode1' succeeded

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl status resource gg_app_res
NAME=gg_app_res
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on dbnode1

Verify GoldenGate processes are running:

GGSCI (dbnode1) 2> INFO ALL

Program     Status      Group             Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING                                           
EXTRACT     RUNNING     PRIMARY_EXTRACT   00:00:00      00:00:03
EXTRACT     RUNNING     PUMP_EXTRACT      00:00:00      00:00:02

To stop OGG via Clusterware:

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl stop resource gg_app_res
CRS-2673: Attempting to stop 'gg_app_res' on 'dbnode1'
CRS-2677: Stop of 'gg_app_res' on 'dbnode1' succeeded

8. Failover Testing

To test the HA configuration, initiate a manual relocation of the GoldenGate application resource. Before testing, ensure the tnsnames.ora configuration with the PRODDB_GGS entry is synchronized across all RAC nodes.

[root@dbnode1 ~]# /opt/grid_infra/product/12.1.0/grid/bin/crsctl relocate resource gg_app_res -f
CRS-2673: Attempting to stop 'gg_app_res' on 'dbnode1'
CRS-2677: Stop of 'gg_app_res' on 'dbnode1' succeeded
CRS-2673: Attempting to stop 'gg_vip_svc' on 'dbnode1'
CRS-2677: Stop of 'gg_vip_svc' on 'dbnode1' succeeded
CRS-2672: Attempting to start 'gg_vip_svc' on 'dbnode2'
CRS-2676: Start of 'gg_vip_svc' on 'dbnode2' succeeded
CRS-2672: Attempting to start 'gg_app_res' on 'dbnode2'
CRS-2676: Start of 'gg_app_res' on 'dbnode2' succeeded

After relocation, verify the GoldenGate processes on the new active node (dbnode2 in this example).

On dbnode1 (old active node):

GGSCI (dbnode1) 4> INFO ALL

Program     Status      Group             Lag at Chkpt  Time Since Chkpt

MANAGER     STOPPED                                           
EXTRACT     STOPPED     PUMP_EXTRACT      00:00:00      00:00:28     
EXTRACT     STOPPED     PRIMARY_EXTRACT   00:00:00      00:00:27

On dbnode2 (new active node):

GGSCI (dbnode2) 1> INFO ALL

Program     Status      Group             Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING                                               
EXTRACT     RUNNING     PUMP_EXTRACT      00:00:00      00:00:01    
EXTRACT     RUNNING     PRIMARY_EXTRACT   00:00:00      00:00:09

This confirms that GoldenGate processes, along with its VIP, successfully failed over to the alternate RAC node, demonstrating high availability.

Tags: Oracle GoldenGate Oracle RAC High Availability Clusterware Data Replication

Posted on Wed, 21 Oct 2026 16:40:04 +0000 by MobiTec

Freaks City