Linking Oracle GoldenGate Classic Architecture to Oracle GoldenGate Microservices Architecture

In my last post I covered how to connect the microservices architecture to the classic architecture (here). For this post, I want to show you how to connect the GoldenGate Classic Architecture to the new GoldenGate Microservices Architecture.

You many be asking yourself, why do I want to do this? The answer is quite simple. At the current moment and time, there is no upgrade path to move from Classic to Microservices. This is due to the changes in architecture design for remote administration. If you want to make the leap to Microservices though, you can “migrate” to the architecture using this approach. Now this is only one version of migrating to Microservices. I’m calling this one the leap frogging … basically, you can set Microservices up as a target and start replicating to it. Once done and/or nsync, make a new target on the other side using Microservices to complete the configuration.


Before you can do a leap frog migration, you have to get your Classic Architecture to work with Microservices Architecture. In order to do this, you have to connect the Data Pump Extract (Classic Architecture) to the Reciever Service (Microservices Architecture). To keep this post, realtive short, I’m just going to focus on what you need to configured.

Some assumptions on environments:

1. Classic Extract is up and running. Capturing data and shipping it to the local trail location ($OGG_HOME/dirdat)
2. Microservices Architecture installed with at least one deployment. Reciever Services running on a specified port (in this example: 17003)
3. Replicat configured in Microservices Architecture to read remote trail file

Setting Up the Data Pump Extract (Classic Architecture):

At this point, you may have to modify your parameter file or create a new Data Pump Extract. For example purposes, let’s create a new Data Pump Extract.

1. Start GGSCI

2. Add a Data Pump Extract

3. Add remote trail to Data Pump Extract

Note: At this point, notice the remote trail file is not mentioning the “dirdat” directory. This is due to Microservices using a different directory structure for trail files. The Receiver Services will place the remote trail file where it needs to be for the Microservices Architecture.

4. Edit parameter file for the Data Pump Extract

The contents of the parameter file are as follows:

RMTHOST <hostname/IP address>, PORT <reciever service port>

5. Start the Data Pump Extract

After the extract starts, you should see a new path start up in the Reciever Service of the Microservices Architecture. The below image shows you an example of what this may look like.

A couple of things to notice here. The Reciever Service will be named with a default name. And the port number (17003) will highlight what protocol is being used (ogg). This approach will help you get moving towards the Microservices Architecture.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Pardy DBA

ORA-00001: unique constraint (ORA.BLOG_TAGLINE_PK) violated

Martin Widlake's Yet Another Oracle Blog

Oracle performance, Oracle statistics and VLDBs


Heli's thoughts on Database Designing, Oracle SQL Developer Data Modeler, User Groups etc.

Julian Dontcheff's Database Blog

The good DBA is one who learns from his mistakes, the best DBA is one who learns from other DBA's mistakes

Martins Blog

Trying to explain complex things in simple terms

The Data Warrior

Changing the world, one data model at a time. How can I help you?

Maaz Anjum's Blog

A life yet to be lived...

Stuff that interests me, if not you!

Uwe Hesse

about Database Technology

%d bloggers like this: