Preamble

Oracle made it clear: Microservices Architecture (MA) for Oracle GoldenGate is the strategy of the company. Classic Architecture for Oracle GoldenGate is deprecated in 21.1.

Classic architecture not to mess with classic extract (versus integrated extract) that is deprecated in GoldenGate 18c and desupported with GoldenGate 21c.

Classic architecture is something we have already seen a long time back. Let now see what has changed with this MA architecture.

Despite the fact that Microservices Architecture is the strategic direction of the product and a mandatory step forward there are also other benefits:

• Easier upgrade with deployments that can just change their OGG_HOME
• HTML 5 WebUI & Rest API (ggsci equivalent still available with Admin Client tool)
• More Secure with WSS (Secure Web Socket)

I’m using Oracle Linux 8.7 and GoldenGate Microservices Architecture (MA) 21.3. I will have two distinct multitenant databases in 21c (21.11) (with orcl1 and orcl2 sids) with each a pluggable database database called pdb1 (supported database release with GoldenGate 21c are 11.2.0.4, 12.1.0.2, 19c and 21c). No doubt 23c will come soon…

Remark:
Worth mentioning that even if I have used GoldenGate 21c, this is an innovation release and same as for Oracle database for production platforms it is best to use 19c that is a Long Term Support (LTS) release.

Oracle is proposing two distinct deployment architecture with GoldenGate the Hub/Spoke architecture and the Mesh architecture.

The Hub (or Hub/Spoke) architecture is simply a central server where you install GoldenGate and you connect remotely to the target and sources databases (SQL*Net in the case of Oracle database, can be JDBC or ODBC). This is more to be used at the datacenter perimeter when the distances are small. The trail files will be located on your Hub GoldenGate server. The management is most simple:

Remark:
Unfortunately this is not a nice and elegant way to reduce licensing as you still have to license your source and target server with GoldenGate…

The Mesh is more for moving data on long distances by using WSS protocol between GoldenGate deployments. In this architecture you have a GoldenGate deployment close to each source and target databases, not to say directly onto the source and target systems:

GoldenGate Microservices Architecture installation

On Oracle Software Delivery Cloud web site (https://edelivery.oracle.com/) you have a bunch of available zip files. As I plan to test replication from Oracle to Oracle the one I target is V1011471-01.zip in below list:

I have also downloaded Patch 35577874 to move to GoldenGate MA 21.11.

Once again Oracle has made it super easy. On the Critical Patch Updates, Security Alerts and Bulletins web page (https://www.oracle.com/security-alerts/) when trying to download latest Release Update for GoldenGate MA I have been redirected to Primary Note for Oracle GoldenGate Core Product Patch Sets (Doc ID 1645495.1).

From this note I have been redirected to a GoldenGate MA 21.10 specify note (strangely the note for 21.11 is not yet available) called Oracle GoldenGate 21.10.0.0.0 Patch Set Availability (Doc ID 2947708.1). And from this note you can download directly Oracle GoldenGate 21.10.0.0.0 Microservices for Oracle (Complete Install). In other words, instead of installing 21.3 from Oracle edelivery you can directly start with 21.10. Even if 21.11 has been released I have not found as the time of writing this blog post a complete binaries zip for 21.11…

Unzip the zip file and execute runInstaller (/tmp/fbo_ggs_Linux_x64_Oracle_services_shiphome/Disk1/runInstaller) and the installation with OUI is straightforward…

I have then downloaded RU 21.11, unzip p35577874_2111000OGGRU_Linux-x86-64.zip file. Installation is as simple as (you also need to download latest OPatch with 6880880 patch number):

opatch prereq CheckConflictAgainstOHWithDetail -ph ./
opatch apply

GoldenGate Microservices Architecture deployment configuration

Once the binaries have been installed you need to create a deployment using oggca.sh located in $OGG_HOME/bin directory.

Service Manager directory must not be in GoldenGate Home directory (OGG_HOME), the port is totally up to you:

Add a new GoldenGate deployment:

It is highly important here to put the correct GoldenGate home (OGG_HOME):

Choose the new GoldenGate deployment directory (separated from Goldengate Home):

Fill in the TNS_ADMIN directory manually:

Choose a web interface administrator account and passord (ggsca name is coming from Oracle official documentation):

For this trial I’m not bothering myself with in transit encryption but in a production environment it must be activated:

Fill the administrative ports and the datastore directory:

Default GoldenGate replication schema, can be changed afterwards:

Can finally click finish to create a new deployment:

You can now go with a web browser on administrative port you have chosen:

At the end of the installation the deployment is automatically started but if you wish to start (or stop it) manually you have a bunch of available scripts:

[oracle@server1 ~]$ export OGG_HOME=/u01/app/oracle/product/21.0.0/gghome_1
[oracle@server1 ~]$ export OGG_ETC_HOME=/u01/gg_deployments/ggsm01/etc
[oracle@server1 ~]$ export OGG_VAR_HOME=/u01/gg_deployments/ggsm01/var
[oracle@server1 ~]$ /u01/gg_deployments/ggsm01/bin/startSM.sh
Starting Service Manager process...
Service Manager process started (PID: 8570)
[oracle@server1 ~]$ ps -ef | grep oracle
root        5585    4752  0 17:52 pts/0    00:00:00 su - oracle
oracle      5586    5585  0 17:52 pts/0    00:00:00 -bash
oracle      8570       1 17 17:55 ?        00:00:00 /u01/app/oracle/product/21.0.0/gghome_1/bin/ServiceManager --quiet
oracle      8588    8570 32 17:55 ?        00:00:00 /u01/app/oracle/product/21.0.0/gghome_1/bin/pmsrvr --config /u01/deployments/ggsm01/var/temp/gg01-pmsrvr-config.dat --force --quiet
oracle      8590    8570 28 17:55 ?        00:00:00 /u01/app/oracle/product/21.0.0/gghome_1/bin/distsrvr --config /u01/deployments/ggsm01/var/temp/gg01-distsrvr-config.dat --force --quiet
oracle      8592    8570 25 17:55 ?        00:00:00 /u01/app/oracle/product/21.0.0/gghome_1/bin/adminsrvr --config /u01/deployments/ggsm01/var/temp/gg01-adminsrvr-config.dat --force --quiet
oracle      8594    8570 32 17:55 ?        00:00:00 /u01/app/oracle/product/21.0.0/gghome_1/bin/recvsrvr --config /u01/deployments/ggsm01/var/temp/gg01-recvsrvr-config.dat --force --quiet
oracle      8607    5586  0 17:55 pts/0    00:00:00 ps -ef
oracle      8608    5586  0 17:55 pts/0    00:00:00 grep --color=auto oracle

Remark:
There is also a stopSM.sh is same directory…

GoldenGate Microservices Architecture database preparation

If you are in a multitenant architecture (and you should as the classic one will gone with 23c) you can either create a global account (c##ggadmin) or one account er pluggable database (ggadmin). I rate a bit more clearer to have a global account and centrally manage all the potential pluggable database replication from a single account.

Instance global configuration (your databases must be in ARCHIVELOG mode) on source and target:

ALTER SYSTEM SET enable_goldengate_replication=TRUE;
ALTER SYSTEM SET streams_pool_size=1g;
ALTER DATABASE force logging;
ALTER DATABASE ADD supplemental LOG data;

Creating the c##ggadmin global account on source:

CREATE USER c##ggadmin IDENTIFIED BY "secure_password" container=ALL DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
ALTER USER c##ggadmin quota unlimited ON users;
GRANT CONNECT TO c##ggadmin container=ALL;
GRANT CREATE VIEW TO c##ggadmin container=ALL; -- Heatbeat table
GRANT SELECT ANY dictionary TO c##ggadmin container=ALL; -- Heatbeat table
GRANT CREATE TABLE TO c##ggadmin container=ALL; -- Checkpoint table
GRANT RESOURCE TO c##ggadmin container=ALL; -- Heartbeat table (sequence)
EXEC dbms_goldengate_auth.grant_admin_privilege(grantee => 'c##ggadmin', privilege_type => 'CAPTURE', container => 'ALL');

Creating the c##ggadmin global account on target (privilege_type can be set to * to have same script everywhere and/or set bidirectional replication):

CREATE USER c##ggadmin IDENTIFIED BY "secure_password" container=ALL DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
ALTER USER c##ggadmin quota unlimited ON users;
GRANT CONNECT TO c##ggadmin container=ALL;
GRANT CREATE VIEW TO c##ggadmin container=ALL;
GRANT SELECT ANY dictionary TO c##ggadmin container=ALL; -- Heatbeat table
GRANT CREATE TABLE TO c##ggadmin container=ALL;
GRANT RESOURCE TO c##ggadmin container=ALL; -- Heartbeat table (sequence)
GRANT INSERT ANY TABLE TO c##ggadmin container=ALL; -- Replicate DML, individual grants can be given per object but painful
GRANT UPDATE ANY TABLE TO c##ggadmin container=ALL; -- Replicate DML, individual grants can be given per object but painful
GRANT DELETE ANY TABLE TO c##ggadmin container=ALL; -- Replicate DML, individual grants can be given per object but painful
EXEC dbms_goldengate_auth.grant_admin_privilege(grantee => 'c##ggadmin', privilege_type => 'APPLY', container => 'ALL');

Remark:
Building these grant scripts with the least privilege approach is clearly not a piece of cake. Often in Oracle literature you will see people directly granting DBA to GoldenGate account for practicality. I have here tried to grant strict minimum but in some edge cases you would like to treat it might not be sufficient…

I create an applicative account and a test table on source and target pluggable database (pdb1):

CREATE USER app1 IDENTIFIED BY secure_password
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
 
GRANT CONNECT, RESOURCE TO app1;
 
ALTER USER app1 quota unlimited ON users;
 
CREATE TABLE app1.test1 (
val NUMBER NOT NULL,
descr VARCHAR2(50),
CONSTRAINT test1_pk PRIMARY KEY (val) enable);
 
INSERT INTO app1.test1 VALUES (1,'One');
 
COMMIT;
 
SELECT * FROM app1.test1 ORDER BY val;

On GoldenGate WebUI configuration page create all the credentials to connect to your source and target container(s) and pluggable database with c##ggadmin account:

If you connect on source pluggable database you are able to configure checkpoint table and heartbeat. You can also add TRANDATA information on the table you plan to replicate (app1.test1) in my case:

GoldenGate Microservices Architecture extract and replicat creation

Extract

With the new GoldenGate Microservices Architecture and its webUI the creation of extract and replicat processes is really much easier. Just click on the plus sign along Extracts:

Then choose few parameter as well as source_cdb credentials we created above:

Customize parameter on third page with below script (taken from GoldenGate Quickstarts guide):

EXTRACT ext01
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL ext01/ex
SOURCECATALOG PDB1
DDL INCLUDE MAPPED
TABLE app1.test1;

Replicat

Click on the plus sign along Replicats and choose a Integrated Replicat with below option. The credential used must be the pluggable target one:

Remark:
The Trail Name and Trail Subdirectory must be exactly the same as for the extract parameter as here we are not in a distribution of trail files. In a Hub architecture there is only one trail directory, to simplify, and extract and replicat are using the exact same files. Directory of trail files are located in /u01/gg_deployments/ggdd01/var/lib/data. There is a subdirectory with extract name containing trail file starting by trail name you have chosen.

Customize parameter on third page with below script (taken from GoldenGate Quickstarts guide):

REPLICAT rep01
USERIDALIAS target_pdb1 DOMAIN OracleGoldenGate
DDLOPTIONS REPORT
SOURCECATALOG PDB1
MAP app1.*, TARGET app1.*;

Final result

We get something like:

And obviously when you insert a new row in the pdb1 pluggable database of your source instance it got replicated to pdb1 pluggable database of your target instance.

all the errors I had were on grants given to c##ggadmin account. That’s why most of the time it’s easier to give it DBA privileges…

By clicking on Details of each process you can access to a lot of information about statistics and even changing graphically the parameters…

GoldenGate Microservices Architecture command line client

If you are really nostalgic of the classic architecture or more seriously if you want to build some kind of automatic scripts you have still access to a command line tool with:

[oracle@server1 ~]$ $OGG_HOME/bin/adminclient
Oracle GoldenGate Administration Client for Oracle
Version 21.11.0.0.0 OGGCORE_21.11.0.0.0OGGRU_PLATFORMS_230714.2015
 
Copyright (C) 1995, 2023, Oracle and/or its affiliates. All rights reserved.
 
Oracle Linux 7, x64, 64bit (optimized) on Jul 14 2023 21:58:01
Operating system character set identified as UTF-8.
 
OGG (not connected) 1> connect http://192.168.56.101:9101 deployment gg01 as ggsca
Password for 'ggsca' at 'http://192.168.56.101:9101/gg01':

The information I have used to connect have all been specified when I have installed the product…

Then you have the basic bunch of commands available same as you had with classic architecture (help command for the list)…

Example:

OGG (http://192.168.56.101:9101 gg01) 3> info all
Program     Status      Group       Type             Lag at Chkpt  Time Since Chkpt
 
EXTRACT     RUNNING     EXT01       INTEGRATED       00:00:00      00:00:07
REPLICAT    RUNNING     REP01       INTEGRATED       00:00:00      00:00:00

References

• Data Replication using GoldenGate 21.3 Microservices for Oracle
• #GoldenGate Classic vs Microservices Architecture
• Oracle GoldenGate Migration Utility To Migrate From Classic To Microservices Architecture (Doc ID 2822450.1)
• Microservices Architecture Specific Programs and Utilities (Doc ID 2637446.1)
• https://www.youtube.com/@oraclegoldengate
• Set Up Data Replication with Oracle GoldenGate Microservices Architecture

About Post Author

Yannick Jaquier

administrator

Find more about me on social media.

See author's posts