Create a DBCS Database in Italy VCN and another DBCS in Amsterdam and

Sync them from Italy to Amsterdam using GG microservices (Unidirectional)

➢ Key Considerations
1. Source: DBCS in Italy (Milan)
2. Target: DBCS in Netherlands (Amsterdam)
3. Source VCN: ITALY-VCN (14.0.0.0/16)
4. Target VCN : NDL-VCN (15.0.0.0/16)
5. DRG-RPC peering to peer Italy and Netherlands this is must be in place.
6. DNS Resolver: Required to resolve the fully qualified domain names (FQDNs) of
OCI Golden Gate deployments across regions, as they are in private subnets and
communicate over the peered VCNs.
7. Distribution Path: Created on the source (Italy, Golden Gate-Milan) to send
replicated data to the target (Amsterdam, Golden Gate-Amsterdam).
8. Receiver Path: Automatically created on the target when the distribution path is
established from the source, so no manual receiver path configuration is
needed.
9. DBCS instances in both regions are on Oracle Database version 19.27.
10. OCI GG microservice Ver: 23.8.2.25.05 (Latest June 2025)
11. OCI GG console users: oggadmin-milan and oggadmin-amsterdam
12. Database User: OGGUSER

Introduction:

Oracle Golden Gate microservices architecture (MA) is a replication tool that lets you
manage and configure data replication across multiple database environments. It uses
RESTful services and a microservices-based architecture to simplify the management,
configuration, and monitoring of cloud deployments.

1
Architecture:

In our case on target instead of Autonomous Database we have OCI DBCS database.

• Oracle Golden Gate 23ai:

Is available in Oracle Cloud Infrastructure (OCI) as a fully managed cloud service.

Includes features like high availability for microservices, improved observability, and
support for Oracle Database 23ai.

Can be used for a variety of use cases, including cross-region and cross-cloud high
availability, data migration, and data analysis for various databases like Oracle, MySQL,
MS SQL, PostgreSQL and cloud like Microsoft Azure, Amazon Relational Database
Service (RDS) and so on.

➢ Verify Network Connectivity and Security Rules

• Confirm VCN Peering:
❖ Ensure the DRG-RPC peering between Italy (Milan) and Amsterdam is active,
with peering status set to “PEERED” in the OCI Console for both regions’ RPCs.
❖ Verify route tables:

In Italy VCN (14.0.1.0/24), the route table for the private subnet should have a
rule routing traffic destined for 15.0.1.0/24 to the DRG.

In Amsterdam VCN (15.0.1.0/24), the route table for the private subnet should
have a rule routing traffic destined for 14.0.1.0/24 to the DRG.

• Update Security Lists

In Italy VCN, add ingress rules to the private subnet’s security list (14.0.1.0/24):
❖ Allow TCP port 443 from 15.0.1.0/24 (for Golden Gate communication).
❖ Allow TCP port 1521/1522 from 15.0.1.0/24 (for database connectivity, if
needed).

In Amsterdam VCN, add ingress rules to the private subnet’s security list (15.0.1.0/24):

2
 ❖ Allow TCP port 443 from 14.0.1.0/24 (for Golden Gate communication).
❖ Allow TCP port 1521/1522 from 14.0.1.0/24 (for database connectivity, if
needed).
❖ Add egress rules in both VCNs to allow outbound traffic to the peer
subnet on ports 443 and 1521/1522.

➢ Configure DNS Resolver Endpoints

Since the Golden Gate deployments are in private subnets, a DNS Resolver with
listening and forwarding endpoints is required to resolve the OCI Golden Gate domain
names across regions.

In Italy (Milan) VCN

• Navigate to Networking > Virtual Cloud Networks in the OCI Console.

• Click on Private Resolver

Click on ITALY-VCN

3
Click on Endpoints.

• Create a Listening Endpoint

• Create Endpoint

Note: An IP address in the subnet used to listen for queries. If a listening address is not
provided, then it will be assigned by the system.

4
 • Create a Forwarding Endpoint

Note: An IP address in the subnet that queries may be forwarded from. If a forwarding
address is not provided then it will be assigned by the system.

5
Note: Perform above exact steps to create Listening and forwarding Endpoint on Target
Amsterdam Region.

• Amsterdam Region:

On Source Italy:

• Under Rules, click Manage Rules:

6
Destination IP: Private IP of the Amsterdam DNS Resolver’s Listening Endpoint

Domain: GG domain name of Amsterdam.

In Amsterdam VCN:

• Repeat the above steps for the Amsterdam VCN (NDL-VCN).

1st create the endpoints as we did for source Italy(Milan) .

7
 • Under Rules, click Manage Rules:

Destination IP: Private IP of the Milan DNS Resolver’s Listening Endpoint

Domain: GG domain name of Italy.

➢ Update Security Lists for DNS:
In both regions, add ingress rules to allow UDP/TCP port 53 (DNS) from the peer
subnet:
Italy: Allow 15.0.1.0/24 → 14.0.1.0/24 on port 53.
Amsterdam: Allow 14.0.1.0/24 → 15.0.1.0/24 on port 53.

8
Italy Private security List:

Amsterdam Private Security List:

9
 ➢ Provision Oracle GoldenGate Microservices for Source and Target

• Go to OCI Console → GoldenGate → Deployments.

• Create a Deployment in both regions:

o Region 1 (Italy): for source DB.

o Region 2 (Amsterdam): for target DB.

• Choose Microservices Architecture

• Use Private Endpoint inside the same subnet as the DBCS or with connectivity via RPC.

• Set admin username/password.

➢ Configure Oracle GG microservice with DBCS Database in Amsterdam

Italy:

10
11
12
Create Vault in Italy:

13
14
User Password: DynaBook1234##

Password: DynaBook1234## for ogguser (database user)

15
 ➢ Configure Oracle GG microservice with DBCS Database in Amsterdam.

Amsterdam:

16
17
Create Vault in Amsterdam:

18
Create Secret

User Password: DynaBook1234## this user is for GG console login.

19
20
 ➢ Create Below user in Pluggable database on Source Italy Region DBCS and Target
Amsterdam DBCS

• CREATE USER ogguser IDENTIFIED BY DynaBook1234##;

• GRANT CREATE SESSION, ALTER SESSION, RESOURCE, CONNECT TO ogguser;
• GRANT DBA TO ogguser; (this is only from POC/Testing Perspective)
• GRANT SELECT ANY DICTIONARY, SELECT ANY TABLE, INSERT ANY TABLE, UPDATE ANY TABLE,
DELETE ANY TABLE TO ogguser;
• EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('ogguser',
CONTAINER=>'CURRENT');
• ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -----> in CD$ROOT

➢ Create Connection

No need to enter Wallet secret as it is a optional thing.

21
• Perform Same Steps to create Connection in Amsterdam Region.

22
23
 ➢ Test Connectivity:

Test connectivity from GG Console in Italy:

Click on the above arrow to perform DB Connectivity.

If connection is successful, we get below message.

Check from Deployment→ Assigned Connection page

24
• Test connectivity from GG Console in Amsterdam:

25
Reference: https://docs.public.content.oci.oraclecloud.com/en-us/iaas/goldengate/doc/connectivity-
issues-oracle-database.html

➢ Populate Source Database in Italy with Data which will used for initial load to Target
Database in Amsterdam.

26
27
28
29
Insert data into above 10 tables created in the pluggable database PLUG1 on source Italy

It’s a script that inserts 70000 rows of data in the table ICC_INDIA_PLAYERS under CRICKET
Schema.

30
Once data is inserted, we should see output as above.

➢ Export the data inserted using data pump utility.

• On Source Italy DBCS Server:

Note the current_scn:

31
• On Target Amsterdam DBCS:

32
Scp dumps from source Italy to Amsterdam.

• Import the initial Load data into target database.

33
 ➢ Add an Extract (23ai)

Before you begin

• Oracle GoldenGate relies on the redo logs to capture the data that it needs to replicate source
transactions. Enable supplemental logging on the source database for unidirectional replication,
or both source and target for bidirectional replication:
• ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
• Ensure that you enable table-level supplemental by adding TRANDATA. If schema-level
supplemental logging is already enabled, you can skip these steps.

1. In the OCI GoldenGate deployment console, expand DB Connections, and select your source
database.
2. Next to TRANDATA Information, click Add TRANDATA (plus icon).

• To add an Extract in Oracle GoldenGate 23ai:

Log in to GoldenGate-Milan Deployment Console (as oggadmin-milan)

• In the OCI GoldenGate deployment console, on the Administration Service Home page, click Add
Extract.

• In the Add Extract panel, on the Extract Information page, complete the following fields as
needed, and then click Next:

• Select an Extract Type:

34
 • Integrated Extract
• Initial Load Extract

• Select the Source Credentials:

• Domain
• Alias
• Registration options:
• Enter the Commit Sequence Number (CSN).
• For Share, choose a method to share the LogMiner data directory:
• Automatic: allows the system to choose the method for sharing.
• None: doesn't share the dictionary.
• Extract Name: shares the LogMiner dictionary for this Extract.
• Enable Optimized to optimize Extract registration.
• Extract Trail:
• Enter a Name for the Extract process.
• Enter a Subdirectory name to set a custom location for the generated Trail file.
• Enter Trail Sequence to set the starting number for Trail files.
• Enter a Trail Size to set the max size for the generated trail file.
• Select an Encryption Profile. The Local Wallet profile is selected by default if an
encryption profile wasn't created.
• Select an Encryption Algorithm:
• NONE
• AES256
• AES192
• AES128

35
• On the Managed Options page, complete the following optional fields as needed, and then click
Next:

• Profile Name
• Critical to deployment health
• Auto Start
• Auto Restart

