This is Part 4 of a four-part blog series on replicating data from an on-premises Oracle Database to Oracle Cloud Infrastructure (OCI) using Oracle GoldenGate.
In this final blog, we focus on establishing secure connectivity between the on-premises and OCI GoldenGate environments using NGINX. Once connectivity is established, we create and configure the Extract and Replicate processes to enable real-time data replication from the on-premises source to the OCI target database.
Related blogs in this series:
The following image illustrates the configuration required to establish secure connectivity between on-premises and OCI GoldenGate deployments.
The WSS (WebSocket Secure) protocol is used in Oracle GoldenGate Distribution Path configuration to enable secure, encrypted data transfer over WebSocket using TLS (Transport Layer Security).
When you configure a Distribution Path in GoldenGate Microservices, you specify a Target URL. To enable encryption, it should look like this:
wss://<host>:<port>/services/v2/receivers/<receiver-name>
In the target deployment, create an administrator user named ggnet to be used for connectivity.
Go to the Admin Client for the target OCI GoldenGate deployment, navigate to Administrator from the menu, click + to add a user, set the user type to Operator, and use Amir123! as the password.
Now, the ggnet user has been created
In the source (on-premises) GoldenGate deployment, open the Administration Service, navigate to Configuration, and click + to add a new credential. In the User ID field, enter the user created in the target deployment (ggnet) and specify the same password.
Now, the credential has been created.
We require a certificate to establish a WSS path for secure communication between the on-premises source system and the target OCI environment.
First, create a configuration file. Using this file, we can then generate the certificate. In the configuration file, be sure to specify the hostname on the last line.
[oracle@src ~]$ pwd /home/oracle [oracle@src ~]$ hostname src.amir.net [oracle@src ~]$ vi genkey.conf [ req ] distinguished_name = DN x509_extensions = V3 prompt = no [DN] CN = src.amir.net [V3] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer basicConstraints = CA:TRUE subjectAltName = "DNS:localhost,DNS:src,DNS:src.amir.net,DNS:127.0.0.1,IP:127.0.0.1"
To create the certificate files (the private key and the .pem certificate), I used the following command.
[oracle@src ~]$ openssl req -newkey rsa:2048 -nodes -keyout src.key -new -x509 -days 3650 -out src.pem -config ./genkey.conf Generating a 2048 bit RSA private key [oracle@src ~]$ ls dis_client.pem dist_client.key genkey.conf
We can see the output of this OpenSSL-created file using the openssl x509 -in src.pem -text command. In the following output, you can see Issuer and subject CN name, which are the same as src.amir.net
Now, go to the Service Manager in your on-premises GoldenGate environment, then navigate to Certificate Management. Make sure you select your deployment from the Deployment Name drop-down list (not the Service Manager).
Click + under Client Certificates. Use cat src.pem to display the certificate, then copy and paste the entire content into the Certificate PEM field. Next, use cat on the private key file and copy and paste the entire content into the Private Key field. Since this is a self-signed certificate, you do not need to enter anything in the CA Certificates field.
Click add, and now the client certificate has been added to the source GoldenGate deployment.
Step 5: Add the destination certificate to the source GoldenGate deployment.
In the browser used to access the target (OCI) GoldenGate Console (for example, Chrome), download the root certificate. Then, in the on-premises GoldenGate Service Manager, navigate to Distribution, ensure the correct deployment is selected, click + under CA Certificates, and upload the downloaded certificate file.
Click the Upload button, then the Add button.
Note: It’s important to understand the difference between Shared and Local options. If you select Shared, the digital root certificate is shared across all deployments, meaning you don’t need to add it to other deployments. If you select Local, the certificate is added only to the current deployment. In this example, I selected Local and then saved it.
Now, both the source and the destination certificates have been added to the source (on-premises) GoldenGate deployment.
In Blog 3 of this series, we created the CDB and PDB credentials and added the TRANDATA schema at the PDB level. With these steps completed, we can now add the Extract process. In the On-Premises GoldenGate Administration Service, go to Overview and click + to add the Extract.
On the opening page, I set the following parameters:
Select the CDB and PDB credentials that we created in blog 3.
Note: I created the table below in the HR schema on both the source and destination PDBs and used it to test Oracle GoldenGate replication.CREATE TABLE TBL_GGTEST ( ID NUMBER(8) , VALUE VARCHAR2(10) , CONSTRAINT TABLE1_PK PRIMARY KEY ( ID ) ENABLE );
The following is the Extract command I used in my test, which captures both DDL and DML changes.
EXTRACT exthr USERIDALIAS cdbggsrc DOMAIN OracleGoldenGate EXTTRAIL ef DDL INCLUDE MAPPED DDLOPTIONS REPORT TABLE pdb1.hr.TBL_GGTEST;
Now, we can start the Extract, which will register it with your database.
Now, the Extract has been started.
Open the on-prem Oracle GoldenGate distribution service and click + button.
For the target host, we can copy it from the OCI Goldengate browser
The port is set to 443. The target trail is the trail name that will be referenced by the Replicat process. In this example, I used rf, and the Replicat trail file will also be named rf.
For the Domain and Alias, use the ggnet credential information created earlier. You can copy and paste these values from the previously created credentials.
All other fields can be left with their default values, then click Create Path.
Now, the path is created
If I check the OCI GoldenGate Console, I can see the path listed under Receiver Paths.
First, connect using the PDB credential and create the checkpoint table in the OCI GoldenGate Console
The checkpoint table has been added
Go to the OCI GoldenGate deployment, click Actions, and select Launch Administration Client.
Now, we can add replicat.
Choosing Nonintegrated provides better performance.
For credential alias use PDB credentials.
The following is the Replicat command I used in my test.
REPLICAT hrrep USERIDALIAS C2DBCSPDB DOMAIN OracleGoldenGate DDL INCLUDE MAPPED BATCHSQL MAP PDB1.HR.TBL_GGTEST, TARGET DESTPDB.HR.TBL_GGTEST;
The Replicat has been created, and we can now start it.
In this final part of the series, we completed the end-to-end Oracle GoldenGate replication setup between the on-premises source database and the OCI target database. We configured NGINX to enable secure communication between the two GoldenGate deployments and created the Extract and Replicat processes to capture and apply transactional changes.
With all components now fully configured—source environment, target environment, database connections, secure networking, and replication processes—you have a complete and functional architecture for replicating data from on-premises to OCI using Oracle GoldenGate. This four-part series provides a practical, step-by-step reference that can be adapted for real-world hybrid and cloud migration scenarios.