Oracle GoldenGate From On-Premises to OCI DBCS – Part 1: Configuring the Source Environment

 

Introduction:

This is Part 1 of a four-part blog series that demonstrates how to replicate data from an on-premises Oracle Database to a database running on Oracle Cloud Infrastructure (OCI) using Oracle GoldenGate.

In this blog, we focus on configuring Oracle GoldenGate in the on-premises source environment, including database prerequisites, user setup, and preparing the source database for change data capture.

Related blogs in this series:

• Part 2: Configuring the Target Environment on OCI
• Part 3: Connecting On-Premises GoldenGate to Source and OCI GoldenGate to Target Database
• Part 4: Connecting On-Premises GoldenGate to OCI using NGINX and Creating Extract & Replicat

Prerequisites

Before configuring Oracle GoldenGate on the on-premises source environment, ensure that the source database is already installed and operational. The following shows the OS and database version in my environment.

Operating System

• Oracle Enterprise Linux 7.9
• My VM IP is 192.168.56.10

Database Software

• Oracle Database 19c (19.3)
• Database is up and running in ARCHIVELOG mode

Installing Oracle GoldenGate Microservices Architecture on the Source Environment

In this section, we install and configure Oracle GoldenGate Microservices Architecture on the on-premises source environment. Oracle GoldenGate Microservices Architecture provides a modern, web-based deployment model that simplifies administration, improves scalability, and enhances security compared to the classic architecture.

This step prepares the source system to capture transactional changes from the on-premises Oracle Database and publish them for downstream replication. ###The installation includes deploying the GoldenGate software, creating the service manager, and validating access to the administration services, which will be used in later steps to configure Extract and Data Pump processes.###

Step 1: Create a home directory for Goldengate

I downloaded Oracle GoldenGate 21.3, copied it to the /software directory, unzipped the GoldenGate files, and changed the ownership of the extracted directory.

Step 2: Accessing the GUI on the Linux Server Using Xming and PuTTY

To work with the graphical interface on the Linux server, follow these steps:

1. Start Xming on your Windows machine. This enables X11 forwarding for GUI applications.

2. Open PuTTY and load your Linux server connection

3. Enable X11 forwarding in PuTTY before connecting to the server.

4. Connect to the server. Once logged in, you can launch GUI-based applications from the Linux server, and the windows will appear on your Windows machine.

This setup allows you to interact with GUI tools on the Linux server while working from Windows.

Step 3: Execute runinstaller

Reconnect to the VM using the oracle user, navigate to the Oracle GoldenGate installation directory, and execute runInstallet.

Set the Oracle GoldenGate software location to /u01/app/oracle/ogg.

Step 4 (Optional): Add OGG_HOME to .bash_profile file

Step5: Execute oggca.sh

This sets up the necessary services, directories, and permissions required for GoldenGate Microservices Architecture to function correctly. Once executed, you can proceed to configure the Manager and other GoldenGate processes.

Create a folder for the Service Manager home. The Service Manager home should be located outside the Oracle GoldenGate software directory. In this setup, I created it at /u01/app/oracle.

NOTE: If you are installing Oracle GoldenGate on an existing database server configured with Grid Infrastructure, you can take advantage of XAG to start and stop GoldenGate, and you can verify its status as well.

Select add new GoldenGate deployment

Enter the deployment name and the software home

I created the deployment home directory in /u01/app/oracle, with the same name as the deployment, which is onprem.

NOTE: Since I already have a database installed on my server, I provided the path to its tnsnames.ora file to avoid conflicts and multiple tnsnames.ora files. If this were a fresh server without an Oracle database installed, you could specify any path within the GoldenGate home directory—for example, ${OGG_HOME}/etc.

Enter username and password for the Administrator account.

Set a specific port for each service.

The default schema is provided for replication for backward compatibility. In the new GoldenGate version, only the schema specified in your Extract or Replicat is used.

Click Next.

Click Finish.

It will give you a script that must be executed as the root user.

Open another SSH login with root and execute the above script

Click OK, then click Close.

Check everything is working correctly. Service is with a capital S in the following grep.

We can log in to the admin client using this URL in our browser: http://192.168.56.10:9000/?root=account

After logging in, you should see something like the following.

Create c##admin user on the source database

Oracle GoldenGate Microservices Architecture requires a common user, typically C##ADMIN, when working with an Oracle Database 19c multitenant environment. GoldenGate operates at the CDB level, which means it needs access to system metadata and internal objects across one or more PDBs. A common user allows GoldenGate services to authenticate consistently and manage metadata centrally. The C##ADMIN user is used by components such as the Administration Server, Extract, and Data Pump to interact securely with the database. This user must be created on both the source and target databases, as each side independently captures or applies data changes. Using a dedicated common user instead of SYS follows Oracle best practices and improves security, auditability, and upgrade compatibility.

Connect to the CDB, add supplemental log data, and create the common user for GGS using the follwoing codes.

--At CDB level
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH;
DROP USER c##ggadmin CASCADE;
CREATE USER c##ggadmin IDENTIFIED BY "**********" CONTAINER=all;
ALTER USER c##ggadmin SET CONTAINER_DATA=all CONTAINER=current;
GRANT CREATE SESSION TO c##ggadmin;
GRANT CREATE VIEW TO c##ggadmin;
GRANT CONNECT TO c##ggadmin CONTAINER=all;
GRANT RESOURCE TO c##ggadmin;
GRANT ALTER SYSTEM TO c##ggadmin;
GRANT SELECT ANY DICTIONARY TO c##ggadmin;

exec dbms_goldengate_auth.grant_admin_privilege('C##GGADMIN', CONTAINER => 'all');
exec dbms_goldengate_auth.grant_admin_privilege('C##GGADMIN');
grant unlimited tablespace to c##ggadmin;
grant dba to c##ggadmin;

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Now, go to the pluggable database and add supplemental log data here as well

--At pdb level
Alter session set container=PDB1;
ALTER PLUGGABLE DATABASE ADD SUPPLEMENTAL LOG DATA;

Conclusion

In this first part of the series, we completed the foundational steps required to configure Oracle GoldenGate on the on-premises source environment. We covered the necessary database prerequisites, installed and configured GoldenGate Microservices Architecture, created the required users, and prepared the source database for change data capture.

With the source environment now fully configured and ready to capture transactional changes, we can move to the next phase of the setup. In Part 2, we will focus on configuring Oracle GoldenGate on the target database in OCI, ensuring it is ready to receive replicated data.

After configuring both environments, Part 3 will connect the on-premises and OCI GoldenGate setups, and Part 4 will show how to use NGINX to streamline connectivity and finalize the Extract and Replicat processes for end-to-end replication.