• Click on Create / Create and run to have Extract Running on source Italy.

36
• Create Replicat in Amsterdam (Target)

Log in to Golden Gate-Amsterdam Deployment Console (as oggadmin-amsterdam).

Add Replicat:

Navigate to Administration Service > Replicat and click Add Replicat.

37
➢ Choose the "Begin" Option

Given that you’re unsure where to begin and want to pull missing data, here are the
implications of each option:

• Now: This will start the Replicat from the current position (the latest trail file at 02:34 PM
IST on June 16, 2025). It will only process new changes going forward, missing any prior
data that wasn’t replicated. Not suitable since you need to recover missing data.

• Custom Time: This allows you to specify a timestamp to start from. If you know when
the missing data was updated (e.g., 10:00 AM IST on June 16, 2025), you can use this to
start from that point. This is a good option if you have a rough idea of the time.

• Position in Log: This lets you specify the exact trail file sequence number and RBA
offset. This is the most precise option if you want to start from the earliest available trail
file to ensure all missing data is processed. This is the best choice if you’re unsure of the
exact time or want to process all available data

• In my case as this is a POC and I haven’t entered anything new on Source after
initial data was inserted and same was copied over to Target DB , I am going to
choose Begin “Now”.

38
• Click on create and run the replicat.

➢ Add a Distribution Path

A Distribution path sends the transaction of data from an Extract to a Replicat.

• When to use a Distribution Path

Use a Distribution Path when you need to replicate data in a distributed deployment
environment. A Distribution Path sends the transaction of data from the Extract to the Replicat.
Creating and running a Distribution Path automatically creates a Receiver Path in the target
deployment's Receiver service. The Receiver Path receives the transaction of data from the
source deployment's Distribution service.

The source deployment is the deployment where you create the Distribution Path. The target
deployment is the deployment to which the extracted data and Trails are sent.

• Open the source deployment console, and then navigate to the Path Connections in the left
navigation menu.
• Click Add Path Connection, and then complete the following:
• Credential Alias: Enter an alias.
• User ID: Enter the name of the user created in step 2.
• Password and Verify Password: Enter the password associated with this user .
• Click Submit.

39
UserId: oggadmin-amsterdam and its login Password should be entered.

40
➢ Create Distribution Path in Italy (Source)

In GoldenGate-Milan Deployment Console:

Click on (+) sign

Click Next.

41
42
• Click on Create Path which creates Distribution path 1st and then run it . If successful

43
 ➢ Verify Receiver Path in Amsterdam

Note: Automatically created on the target when the distribution path is established
from the source, so no manual receiver path configuration is needed.

Click on (+)

Above indicates successful connection between source GG and Target GG.

44
 ➢ Test Replication:
• Insert Data in Italy DBCS

• Target:

From above Source and Target DBCS have same number of rows in them.

45
Now we will insert a new row into source (Italy) for
Table: ICC_NEWZEALAND_PLAYERS
And check if it replicates on Target (Amsterdam)

• Source (Italy)

Login to OCI GG Console with username: oggadmin-milan (source)

And on target with username: oggadmin-amsterdam(target)

Here on source OCI GG Console we see a new row inserted to mentioned Table:
ICC_NEWZEALAND_PLAYERS

46
 • On Target OCI GG Console:

Here we can see that the inserted row on source has been replicated to Target
and visible in Replicat.
Let us verify from backend as well on source and target to confirm.

• Source:

47
 • Target:

Here in above screenshot, we can notice the difference clearly that row count for
ICC_NEWZEALAND_PLAYERS has changed.
This confirms data insertion from backend as well.

• Source:

48
 • Target:

➢ Update Replication:
• Source (Italy):

We will update the 1st one highlighted in red and see how the update replication
goes.

49
 • Source OCI GG Console:

Row has been updated on source:

• Target (Amsterdam):
Here on Target OCI GG Console, we can see as below.

The row which was updated on source has been replicated to Target side.
Let’s verify in the backend.

50
 ➢ Delete Replication:
• Here we will see how delete replication works.
Source (Italy):
Before Deletion:

After Deletion:

Here we can see entry for the player “Ruturaj Gaikwad” from table
CRICKET.ICC_INDIA_PLAYERS has been deleted.

51
 • Source OCI GG Console.

Let’s verify the same on Target.

Target (Amsterdam):

• Target OCI GG Console:

52
 • Backend:

From above we confirm that deletion of record on source has been replicated to
target dbcs as well.

➢ Bulk deletes on source:

53
All players which have been deleted are no longer visible on source.
• Source OCI GG Console.

• Target:
• OCI GG console:

54
 • Backend:

From Above we can confirm that mentioned rows have been deleted on target as
well as a part of replication.

This completes the activity and uni-directional replication using OCI GG

Microservices.

➢ Reference:
➢ https://docs.oracle.com/en-us/iaas/goldengate/
➢ https://docs.oracle.com/en/learn/oracle-gg-db/index.html#introduction

55