MAA GGMicroservices On RAC
MAA GGMicroservices On RAC
Oracle GoldenGate
Microservices Architecture
with Oracle Real Application
Clusters Configuration Best
Practices
1 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Disclaimer
This document in any form, software or printed matter, contains proprietary information that is the exclusive property
of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle
software license and service agreement, which has been executed and with which you agree to comply. This
document and information contained herein may not be disclosed, copied, reproduced or distributed to anyone
outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it
be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the
implementation and upgrade of the product features described. It is not a commitment to deliver any material, code,
or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing
of any features or functionality described in this document remains at the sole discretion of Oracle. Due to the nature
of the product architecture, it may not be possible to safely include all features described in this document without
risking significant destabilization of the code.
2 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Purpose statement 2
Disclaimer 2
Introduction 5
Configuration Overview 5
Oracle GoldenGate 5
Oracle Real Application Clusters 6
Oracle Clusterware 7
Oracle Grid Infrastructure Agents 7
Oracle Database File System (DBFS) 7
Oracle Advanced Cluster File System (ACFS) 7
Configuration Best Practices 8
Step 1: Configure the Oracle Database for Oracle GoldenGate 8
Step 2: Create the Database Replication Administrator User 8
Step 3: Create the Database Services 8
Step 4: Set Up a File System on Oracle RAC 9
Oracle Database File System (DBFS) 9
Oracle Advanced Cluster File System (ACFS) 11
Step 5: Install Oracle GoldenGate 13
Step 6: Create the Oracle GoldenGate Deployment 13
Step 7: Oracle Clusterware Configuration 17
Step 8: Configure NGINX Reverse Proxy 22
Step 9: Create Oracle Net TNS Alias for Oracle GoldenGate Database Connections 23
Step 10: Configure Oracle GoldenGate Processes 24
Extract Configuration 24
Distribution Path Configuration 26
Replicat Configuration 28
Step 11: Configure Autostart of Extract and Replicat Processes 29
Summary of Recommendations when Deploying n Oracle RAC 31
References 32
Appendix A: Troubleshooting Oracle GoldenGate on Oracle RAC 33
1. XAG log file 33
2. XAG GoldenGate instance trace file 33
3. CRS trace file 34
4. GoldenGate deployment log files 35
5. GoldenGate report files 35
Example Configuration Problems 36
1. Incorrect parameter settings in the mount-dbfs.conf file 36
3 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
4 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
This technical brief is applicable for configuring Oracle GoldenGate Microservices Architecture with on-premises
systems, including Oracle Exadata. A separate technical brief will cover implementation with Exadata
Cloud@Customer and Exadata Cloud Services.
Oracle GoldenGate is instrumental in Oracle RAC configurations for many reasons, including the following:
• To support Oracle Platinum MAA reference architecture resulting in zero or near zero database and
application downtime for planned and unplanned outages. Refer to Oracle MAA Reference Architectures or
Oracle Exadata MAA - Platinum Tier Focused Presentation
• To migrate to an Oracle Database with minimal, or zero downtime
• To implement a near real-time data warehouse or consolidated database on Oracle RAC, sourced from
various, possibly heterogeneous, source databases, populated by Oracle GoldenGate
• To capture data from an OLTP application running on Oracle RAC to support further downstream
consumption, such as middleware integration
Configuration Overview
This section introduces Oracle GoldenGate Microservices Architecture, Oracle RAC, Oracle Clusterware, Oracle
Database File System (DBFS), and Oracle Advanced Cluster File System (ACFS). For more information about these
features, see the References section at the end of this technical brief.
Oracle GoldenGate
Oracle GoldenGate provides real-time, log-based change data capture and delivery between homogenous and
heterogeneous systems. This technology enables you to construct a cost-effective and low-impact real-time data
integration and continuous availability solution.
Oracle GoldenGate replicates data from committed transactions with transaction integrity and minimal overhead on
your existing infrastructure. The architecture supports multiple data replication topologies such as one-to-many,
many-to-many, cascading, and bidirectional. Its wide variety of use cases includes real-time business intelligence;
query offloading; zero-downtime upgrades and migrations; and active-active databases for data distribution, data
synchronization, and high availability.
Oracle GoldenGate Microservices Architecture provides REST-enabled services. The REST-enabled services provide
remote configuration, administration, and monitoring through HTML5 web pages, command line interfaces, and
APIs. Figure 1 shows the Oracle GoldenGate Microservices Architecture referenced throughout this technical brief.
Recommended Oracle GoldenGate 21c (and higher releases) introduces unified build support so a single software
installation supports capturing and applying replicated data to multiple major Oracle Database versions (11g Release
2 to 21c). This is possible because an Oracle GoldenGate installation includes the required Oracle Database client
libraries without requiring a separate database ORACLE_HOME installation.
5 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
More information about Oracle GoldenGate Microservices Architecture can be found in the Oracle GoldenGate
documentation central hub by referencing the highest production GoldenGate release:
https://docs.oracle.com/en/middleware/goldengate/core/index.html
This technical brief is solely based on Oracle GoldenGate 21c. The latest version of Oracle GoldenGate can be
downloaded from:
http://www.oracle.com/technetwork/middleware/goldengate/downloads/index.html
For information about configuring Oracle GoldenGate Classic Architecture with Oracle RAC, see the “Oracle
GoldenGate with Oracle Real Application Clusters Configuration” technical brief:
http://www.oracle.com/technetwork/database/features/availability/maa-goldengate-rac-2007111.pdf
6 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Oracle RAC and Oracle Clusterware allow Oracle Database to run any packaged or custom application across a set of
clustered servers. This capability provides continual database service uptime for node and instance failures, most
planned maintenance activities, and for Oracle RAC expansion. If an Oracle RAC clustered node or instance fails, the
Oracle Database service continues running on the surviving nodes and instances. When more processing power is
needed, you can add another node without interrupting user access to the database or data.
Oracle Clusterware
Oracle Clusterware is a cluster manager that is designed specifically for Oracle Database. In an Oracle RAC
environment, Oracle Clusterware monitors all Oracle resources (such as database instances and listeners). If a failure
occurs, Oracle Clusterware automatically attempts to restart the failed resource. During outages, Oracle Clusterware
relocates the processing performed by the inoperative resource to a backup resource. For example, if a node fails,
then Oracle Clusterware relocates the database services used by the application to surviving RAC nodes and instances
in the RAC cluster.
The Oracle Grid Infrastructure Agents provide pre-defined Oracle Clusterware resources for Oracle GoldenGate,
Siebel, Oracle PeopleSoft, JD Edwards, and Oracle WebLogic Server, as well as Apache and MySQL applications. Using
the agent for Oracle GoldenGate simplifies the creation of dependencies on the source/target database, the
application VIP, and the file system (ACFS or DBFS) mount point. The agent command line utility (AGCTL) is used to
start and stop Oracle GoldenGate and can also be used to relocate Oracle GoldenGate between the nodes in the
cluster.
With DBFS, the server is the Oracle Database. Files are stored as SecureFiles LOBs. PL/SQL procedures implement file
system access primitives such as create, open, read, write, and list directory. The implementation of the file system in
the database is called the DBFS SecureFiles Store. The DBFS SecureFiles Store allows users to create file systems that
can be mounted by clients. Each file system has its own dedicated tables that hold the file system content.
Oracle ACFS leverages Oracle Clusterware for cluster membership state transitions and resource-based high
availability. Oracle ACFS is bundled into the Oracle Grid Infrastructure (GI) allowing for integrated optimized
management of databases, resources, volumes, and file systems.
7 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
When adding Extract or Replicat processes, it is important to recalculate, and configure the new streams pool size
requirement.
For further information on preparing the database for Oracle GoldenGate, refer to the Using Oracle GoldenGate with
Oracle Database Guide at
https://docs.oracle.com/en/middleware/goldengate/core/21.3/oracle-db/preparing-database-oracle-
goldengate.html#GUID-E06838BD-0933-4027-8A6C-D4A17BDF4E41
https://docs.oracle.com/en/middleware/goldengate/core/21.3/oracle-db/establishing-oracle-goldengate-
credentials.html#GUID-F9EBB989-E22F-4355-BE60-40F957B8515E
For a multitenant source database, GoldenGate Extract must be configured to connect to a user in the root container
database, using a c## account. For a multitenant target database, a separate GoldenGate administrator user is
needed for each PDB that a Replicat applies data to. For further details on creating a GoldenGate Administrator in and
Oracle Multitenant Database, refer to the Using Oracle GoldenGate with Oracle Database guide at
https://docs.oracle.com/en/middleware/goldengate/core/21.3/oracle-db/configuring-oracle-goldengate-
multitenant-container-database-1.html#GUID-0B0CEB35-51C6-4319-BEE1-FA208FF4DE05
8 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Create the service using the following command, as the oracle user.
$ srvctl add service -db <db_name> -service <service name> -preferred <instance_1>
-available <instance_2, instance_3 etc.> -pdb <PDB name>
Example:
$ srvctl add service -db ggdb -service oggserv_pdb -preferred ggdb1 -available ggdb2
–pdb GGPDB01
Refer to the Real Application Clusters Administration and Deployment Guide for further details on creating a database
service at https://docs.oracle.com/en/database/oracle/oracle-database/19/racad/index.html.
If Oracle GoldenGate will be configured along with Oracle Data Guard, the recommended file system is DBFS. DBFS is
contained in the database protected by Data Guard, and can be fully integrated with XAG. In the event of a Data Guard
role transition, the file system can be automatically mounted on the new primary server, followed by automated
startup of Oracle GoldenGate. This is currently not possible with ACFS, because it is not part of the Oracle Data Guard
configuration.
Follow instructions in My Oracle Support note 869822.1 to install the required FUSE libraries if they are not already
installed.
Use the instructions in My Oracle Support note 1054431.1 to configure the database, tablespace, database user,
tnsnames.ora Oracle Net connection alias, and permissions on source or target GoldenGate environments required
for DBFS.
NOTE: When using an Oracle Multitenant Database, the DBFS tablespace MUST be created in a Pluggable Database
(PDB). It is recommended that you use the same PDB that the GoldenGate Extract or Replicat processes are connecting
to, allowing DBFS to use the same database service, created above in step 2, for its database dependency.
9 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus dbfs_user/dbfs_password@<database_tns_alias>
SQL> start dbfs_create_filesystem dbfs_gg_tbs goldengate
Follow the instructions in My Oracle Support note 1054431.1 for configuring the newly created DBFS file system so
that the DBFS instance and mount point resources are automatically started by Cluster Ready Services (CRS) after a
node failure, with the following DBFS configuration and script file modifications.
MOUNT_OPTIONS=allow_other,direct_io,failover,nolock
The failover option forces all file writes to be committed to the DBFS database in an IMMEDIATE WAIT mode.
This prevents data getting lost when it has been written into the dbfs_client cache but not yet written to the
database at the time of a database or node failure.
The nolock mount option is required if you are using Oracle Database 18c or later versions, due to a change in
the DBFS file locking, which can cause issues for GoldenGate processes after a RAC node failure when a file is
currently locked.
If you are using a dbfs_client from Oracle Database 12c Release 2 (12.2), make sure you have applied the
latest release update that includes the fix for bug 27056711. Once the fix has been applied, the MOUNT_OPTIONS
should also include the nolock option.
2. Modify the mount-dbfs.sh script to force unmounting of DBFS when the CRS resource is stopped.
Change two occurrences of:
$FUSERMOUNT -u $MOUNT_POINT
To the following:
3. When registering the resource with Oracle Clusterware, be sure to create it as a cluster_resource instead of a
local_resource as specified in the My Oracle Support note. The reason for using cluster_resource is so
the file system can only be mounted on a single node at one time, preventing mounting of DBFS from concurrent
nodes, which creates the potential for concurrent file writes, causing file corruption problems.
Make sure to use the database service name created in a previous step for the DBFS service dependency.
Example:
DBNAME=ggdb
DEPNAME=ora.$DBNAME.oggserv.svc
10 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Once the DBFS resource has been created, the file system should be mounted and tested.
After the file system is mounted, create the directory for storing the GoldenGate files.
$ cd /mnt/dbfs/goldengate
$ mkdir deployments
NOTE: Leave the shared file system mounted. It is required for creating the GoldenGate deployment in a later step.
Create a single ACFS file system for storing the Oracle deployment files.
It is recommended that you allocate enough trail file disk space to permit storage of up to 12 hours of trail files. Doing
this provides sufficient space for trail file generation should a problem occur with the target environment that
prevents it from receiving new trail files. The amount of space needed for 12 hours can only be determined by testing
trail file generation rates with real production data.
1. Create the file system using ASMCMD as the Oracle ASM administrator user.
ASMCMD [+] > volcreate -G datac1 -s 1200G ACFS_GG
Note: Modify the file system size according to the determined size requirements.
Redundancy: MIRROR
Stripe Columns: 8
Stripe Width (K): 1024
11 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
2. Create the CRS resource for the newly created ACFS file system, if not already created.
Check to see if the file system resource was already created.
If not already created, create the ACFS mount point on all RAC nodes.
# mkdir -p /mnt/acfs_gg
Create the file system resource as the root user. Due to the implementation of distributed file locking on ACFS,
unlike DBFS, it is acceptable to mount ACFS on more than one RAC node at any one time.
Create the ACFS resource using srvctl from the Oracle Grid Infrastructure ORACLE_HOME.
To verify the currently configured ACFS file systems, use the following command to view the file system details.
The CRS resource that is created is named using the format ora.diskgroup_name.volume_name.acfs. Using
the above file system example, the CRS resource is called ora.datac1.acfs_gg.acfs.
To see all ACFS file system CRS resources that currently exist, use the following command.
$ cd /mnt/acfs_gg
$ mkdir deployments
Refer to the Oracle Automatic Storage Management Administrator’s Guide for more information about ACFS:
https://docs.oracle.com/en/database/oracle/oracle-database/19/ostmg/index.html
NOTE: Leave the shared file system mounted. It is required for creating the GoldenGate deployment in a later step.
http://www.oracle.com/technetwork/middleware/goldengate/downloads/index.html
Install the Oracle GoldenGate software locally on all nodes in the Oracle RAC configuration that will be part of the
GoldenGate configuration. Make sure the installation directory is the identical on all nodes.
https://docs.oracle.com/en/middleware/goldengate/core/21.3/coredoc/index.html
There are two limitations that currently exist with Oracle GoldenGate and XAG:
1. A Service Manager that is registered with XAG can only manage a single deployment. If multiple deployments are
required, each deployment must use their own Service Manager. Oracle GoldenGate release 21c simplifies this
requirement because it uses a single deployment to support Extract and Relicat processes connecting to different
versions of the Oracle Database.
2. Each Service Manager registered with XAG must belong to separate OGG_HOME software installation directories.
Instead of installing Oracle GoldenGate multiple times, the recommended approach is to install Oracle
GoldenGate one time, and then create a symbolic link for each Service Manager OGG_HOME.
Example:
$ echo $OGG_HOME
/u01/oracle/goldengate/gg21c_MS
$ ln –s /u01/oracle/goldengate/gg21c_MS /u01/oracle/goldengate/gg21c_MS_ggnorth
$ export OGG_HOME=/u01/oracle/goldengate/gg21c_MS_ggnorth
$ $OGG_HOME/bin/oggca.sh
13 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Recommendations for creating the GoldenGate deployment in the Oracle GoldenGate Configuration Assistant are as
follows.
1. In Service Manager Options, specify the following for the creation of a new Service Manager.
a. In the Service Mnaager Details pane, select ‘Create New Service Manager’.
b. Enter the ‘Service Manager Deployment Home’ location on the shared DBFS or ACFS file system.
c. Select to ‘Integrate with XAG’
d. In the Service Manager Connection Details pane, specify localhost in the Listening
hostname/address field. Using localhost allows the deployment to be started on all of the RAC
nodes without the need for a Virtual IP address (VIP).
e. Enter the port number in Listening port
2. In Deployment Directories, specify the Deployment home directory on the shared DBFS or ACFS file system:
14 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
5. In Port Settings, if the Management Pack for Oracle GoldenGate has been licensed, select ‘Enable Monitoring’
to use the performance metric server using either Berkeley Database (BDB) or Lightening Memory Database
(LMDB).
15 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
For both BDB and LMDB Metrics Service DataStore types, set the ‘Metrics Service DataStore home’ directory
to a local directory that exists on all RAC nodes. For example:
/u01/oracle/goldengate/datastores/<deployment name>
Continue through the Oracle GoldenGate Configuration Assistant until the deployment is created.
After the deployment has been created, if you are using DBFS for the shared file system and the database version is
lower than Oracle Database Release 21c (21.3), run the following commands to move the GoldenGate deployment
temp directory from DBFS to local storage.
$ cd /mnt/dbfs/goldengate/deployments/ggnorth/var
$ mkdir –p /u01/oracle/goldengate/deployments/ggnorth
$ mv temp /u01/oracle/goldengate/deployments/ggnorth
$ ln -s /u01/oracle/goldengate/deployments/ggnorth/temp temp
16 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
When using Oracle GoldenGate Microservices Architecture you MUST use XAG version 10.2 or later.
The latest agent software is available for download from the following location:
http://www.oracle.com/technetwork/database/database-technologies/clusterware/downloads/xag-agents-
downloads-3636484.html
Install the XAG standalone agent outside of the Oracle Grid Infrastructure home directory. XAG must be installed
in the same directory on all RAC nodes in the cluster where Oracle GoldenGate is installed.
For example, as the Oracle Grid Infrastructure user, the default of oracle:
Add the location of the newly installed XAG software to the PATH variable so that the location of agctl is known
when the oracle user logs on to the machine.
$ cat .bashrc
export PATH=/u01/oracle/xag/bin:$PATH
NOTE: It is important to make sure that the XAG bin directory is specified BEFORE the Grid Infrastructure bin directory,
to ensure the correct agctl binary is found. Set this location in the oracle user environment to take effect at time of
logging on, such as in the .bashrc file when the Bash shell is in use.
The VIP is a cluster resource that Oracle Clusterware manages. The VIP is assigned to a cluster node and is
automatically migrated to another node in the event of a node failure.
There are two pieces of information needed before creating the application VIP:
• The network number, which can be identified using the following command.
$ crsctl status resource -p -attr ADDRESS_TYPE,NAME,USR_ORA_SUBNET -w "TYPE =
ora.network.type" |sort | uniq
ADDRESS_TYPE=IPV4
NAME=ora.net1.network
17 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
The net1 in NAME=ora.net1.network indicates that this is network 1, and it is of type IPV4.
• The IP address for the new Application VIP, provided by your system administrator. This IP address must be
in the same subnet of the cluster environment as determined above.
The VIP will be created in the next step, when configuring the Oracle Grid Infrastructure Agent.
To register Oracle GoldenGate Microservices Architecture with XAG use the following command format.
Where:
--gg_home specifies the location of the Oracle GoldenGate software. Specify the OGG_HOME symbolic link for
the OGG_HOME if registering multiple Service Managers (see Step 6: Create the Oracle GoldenGate Deployment).
--config_home specifies the GoldenGate Service Manager deployment configuration home directory.
--var_home specifies the GoldenGate Service Manager deployment variable home directory.
--oracle_home specifies the location of the Oracle database libraries that are included as part of Oracle
GoldenGate 21c and later releases. Example: $OGG_HOME/lib/instantclient
--user specifies the name of the operating system user that owns the GoldenGate deployment.
--group specifies the name of the operating system group that owns the GoldenGate deployment.
--network specifies the network subnet for the VIP, determined above in step 7.2.
18 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
--filesystems specifies the DBFS or ACFS CRS file system resource that must be mounted before the
deployment is started.
--db_services specifies the ora.<database>.<service_name>.svc service name that was created in the previous
step. If using Oracle Multitenant Database, specify the PDB database service for Replicat, or the CDB database
service for an Extract. If using both Replicat and Extract, specify both services names, separated by a comma.
--use_local_services specifies that the GoldenGate instance must be co-located on the same RAC node
where the db_services service is running.
--nodes specifies which of the RAC nodes this GoldenGate instance can run on. If GoldenGate is configured to
run on any of the RAC nodes in the cluster, this parameter should still be used to determine the preferred order of
nodes to run Oracle GoldenGate.
Notes:
• The GoldenGate instance registration with XAG MUST be run as the root user.
• The user and group parameters are mandatory because the GoldenGate registration with XAG is run as
the root user.
Where:
19 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
RAC cluster, using ACFS, with an application VIP running on a subset of the nodes in the cluster.
Where:
20 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Below are some example agctl commands that are used to manage the GoldenGate deployment with XAG.
To start the GoldenGate deployment, and all Extract/Replicat processes that have been configured to autostart
(instructions in a later step):
21 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
http://www.oracle.com/technetwork/database/database-technologies/clusterware/downloads/xag-agents-
downloads-3636484.html
NOTE: When using CA Signed Certificates with NGINX, make sure the NGINX ssl_certificate parameter points to
a certificate file that contains the certificates in the correct order of CA signed certificate, intermediate certificate and root
certificate.
Oracle Clusterware needs to have control over starting the NGINX reverse proxy so that it can be started automatically
before the GoldenGate deployments are started.
The NGINX resource is created with a dependency on the underlying network CRS resource, the name of which can be
determined using the following command:
NAME=ora.net1.network
As the root user, use the following example command to create a Clusterware resource to manage NGINX.
The NGINX resource created in this example run on the named cluster nodes at the same time, specified by
HOSTING_MEMBERS. This is recommended when multiple GoldenGate Service Manager deployments are
configured, and they can independently move between cluster nodes.
Once the NGINX Clusterware resource is created, alter the GoldenGate XAG resources so that NGINX must be started
before the GoldenGate deployments are started.
As the oracle user, modify the XAG resources using the following example commands.
22 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Repeat the above commands for each of the XAG GoldenGate registrations relying on NGINX.
Step 9: Create Oracle Net TNS Alias for Oracle GoldenGate Database Connections
Create a TNS alias on all of the RAC nodes where Oracle GoldenGate may be started to provide local database
connections for the GoldenGate processes when switching between Oracle RAC nodes. Create the TNS alias in the
tnsnames.ora file in the TNS_ADMIN directory specified in the deployment creation.
If the source database is a multitenant database, two TNS alias entries are required: one for the container database
(CDB) and one for the pluggable database (PDB) that is being replicated. For a target multitenant database, the TNS
alias connects the PDB where replicated data is being applied to. The pluggable database SERVICE_NAME should be
set to the database service created in an earlier step (refer Step 1: Create the Database Services).
Below are some example source database TNS alias definitions using the IPC protocol, which must be defined locally
on all RAC nodes.
OGGSOURCE_CDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL=IPC)(KEY=LISTENER))
(CONNECT_DATA =
(SERVICE_NAME = oggserv_cdb)
)
)
OGGSOURCE_PDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL=IPC)(KEY=LISTENER))
(CONNECT_DATA =
(SERVICE_NAME = oggserv_pdb)
)
)
NOTE: When the tnsnames.ora or sqlnet.ora, located in the TNS_ADMIN directory for the GoldenGate deployment, are
modified, the deployment needs to be restarted in order to pick up the changes.
With the GoldenGate deployment created, use the Administration Server home page to create the database
credentials using the above TNS alias names. See Figure 6 below for an example of the database credential creation
using the TNS alias appended to the database user name in the ‘User ID” field.
If the source database is a multitenant database, create database credentials for the CDB and PDB. If the target
database is a multitenant database, create a single credential for the PDB.
23 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Listed below are important configuration details that are recommended for running Oracle GoldenGate Microservices
on Oracle RAC for Extract, Distribution Paths and Replicat processes.
Extract Configuration
1. When creating an Extract using the Oracle GoldenGate Administration Server GUI interface, leave the Trail
SubDirectory parameter blank, so that the trail files are automatically created in the deployment directories
stored on the shared file system. The default location for trail files is the /<deployment
directory>/var/lib/data directory.
In the example shown below, all of the Add Extract Basic Information fields are populated except Trail
Subdirectory:
24 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
2. If you are using DBFS for shared storage, and the deployment var/temp directory was moved to local
storage as described in Step 6: Create the Oracle GoldenGate Deployment, it is recommended that you use
the Extract CACHEMGR parameter to place the temporary cache files on the shared storage.
Create a new directory under the DBFS deployment mount point. For example:
$ mkdir –p /mnt/dbfs/goldengate/deployments/ggnorth/temp_cache
Shown below is an example of how the parameters specified for an integrated Extract with the Oracle
GoldenGate Administration Server GUI looks in the UI.
25 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
More instructions about creating an Extract process are available in the Using Oracle GoldenGate Microservices
Architecture guide at https://docs.oracle.com/en/middleware/goldengate/core/21.3/oracle-db/index.html
Follow the instructions provided in the following video to correctly configure the certificates:
https://apexapps.oracle.com/pls/apex/f?p=44785:112:0::::P112_CONTENT_ID:31380
1. Create a client certificate for the source deployment and add the client certificate to the source deployment
Service Manager. This is not required when using Oracle GoldenGate 21c or higher releases.
2. Download the target deployment server’s root certificate and add the CA certificate to the source deployment
Service Manager.
3. Create a user in the target deployment for the distribution path to connect to.
4. Create a credential in the source deployment connecting to the target deployment with the user created in
the previous step. For example, a domain of GGNORTH_to_GGSOUTH and an alias of PathReceiver.
After configuring the client and server certificates, the following configuration options need to be set correctly, as
shown in Figure 9 below.
1. Change the Generated Source URI specifying localhost for the server name. This allows the distribution
path to be started on any of the Oracle RAC nodes.
2. Set the Target Authentication Method to ‘UserID Alias’ and the Target transfer protocol to wss (secure web
socket). Set the Target Host to the target host name/VIP that will be used for connecting to the target
system along with the Port Number that NGINX was configured with (default is 443). The target host
name/VIP should match the common name in the CA signed certificate used by NGINX.
26 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Replicat Configuration
1. The checkpoint table is a required component for GoldenGate Replicat processes. Make sure that a
checkpoint table has been created in the database GoldenGate administrator (GGADMIN) schema.
The checkpoint table can be created using the Oracle GoldenGate Administration Server GUI, clicking on the
‘+’ button and entering the checkpoint table name in the format of schema.tablename. This is shown in
Figure 10.
Refer to Using Oracle GoldenGate with Oracle Database for more information about creating a checkpoint
table at https://docs.oracle.com/en/middleware/goldengate/core/21.3/oracle-db/configuring-oracle-
goldengate-apply.html#GUID-3DFBE2BE-20C5-48AA-B96A-7697126D77FE
2. When creating a Replicat using the Oracle GoldenGate Administration Server GUI interface, set the Trail
SubDirectory parameter to the location where the distribution path or local Extract are creating the trail files.
3. If a checkpoint table was created previously, select the table name from the Checkpoint Table pulldown list.
Below, in Figure 11, a screenshot shows the Trail SubDirectory and Checkpoint Table prompts.
28 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Using the Oracle GoldenGate Administration Server GUI, create a new profile which can be assigned to each of the
GoldenGate processes. Figure 12 shows the recommended settings.
29 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
After the profile has been created, and set as the default profile, all new GoldenGate processes created are assigned
this profile. For all existing processes, the profile must be assigned to each process. Figure 13 shows an example of
assigning the auto start profile to a GoldenGate process.
30 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
NOTE: When using Oracle GoldenGate Microservices with XAG, it is strongly recommended not to enable the ‘Critical to
deployment health’ flag for any Extract or Replicat processes. Doing so can cause an entire GoldenGate deployment
outage from a single Extract or Replicat failure, and also prevents XAG from being able to restart GoldenGate. Refer to
Appendix A for an example of troubleshooting an outage caused by setting a Replicat to critical.
• Install the latest version of Oracle GoldenGate software locally on each Oracle RAC node, making sure that the
software location is the same on all Oracle RAC nodes.
• Use the Oracle Database File System (DBFS) or Oracle Advanced Cluster File System (ACFS) for the file
system where the GoldenGate files are stored (trail, checkpoint, temporary, report, and parameter files).
• Use the same DBFS or ACFS mount point on all of the Oracle RAC nodes that may run Oracle GoldenGate.
• When creating the GoldenGate deployment, specify either DBFS or ACFS for the deployment location.
• Install Grid Infrastructure agent (XAG) version 10 or later on all Oracle RAC nodes that will run Oracle
GoldenGate.
• Configure the GoldenGate processes to automatically start and restart when the deployment is started.
31 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
32 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Below is a list of important log and trace files, along with their example locations and some example output.
Example:
Example:
33 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Example:
2022-04-18 11:52:38.634 : AGFW:549631744: {1:30281:59063} Agent received the message:
RESOURCE_START[xag.GGNORTH.goldengate 1 1] ID 4098:4125749
2022-04-18 11:52:38.634 : AGFW:549631744: {1:30281:59063} Preparing START command for:
xag.GGNORTH.goldengate 1 1
2022-04-18 11:52:38.634 : AGFW:549631744: {1:30281:59063} xag.GGNORTH.goldengate 1 1
state changed from: OFFLINE to: STARTING
2022-04-18 11:52:38.634 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[start] Executing action script: /u01/oracle/XAG_MA/bin/aggoldengatescaas[start]
2022-04-18 11:52:38.786 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[start] GG agent running command 'start' on xag.GGNORTH.goldengate
2022-04-18 11:52:42.140 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[start] ServiceManager fork pid = 265747
2022-04-18 11:52:42.140 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[start] Waiting for /mnt/dbfs/goldengate/deployments/ggsm01/var/run/ServiceManager.pid
2022-04-18 11:52:42.140 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[start] Waiting for SM to start
2022-04-18 11:52:42.140 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[start] ServiceManager PID = 265749
2022-04-18 11:52:43.643 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[start] XAGTask retcode = 0
2022-04-18 11:52:43.643 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[start] XAG HealthCheck after start returned 0
2022-04-18 11:52:43.643 : AGFW:558036736: {1:30281:59063} Command: start for resource:
xag.GGNORTH.goldengate 1 1 completed with status: SUCCESS
2022-04-18 11:52:43.643 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[check] Executing action script: /u01/oracle/XAG_MA/bin/aggoldengatescaas[check]
2022-04-18 11:52:43.644 : AGFW:549631744: {1:30281:59063} Agent sending reply for:
RESOURCE_START[xag.GGNORTH.goldengate 1 1] ID 4098:4125749
2022-04-18 11:52:43.795 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[check] GG agent running command 'check' on xag.GGNORTH.goldengate
2022-04-18 11:52:45.548 :CLSDYNAM:558036736: [xag.GGNORTH.goldengate]{1:30281:59063}
[check] XAGTask retcode = 0
2022-04-18 11:52:45.548 : AGFW:549631744: {1:30281:59063} xag.GGNORTH.goldengate 1 1
state changed from: STARTING to: ONLINE
34 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Example:
The GoldenGate report files contain important information, warning messages and errors for all of the GoldenGate
processes, including the Manager processes. If any of the GoldenGate processes fail to start or abend when they are
running, the process report file will contain important information which can be used to determine the cause of the
failure.
35 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
The XAG log file (agctl_goldengate_oracle.trc) has the advantage that it shows timestamps that can be used
when looking at other log or trace files:
Next, check the CRS trace file (crsd_scriptagent_oracle.trc) which shows the reason why DBFS failed to
mount. Below are some example errors caused by incorrect parameter settings in the mount-dbfs.conf file.
• Incorrect DBNAME
2022-04-19 15:32:16.679 : AGFW:1190405888: {1:30281:17383} dbfs_mount 1 1 state
changed from: UNKNOWN to: STARTING
2022-04-19 15:32:16.680 :CLSDYNAM:1192507136: [dbfs_mount]{1:30281:17383} [start]
Executing action script: /u01/oracle/scripts/mount-dbfs.sh[start]
2022-04-19 15:32:16.732 :CLSDYNAM:1192507136: [dbfs_mount]{1:30281:17383} [start] mount-
dbfs.sh mounting DBFS at /mnt/dbfs from database ggdg
2022-04-19 15:32:17.883 :CLSDYNAM:1192507136: [dbfs_mount]{1:30281:17383} [start]
ORACLE_SID is
2022-04-19 15:32:17.883 :CLSDYNAM:1192507136: [dbfs_mount]{1:30281:17383} [start] No
running ORACLE_SID available on this host, exiting
2022-04-19 15:32:17.883 : AGFW:1192507136: {1:30281:17383} Command: start for
resource: dbfs_mount 1 1 completed with invalid status: 2
36 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
• Incorrect ORACLE_HOME
2022-04-19 16:50:38.952 : AGFW:567502592: {1:30281:17739} dbfs_mount 1 1 state
changed from: UNKNOWN to: STARTING
2022-04-19 16:50:38.953 :CLSDYNAM:569603840: [dbfs_mount]{1:30281:17739} [start]
Executing action script: /u01/oracle/scripts/mount-dbfs.sh[start]
2022-04-19 16:50:39.004 :CLSDYNAM:569603840: [dbfs_mount]{1:30281:17739} [start] mount-
dbfs.sh mounting DBFS at /mnt/dbfs from database ggdgs
37 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
To resolve these configuration issues, set the correct parameter values in mount-dbfs.conf.
The same problem is encountered if you are using Oracle Database 11g Release 2 (11.2.0.4) or 12c Release 1 (12.1)
with patch for bug 22646150 applied. This patch changes the way in which file locking is handled by DBFS to match
Oracle Database 12c Release 2 (12.2).
To add the nolock DBFS mount option, the patch for bug 27056711 must be applied to the database. If the patch for
bug 22646150 has not been applied to the database, the patch for bug 27056711 and the nolock mount option is
not required.
When starting a deployment with XAG, one or more processes may not start due to detecting a locking conflict on one
or more files. This will often occur after a RAC node failover where the deployment did not get a chance to shut down
cleanly.
When one of the deployment server processes fails to start (Administration Server, Performance Metrics Server,
Distribution Server, Receiver Server, or Service Manager) check the log file for the particular server located in the
deployment var/log directory.
38 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Next, check to make sure the process failing to start up is not running on any of the RAC nodes.
Example:
$ ps -ef|grep EXT1|grep –v grep
Once you determine that the process is not running, the deployment needs to be shut down cleanly, the file system
unmounted, and the correct DBFS patch applied.
Example:
$ agctl stop goldengate GGNORTH
$ crsctl stop resource dbfs_mount
It is clear that the nolock mount option was not used, which leads to the locking errors.
Use the guidelines at the beginning of this topic to determine if a DBFS patch is required. Then add the nolock
mount option to the mount-dbfs.conf file on all RAC nodes that are part of the deployment.
Example:
MOUNT_OPTIONS=allow_other,direct_io,failover,nolock
When restarting GoldenGate using XAG (agctl start goldengate) it will fail with the following error:
39 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
The CRS trace file (crsd_scriptagent_oracle.trc) does not provide enough information to determine the
reason behind the startup failure.
Example:
In order to determine why the startup failed, increase the CRS logging mode and restart GoldenGate.
Example:
Check the CRS trace file (crsd_scriptagent_oracle.trc) for more information on the failure.
Example:
When Extract or Replicat processes are not set to critical, they will not appear in the CRS trace file. Because Replicat
REP1 is shown as failed, this indicates that REP1 is set to critical and is preventing GoldenGate from starting.
To disable the critical setting for Replicat, the GoldenGate Service Manager and deployment must be started
manually.
Example:
$ export OGG_ETC_HOME=/mnt/acfs/goldengate/deployments/ggsm01/etc
$ export OGG_VAR_HOME=/mnt/acfs/goldengate/deployments/ggsm01/var
$ export OGG_HOME=/u01/oracle/goldengate/ggMS_21c
$ $OGG_HOME/bin/ServiceManager --xagEnabled
Using the Administration Server GUI, select the Replicat or Extract details, and unset the critical flag. Figure 14 shows
how to unset the critical flag. Remember to submit the change.
Once the critical setting has been disabled, XAG can be used to start and stop Oracle GoldenGate Microservices.
Example:
41 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at: oracle.com/contact.
Copyright © 2023, Oracle and/or its affiliates. All rights reserved. This document is Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be
provided for information purposes only, and the contents hereof are subject to change trademarks of their respective owners.
without notice. This document is not warranted to be error-free, nor subject to any other
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC
warranties or conditions, whether expressed orally or implied in law, including implied
trademarks are used under license and are trademarks or registered trademarks of SPARC
warranties and conditions of merchantability or fitness for a particular purpose. We
International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or
specifically disclaim any liability with respect to this document, and no contractual
registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open
obligations are formed either directly or indirectly by this document. This document
Group. 0120
may not be reproduced or transmitted in any form or by any means, electronic or
mechanical, for any purpose, without our prior written permission. Disclaimer: If you are unsure whether your data sheet needs a disclaimer, read the revenue
recognition policy. If you have further questions about your content and the disclaimer
This device has not been authorized as required by the rules of the Federal
requirements, e-mail [email protected].
Communications Commission. This device is not, and may not be, offered for sale or
lease, or sold or leased, until authorization is obtained.
42 Business / Technical Brief / Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices