Overview

1 Overview

Learn about the prerequisites for installing Oracle GoldenGate.

Topics:

Understanding and Obtaining the Oracle GoldenGate Distribution

You can download Oracle GoldenGate from the Oracle GoldenGate Downloads page: https://www.oracle.com/middleware/technologies/goldengate-downloads.html.

Parent topic: Overview

Verify Certification and System Requirements

Ensure that you install your product on a supported hardware or software configuration. For more information, see the certification matrix for this release.

Oracle tests and verifies the performance of your product on all certified systems and environments. As new certifications occur, they are added to the proper certification document. New certifications can occur at any time, and for this reason the certification documents are kept outside of the documentation libraries and are available on Oracle Technology Network.

Here are some additional details about the supported platforms:

Cross Endian Support: Most Oracle GoldenGate products support cross endian replication, which means that the source and target database can be a different platform (or even endian) than the actual server where Oracle GoldenGate is installed.
Fully Certified Criteria: Oracle GoldenGate certifications are often phased in, for a particular new release of the product, Oracle typically supports Oracle databases first and then the various non-Oracle and Big Data technologies. In some cases, Oracle GoldenGate may support the data store you are looking for, but you may need to check the certification matrix for a previous release. Platforms that are in the certification matrix are platforms where either full regression testing is done or where basic validation is performed for continuity purposes.
Fully Supported by Inference: There are other technologies that are supported for Oracle GoldenGate that may not be explicitly listed in the certification matrix. For example, Oracle certify its technologies based on a combination of Chipset, Operating System, Data Store Type, and Data Store Version. As long as these four criteria are met, support is available.
Fully Supported through Open Source Compatibility: There are a number of Open Source technologies that Oracle GoldenGate is certified with such as Big Data and non-Oracle databases. Sometimes, users may have open source environments and need Oracle GoldenGate to provide support with such unique infrastructures, such as Apache HBase on Azure Data Lake. In such cases, Oracle GoldenGate does support any unique open source enviroment if the Chipset, Operating System, Open Source Framework and Framework Version are certified by Oracle GoldenGate. For example, in case of Apache HBase, Oracle GoldenGate support needs to check the version of Apache HBase, for which Oracle GoldenGate is certified, and if that version happens to be running on some Cloud, then Oracle GoldenGate will be supported. In each of these Open Source examples (that are not explicitly certified), Oracle GoldenGate support is available using the base open source configurations, such as Apache on certified hardware. However, Oracle may not be obligated to support each possible infrastructure combination that users may select.
Java JDBC Support: Many SQL, NoSQL and Big Data technologies support Java JDBC capabilities. Oracle GoldenGate for Big Data enables replication of transactions into any JDBC compliant drivers. Individual drivers may vary in terms of performance and metadata coverage, so there is no specific guarantee that Oracle GoldenGate JDBC support will work with every JDBC driver, but most common JDBC drivers and commercial implementations usually work with Oracle GoldenGate JDBC and these are supported. If you don’t find your technology in the certification matrix, but you know that there is a JDBC drive available, then it could be that you may have both technical compatibility and a supported configuration.
Managed and Unmanaged Data Stores: With the advent of managed Cloud services such as native cloud services, many data stores are now available with automated lifecycle, patching, and other conveniences. In many cases, managed data stores are fully compatible and consistent with Oracle GoldenGate certifications and support. However, in some cases, a cloud vendor may turn-off or restrict access to features that Oracle GoldenGate requires for full features compatibility, particularly with Oracle GoldenGate Extract capabilities. If you have a question about a third party cloud managed service for a data store that Oracle GoldenGate may usually support, but you do not see that managed service listed in the Oracle GoldenGate certification matrix, directly contact Oracle GoldenGate product management.

Parent topic: Overview

Operating System Requirements

This section outlines the operating system resources that are necessary to support Oracle GoldenGate.

Topics:

Parent topic: Overview

Memory Requirements

All Platforms

The amount of memory that is required for Oracle GoldenGate depends on the amount of data being processed, the number of Oracle GoldenGate processes running, the amount of RAM available to Oracle GoldenGate, and the amount of disk space that is available to Oracle GoldenGate for storing pages of RAM temporarily on disk when the operating system needs to free up RAM (typically when a low watermark is reached). This temporary storage of RAM to disk is commonly known as swapping or paging (herein referred to as swapping). Depending on the platform, the term swap space can be a swap partition, a swap file, a page file (Windows) or a shared memory segment (IBM for i).

Modern servers have sufficient RAM combined with sufficient swap space and memory management systems to run Oracle GoldenGate. However, increasing the amount of RAM available to Oracle GoldenGate may significantly improve its performance, as well as that of the system in general.

Typical Oracle GoldenGate installations provide RAM in multiples of gigabytes to prevent excessive swapping of RAM pages to disk. The more contention there is for RAM the more swap space that is used.

Excessive swapping to disk causes performance issues for the Extract process in particular, because it must store data from each open transaction until a commit record is received. If Oracle GoldenGate runs on the same system as the database, then the amount of RAM that is available becomes critical to the performance of both.

RAM and swap usage are controlled by the operating system, not the Oracle GoldenGate processes. The Oracle GoldenGate cache manager takes advantage of the memory management functions of the operating system to ensure that the Oracle GoldenGate processes work in a sustained and efficient manner. In most cases, users need not change the default Oracle GoldenGate memory management configuration.

For more information about evaluating Oracle GoldenGate memory requirements, see the CACHEMGR parameter in the Reference for Oracle GoldenGate. Also, see Tuning the Performance of Oracle GoldenGate in Administering Oracle GoldenGate.

Windows Platforms

For Windows Server environments, the number of process groups that can be run are tightly coupled to the non-interactive Windows desktop heap memory settings. The default settings for Windows desktop heap may be enough to run very small numbers of process groups. As you approach larger amounts of process groups, more than 60 or so, you have two choices:

Adjust the non-interactive value of the SharedSection field in the registry based on information from Microsoft (Windows desktop heap memory).
Increase the number of Oracle GoldenGate homes and spread the total number of desired process groups across these homes.

For more information on modifying the Windows Desktop Heap memory, review the following Oracle Knowledge Base document (Doc ID 2056225.1).

Parent topic: Operating System Requirements

Disk Requirements

Disk space requirements vary based on the platform, database, and Oracle GoldenGate architecture to be installed.

Parent topic: Operating System Requirements

Disk Requirements for Oracle GoldenGate Installation Files

The disk space requirements for a Oracle GoldenGate installation vary based on your operating system and database. Ensure that you have adequate disk space for the downloaded file, expanded files, and installed files, which can be up to 2GB.

Parent topic: Disk Requirements

Temporary Disk Requirements

When total cached transaction data exceeds the CACHESIZE setting of the CACHEMGR parameter, Extract begins writing cache data to temporary files located in the Oracle GoldenGate installation directory. For Classic Architecture, this is in the installation's dirtmp folder, and for Microservices Architecture, it is the /var/temp folder for that deployment.

The cache manager assumes that all of the free space on the file system is available. These directories can fill up quickly if there are many transactions with large transaction sizes. To prevent I/O contention and possible disk-related Extract failures, dedicate a disk to this directory. You can assign a name to this directory with the CACHEDIRECTORY option of the CACHEMGR parameter.

Note:

CACHEMGR is an internally self-configuring and self-adjusting parameter. It is rare that this parameter requires modification. Doing so unnecessarily may result in performance degradation. It is best to acquire empirical evidence before opening an Oracle Service Request and consulting with Oracle Support.

It is typically more efficient for the operating system to swap to disk than it is for Extract to write temporary files. The default CACHESIZE setting assumes this. Thus, there should be sufficient disk space to account for this, because only after the value for CACHESIZE is exceeded will Extract write transaction cached data to temporary files in the file system name space. If multiple Extract processes are running on a system, the disk requirements can multiply. Oracle GoldenGate writes to disk when there is not enough memory to store an open transaction. Once the transaction has been committed or rolled back, committed data is written to trail files and the data are released from memory and Oracle GoldenGate no longer keeps track of that transaction. There are no minimum disk requirements because when transactions are committed after every single operation these transactions are never written to disk.

Note:

Oracle recommends that you do not change the CACHESIZE because performance can be adversely effected depending on your environment.

Parent topic: Disk Requirements

Other Disk Space Considerations

In addition to the disk space required for the files and binaries that are installed by Oracle GoldenGate, allow additional disk space to hold the Oracle GoldenGate trails. Trails can be created up to 2GB in size, with a default of 500MB. The space required depends upon the selected size of the trails, the amount of data being captured for replication, and how long the consumed trails are kept on the disk. The recommended minimum disk allocated for Trails may be computed as:

((transaction log size * 0.33) * number of log switches per day) * number of days to retain trails

Based on this equation, if the transaction logs are 1GB in size and there is an average of 10 log switches per day, it means that Oracle GoldenGate will capture 3.3GB data per day. To be able to retain trails for 7 days, the minimum amount of disk space needed to hold the trails is 23GB.

A trail is a set of self-aging files that contain the working data at rest and during processing. You may need more or less than this amount, because the space that is consumed by the trails depends on the volume of data that will be processed.

Parent topic: Disk Requirements

Disk Requirements for NonStop SQL/MX

Oracle GoldenGate must be installed on a physical disk drive, not on virtual disks that are maintained by NonStop SMF (Storage Management Foundation).

Assign the following free disk space:

Approximately 200 MB for the compressed download file.
Approximately 966 MB for the installation directory after the download is expanded. This requirement is per installation. For example, to install two builds of Oracle GoldenGate into two separate directories, allocate 1932 MB of space.

Other Disk Space Considerations

In addition to the disk space required for the files and binaries that are installed by Oracle GoldenGate, allow an additional 1 GB of disk space on any system that hosts the Oracle GoldenGate trail (or trails). A trail is a set of self-aging files that contain the working data at rest and during processing. You may need more or less than this amount, because the space that is consumed by the trails depends on the volume of data that will be processed. See Assigning Storage for Oracle GoldenGate Trails in Administering Oracle GoldenGatefor guidelines on sizing trails.

Temporary Disk Requirements

By default, Oracle GoldenGate maintains memory data that it saves to disk as part of the memory management function in the dirtmp sub-directory of the Oracle GoldenGate installation directory. This directory can fill up quickly if there is a large transaction volume with large transaction sizes. To prevent I/O contention and possible disk-related Extract failures, dedicate a disk to this directory.

Parent topic: Disk Requirements

Storage for Oracle GoldenGate Trails

To prevent trail activity from interfering with business applications, assign a separate disk or file system to contain the trail files. These files are created during processing to store all of the data that is captured by Oracle GoldenGate. The default size can be changed during the configuration process. Trail files accumulate but can be purged according to rules set with the PURGEOLDEXTRACTS parameter. You will specify the location of the trails when you configure Oracle GoldenGate. For more information about configuring trail files, see Creating a Trail in Administering Oracle GoldenGate.

Parent topic: Disk Requirements

Network

The following network resources must be available to support Oracle GoldenGate:

Use the fastest network possible and install redundancies at all points of failure for optimal performance and reliability, especially in maintaining low latency on the target.
You can configure Oracle GoldenGate Microservices to use a reverse proxy. Oracle GoldenGate Microservices includes a script called ReverseProxySettings that generates configuration file for only the NGINX reverse proxy server.

See Reverse Proxy Support in Oracle GoldenGate Security Guide.
Configure the system to use both TCP and UDP services, including DNS. Oracle GoldenGate supports IPv4 and IPv6 and can operate in a system that supports one or both of these protocols.
Configure the network with the host names or IP addresses of all systems that will be hosting Oracle GoldenGate processes and to which Oracle GoldenGate will be connecting.
Oracle GoldenGate requires some unreserved and unrestricted TCP/IP network ports, the number of which depends on the number and types of processes in your configuration. See Administering Oracle GoldenGate for details on how to configure the Manager process to handle the required ports.
Keep a record of the ports that you assigned to Oracle GoldenGate processes. You specify them with parameters when configuring deployments for the Microservices Architecture and for the Manager and pumps with the Classic Architecture.
Configure your firewalls to accept connections through the Oracle GoldenGate ports.

Parent topic: Operating System Requirements

Operating System Privileges

The following are the privileges in the operating system that are required to install Oracle GoldenGate and to run the processes:

The person who installs Oracle GoldenGate must be granted read and write privileges on the Oracle GoldenGate software home directory.
To install on Windows, the person who installs Oracle GoldenGate must log in as an Administrator.
The Oracle GoldenGate Extract, Replicat, and Manager processes, and configuring deployments using the oggca.sh script must operate as an operating system user that has read, write, and delete privileges on files and subdirectories in the Oracle GoldenGate directory.
For Extract processes that read from transaction logs and backups, it must operate as an operating system user that has read access to the logs and backup files.
Oracle recommends that you dedicate the Extract and Replicat operating system users to Oracle GoldenGate. Sensitive information might be available to anyone who runs an Oracle GoldenGate process, depending on how database authentication is configured.

Manager Running on Windows

Parent topic: Operating System Requirements

Manager Running on Windows

The Manager process can run as a Windows service, or it can run interactively as the current user. The Manager process requires:

Full control permissions over the files and folders within the Oracle GoldenGate directories.
Full control permissions over the trail files, when they are stored in a location other than the Oracle GoldenGate directory.
Membership in the server's local Administrators Group (on all nodes in a cluster).
If you are running Manager as a Windows service with an Extract or Replicat that is connected to a database using Windows Authentication, then the process attempts to log in to the database with the account that the Manager is running under. Ensure that the Manager's service account has the correct access to the database.

The programs that capture and replicate data, Extract and Replicat, run under the Manager account and inherit the Manager's operating system level privileges.

Parent topic: Operating System Privileges

Other Operating System Requirements

The following additional features of the operating system must be available to support Oracle GoldenGate.

To use Oracle GoldenGate user exits, install the C/C++ Compiler, which creates the programs in the required shared object or DLL.
Gzip to decompress the Oracle GoldenGate installation files. Otherwise, you must unzip the installation on a PC by using a Windows-based product, and then FTP it to the AIX, DB2 for i, or DB2 z/OS platforms.
For best results on DB2 platforms, apply high impact (HIPER) maintenance on a regular basis staying within one year of the current maintenance release. The HIPER process identifies defects that could affect data availability or integrity. IBM provides Program Temporary Fixes (PTF) to correct defects found in DB2 for i and DB2 z/OS.
For Oracle GoldenGate running on a Windows system, install the Microsoft Visual C++ Redistributable Package for Visual Studio 2015, 2017, and 2019. This package installs runtime components of Visual C++ Libraries that are required for Oracle GoldenGate processes.

Download and install the x64 version of Visual C++ 2015, 2017, and 2019 package:

https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
For Oracle GoldenGate for Oracle to be installed on a remote hub server, download and install the Oracle Database 21c client for the operating system platform where Oracle GoldenGate will be installed and ensure that you install the Administrator version of the client.

Parent topic: Operating System Requirements

Operating System Requirements for NonStop SQL/MX

To support Oracle GoldenGate for SQL/MX, install the Open System Services (OSS) environment.

Parent topic: Operating System Requirements

Windows Console Character Sets

The operating system and the command console must have the same character sets. Mismatches occur on Microsoft Windows systems, where the operating system is set to one character set, but the DOS command prompt uses a different, older DOS character set. Oracle GoldenGate uses the character set of the operating system to send information to GGSCI command output; therefore a non-matching console character set causes characters not to display correctly. You can set the character set of the console before opening a GGSCI session by using the following DOS command:

chcp codepagenumber

For example, chcp 437.

For a code page overview, see https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752(v=vs.85).aspx and the list of code page identifiers https://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx.

Parent topic: Operating System Requirements

Database Requirements

This section outlines the database requirements that are necessary to support Oracle GoldenGate for different databases.

Topics:

Parent topic: Overview

Requirements for Installing Oracle GoldenGate for DB2 LUW

Learn the prerequisites for installing Oracle GoldenGate for a DB2 LUW database.

Topics:

Parent topic: Database Requirements

Choosing an Installation System for DB2 LUW

To install Oracle GoldenGate for DB2 LUW, you can use either of the following configurations:

Install Oracle GoldenGate on the DB2 LUW database server.
Install Oracle GoldenGate on another server, and configure Oracle GoldenGate to connect remotely to the database server through DB2 Connect. All of the Oracle GoldenGate functionality that is supported for DB2 LUW is supported in this configuration. To use this option, proceed to Choosing and Configuring a System for Remote Capture or Delivery.

To Use Remote Delivery to the DB2 LUW System Using DB2 Connect

For the intermediary system, select any supported for the DB2 for LUW database to be the system that Oracle GoldenGate is installed on.
Install and run DB2 for LUW on the selected remote system so that the Replicat process can use the supplied DB2 Connect driver.
Catalog the DB2 target node in the DB2 for LUW database on the remote system by using the following DB2 command:
```
catalog tcpip node db2_node_name remote DNS_nameserver DB2_port-number
```
Add the target DB2 database to the DB2 for LUW catalog on the intermediary system by using the following DB2 command:
```
catalog db database_name as database_alias at node db_node_name 
```
Note:

Refer to the IBM DB2 LUW documentation for more information about these commands.
Install Oracle GoldenGate. For CA, see Installing Oracle GoldenGate Classic Architecture for Non-Oracle Databases. For MA, see Installing Microservices Architecture for Oracle GoldenGate.
Specify the DB2 target database name with the Replicat parameter.TARGETDB when you configure the Oracle GoldenGate processes.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 LUW

Choosing and Configuring a System for Remote Capture or Delivery

In a remote installation, you install Oracle GoldenGate on a server that is remote from the source or target database server. This server can be any Linux, UNIX, or Windows platform that Oracle GoldenGate supports for the DB2 for LUW database. The Oracle GoldenGate build must match the version of DB2 LUW that is running on the installation server.

In this configuration, the location of the database is transparent to Extract and Replicat. Extract can read the DB2 logs on a source DB2 LUW database server, and Replicat can apply data to a target DB2 LUW server.

To Configure Remote Capture or Delivery:

Install and run DB2 for LUW on the remote server that has DB2 Connect.
Catalog the remote server in the DB2 source or target database by using the following DB2 command.
```
catalog tcpip node db2_node_name remote remote_DNS_name
```
Catalog the DB2 target node in the DB2 for LUW database on the remote server by using the following DB2 command:
```
catalog tcpip node db2_node_name remote remote_DNS_name server remote_port_number
```
Add the DB2 source or target database to the DB2 catalog on the remote server by using the following DB2 command:
```
catalog db database_name as database_alias at node db_node_name
 
```
Note:

Refer to the IBM DB2 LUW documentation for more information about these commands.
Download and install the Oracle GoldenGate build that is appropriate for the DB2 LUW database on the remote server.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 LUW

Requirements for Installing Oracle GoldenGate for DB2 for i

Learn the prerequisites for installing Oracle GoldenGate for a DB2 for i database.

Topics:

Parent topic: Database Requirements

Memory Requirements

Oracle GoldenGate requires the following memory resources on the remote system, and the database host system.

On the remote system:

The amount of memory that is required for Oracle GoldenGate depends on the amount of data being processed, the number of Oracle GoldenGate processes running, the amount of RAM available to Oracle GoldenGate, and the amount of disk space that is available to Oracle GoldenGate for storing pages of RAM temporarily on disk when the operating system needs to free up RAM (typically when a low watermark is reached). This temporary storage of RAM to disk is commonly known as swapping or paging. Depending on the platform, the term swap space can be a swap partition, a swap file, or a shared memory segment (IBM i platforms). Modern servers have sufficient RAM combined with sufficient swap space and memory management systems to run Oracle GoldenGate. However, increasing the amount of RAM available to Oracle GoldenGate may significantly improve its performance, as well as that of the system in general.

Typical Oracle GoldenGate installations provide RAM in multiples of gigabytes to prevent excessive swapping of RAM pages to disk. The more contention there is for RAM, the more swap space is used. Excessive swapping to disk causes performance issues for the Extract process in particular, because it must store data from each open transaction until a commit record is received. If Oracle GoldenGate runs on the same system as the database, the amount of RAM that is available becomes critical to the performance of both.

For more information about evaluating Oracle GoldenGate memory requirements, see the CACHEMGR parameter in the Reference for Oracle GoldenGate.

On the DB2 for i host system allocate approximately 10-50 MB of memory for each Oracle GoldenGate journal reader.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 for i

Oracle GoldenGate Security Privileges

This section outlines the security privileges that Oracle GoldenGate requires on a source DB2 for i system and on a Windows or Linux target system.

The person who installs Oracle GoldenGate must have read and write privileges on the Oracle GoldenGate installation directory, because steps will be performed to create some sub-folders and run some programs. On a Windows systen, the person who installs Oracle GoldenGate must log in as Administrator.

Manager, Replicat, and Collector (program name is server) are active. Manager controls the other processes and interacts with Collector to receive incoming data, while Replicat applies data to the target DB2 for i database through ODBC.

Oracle GoldenGate processes must be assigned a user account that is dedicated to Oracle GoldenGate and cannot be used by any other program. One user account can be used by all of the Oracle GoldenGate processes. This account must have privileges to read, write, and delete files and directories within the Oracle GoldenGate installation directory.

If the Extract user profile does not have the required authority, Extract will log the following errors and stop.

[SC=-1224:SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command.SQL STATE 55032: The CONNECT statement is invalid, because the database manager was stopped after this application was started]

The user profile must be specified with the USERID parameter when you configure the parameter files and in the DBLOGIN command prior to issuing any GGSCI commands that interact with the database.

For more information on user profiles and security privileges, see User Profiles and Security Privileges.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 for i

General Requirements

Portable Application Solution Environment (PASE) must be installed on the system.
Java 8 must be installed on the IBM i and the Linux host system where GoldenGate for IBM i will run.
OpenSSH is recommended to be installed on the system. OpenSSH is part of the IBM Portable Utilities licensed program and allows SSH terminal access to the system in the same manner as other Linux system.
A library/schema should be dedicated to each install for Oracle GoldenGate on the IBM i system.

The IBM DB2 for i Program temporary fixes (PTFs) that are required by release for Oracle GoldenGate are detailed in the following tables:

IBM i7.3 Group PTF	Level	Name	Notes
SF99730	23103	Cumulative PTF	NA
SF99731	12	All PTF groups except cumulative PTF package	.

IBM i7.4 Group PTF	Level	Name	Notes
SF99740	23117	Cumulative PTF	NA
SF99741	8	All PTF groups except cumulative PTF package	NA

IBM i7.5 Group PTF	Level	Name	Notes
SF99750	23110	Cumulative PTF	NA
SF99751	4	All PTF groups except cumulative PTF package	NA

These required PTFs are the levels at which Oracle GoldenGate has been tested against for the 21c releases. To check the group PTF levels, you must use the WRKPTFGRP command from a 5250 terminal session and check for the specific PTFs with the commands shown in the preceding tables. The specific extra PTFs must be at least temporarily applied.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 for i

Choosing an Installation Operating System

Oracle GoldenGate for DB2 for i operates remotely on Intel Linux systems. A few componenets will be automatically copied to the IBM i systems.

Oracle GoldenGate for Db2 for i supports the IBM i Access ODBC Driver 64-bit. For more information, see Supported ODBC Driver.

Consider the following:

The best performance is seen with a system that has the lowest network latency to the IBM i system that you use. Although it is possible to run over a wide area network, the performance suffers due to the increased network latency.
No special requirements beyond what capture already has for Oracle GoldenGate delivery. Because this Oracle GoldenGate release is a fully-remote distribution, the former Oracle GoldenGate DB2 for i remote product is no longer shipped separately. However, Windows is not supported in Oracle GoldenGate for DB2 for i in this release. If you still require delivery to DB2 for i from Windows, then Oracle GoldenGate DB2 for i remote 12.3 is still available.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 for i

Supported ODBC Driver

Starting from Oracle GoldenGate release 21.12, Oracle GoldenGate for Db2 for i supports the IBM i Access ODBC Driver 64-bit version 1.1.0.27 or higher.

See Linux, macOS, and PASE Application Packages for more information on IBM i Access ODBC Driver and follow the steps provided to install IBM i Access application package for the Linux operating system.

In addition, install unixODBC driver manager to be used with the Db2 ODBC driver on all supported Linux operating systems. For example, to install the unixODBC driver manager on the Red-Hat Linux operating system, use the yum command. See Installing the unixODBC driver manager for more information.

After the IBM i Access ODBC Driver and the unixODBC driver manager are installed successfully, add appropriate values in the odbcinst.ini and odbc.ini files to register the driver and the system.

You can test if the DSN and drivers are configured properly by testing the connection using the isql command. For example:

isql -v DSN user password

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 for i

Installing Oracle GoldenGate Files for IBM DB2 for i

The installation of the Oracle GoldenGate requires that certain environment variables be set:

The JAVA_HOME variable is set to the location of a Java 8 JRE.
The LD_LIBRARY_PATH variable must include $JAVA_HOME/lib:$JAVA_HOME/lib/amd64:$JAVA_HOME/lib/amd64/server.

To install the Oracle GoldenGate files, do the following:

Unzip the downloaded files by using gunzip or n equivalent compression product.
Move the files in binary mode to a folder on the drive where you want to install Oracle GoldenGate.
From the Oracle GoldenGate folder, run the GGSCI program.
Edit the GLOBALS file to set the location of the GoldenGate library (GGSCHEMA) that will be used on the IBM i system(s) that this installation will work with.
In GGSCI, issue the following command to create the Oracle GoldenGate working directories.

ggsci> CREATE SUBDIRS
Run the DBLOGIN command to all IBM i systems that this GoldenGate installation will work with using a user profile that has at least *ALLOBJ authority. This will allow the native objects to be correctly copied and setup on the IBM i system in the library specified by GGSCHEMA in GLOBALS. This level of authority is only required for Oracle GoldenGate setup, and not for any operation of the product.
Issue the following command to exit GGSCI.

ggsci>EXIT

Note:

On an upgrade installation process, the ownership of the objects on the IBM i system(s) is retained with the original owner of those objects. However, for an initial installation process, if the owner is to be a profile other than the install profile, then it would be required to log in to each IBM i system directly and change the ownership manually in the GGSCHEMA library to the user or group profile that is intended for that system.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 for i

Requirements for Installing Oracle GoldenGate for DB2 z/OS

Learn the prerequisites for installing Oracle GoldenGate for a DB2 z/OS database.

Topics:

Parent topic: Database Requirements

System Services

Activate UNIX System Services (USS) only if required to install the executables for the Extract support modules.

Oracle GoldenGate supports Sysplex data sharing.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 z/OS

Memory Requirements

Oracle GoldenGate requires the following memory resources on the Oracle GoldenGate remote system and the database host system.

On the remote system

Excessive swapping to disk causes performance issues for the Extract process in particular, because it must store data from each open transaction until a commit record is received. If Oracle GoldenGate runs on the same system as the database, the amount of RAM that is available becomes critical to the performance of both.

For more information about evaluating Oracle GoldenGate memory requirements, see the CACHEMGR parameter in the Reference for Oracle GoldenGate.

On the DB2 host system

Allocate approximately 10-50 MB of virtual memory for each Oracle GoldenGate log reader, oggreadb, that is invoked depending on the size of the log buffer. There is one invocation per Extract process on the remote system. To adjust the maximum log buffer size, use the TRANLOGOPTIONS BUFSIZE parameter in the Extract parameter file.

When setting up the Workload Manager (WLM) environment for the Extract log read components, it is recommended to set NUMTCB in the range of 10-40 depending on your environment. Refer to the IBM documentation for more information.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 z/OS

Disk Requirements for DB2 z/OS

On the DB2 host system: (Only applicable if you are installing stored procedures.) Assign a zFS (zSeries file systems) or hierarchical file system volume. To determine the size of the Oracle GoldenGate download file, examine the size of zOSPrograms.zip on the remote DB2 system after extracting the installation image.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 z/OS

Operating System Privileges for DB2 z/OS

The remote host requires privileges to use the chmod +rw command on the sub-directories in the Oracle GoldenGate product directory.

Table 1-1 shows the other required operating system privileges for Oracle GoldenGate:

Table 1-1 Operating System Privileges

DB2 z/OS User Privilege	Extract	Stored Procedures	Replicat
`CONNECT` to the remote DB2 subsystem.	X	X	X

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 z/OS

Choosing an Installation Operating System

Oracle GoldenGate for DB2 for z/OS operates remotely on zLinux, AIX or Intel Linux systems. To capture data, a small component must be installed on the DB2 z/OS system that contains the DB2 instance that will allow Oracle GoldenGate to read the DB2 log data.

To install Oracle GoldenGate on a remote zLinux, AIX or Linux system, you have the following options for connecting to DB2 on the z/OS system:

DB2 Connect v10.5 or greater
IBM Data Server Driver for ODBC and CLI v10.5 or greater
IBM Data Server Client v10.5 or greater
IBM Data Server Runtime Client v10.5 or greater

Consider the following:

Extract uses Open Database Connectivity (ODBC) to connect to the DB2 subsystem on the z/OS system. If one of the other drivers is not already installed, the IBM Data Server Driver for ODBC and CLI is the most lightweight driver and is recommended for most configurations, although the other drivers are suitable also.
To capture DB2 log data, the log reader component must be installed in a Library (PDSE) on the z/OS system. Load Libraries (PDS) are not supported. The library must be authorized program facility (APF) helps your installation protect the system. APF-authorized programs can access system facility (APF) authorized. The log read component is called through SQL from the remote system and since it is APF authorized, an authorized Workload Manager (WLM) environment must also be used to run these programs since the default DB2 supplied WLM environment is not able to run authorized workload.
No special requirements beyond what capture already has for Oracle GoldenGate delivery. Because this Oracle GoldenGate release is a fully-remote distribution, the former Oracle GoldenGate DB2 Remote product is no longer shipped separately. However, Windows is not supported in Oracle GoldenGate for DB2 z/OS in this release. If you still require delivery to z/OS from Windows, then Oracle GoldenGate DB2 Remote 12.2 is still available.
UNIX System Services (USS) is no longer required (as in prior releases) except for a few installation procedures.
Windows only: To apply data to a DB2 target from Windows, Oracle GoldenGate DB2 Remote v12.2 must be used. Capture is not support in this scenario.
Install Oracle GoldenGate DB2 Remote on a remote system for remote delivery to the DB2 target system. In this configuration, Replicat connects to the target DB2 database by using the ODBC API that is supplied in DB2 Connect . This configuration requires DB2 LUW to be installed on the remote system.

Note:

All of the Oracle GoldenGate functionality that is supported for DB2 for z/OS is supported by DB2Connect. In addition, ASCII character data is converted to EBCDIC automatically by DB2 Connect.
Although it is possible to install Oracle GoldenGate on zLinux, AIX, and Intel based Linux, the best performance is seen with a system that has the lowest network latency to the z/OS system that you use. Although it is possible to run over a wide area network, the performance suffers due to the increased network latency. Oracle recommends using a zLinux partition on the same physical hardware as the z/OS system that is running DB2 using Hipersockets or a VLAN between the partitions. Otherwise, systems connected with OSA adapters in the same machine room, would be the next best choice. Alternatively, the fastest Ethernet connection between the systems that is available would be acceptable.

Using the Remote Delivery to the DB2 z/OS using DB2Connect

For the intermediary system, select any platform that Oracle GoldenGate supports for the DB2 for LUW database. This is the system on which Oracle GoldenGate is installed.
Install and run DB2 for LUW on the selected remote system so that the Replicat process can use the supplied DB2 Connect driver.
Catalog the DB2 target node in the DB2 for LUW database on the remote system by using the following DB2 command:
```
catalog tcpip node db2_node_name remote DNS_name server DB2_port-number
```
Add the target DB2 database to the DB2 for LUW catalog on the intermediary system by using the following DB2 command:
```
catalog db database_name as database_alias at node db_node_name 
```

See the IBM DB2 LUW documentation for more information about these commands.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 z/OS

Installing Extract Components on Db2 z/OS

The Oracle GoldenGate Db2 z/OS Extract uses SQL objects to access and read the Db2 log. These Oracle GoldenGate Db2 z/OS objects require a minimum hardware platform of z10, a minimum operating system release of 1.13, and a minimum Db2 release of 11. The components consist of executable load modules, SQL stored procedures and functions, and external programs called via the stored procedures. these components are:

External programs (authorized) includes the following programs:
1. oggib001 – Initialization and utility program
2. oggrb001 – Log read program functionality
3. oggmt001 – Stand-alone program that monitors ECSA and 64-bit memory
4. oggjt001 – Setup program for the oggmt001 startup JCL run from oggib001 program
5. oggfr001 – Utility for use by a DBA under guidance from Oracle Support
SQL stored procedure and function includes demo_db2_setupb_os390.sql with the OGGINITB and OGGREADB SQL.
JCL procedure, oggtask.jcl

Note:

These external names, SQL and JCL names are the default names, which you can edit and update. This process is discussed in the subsequent sections.

The Replication Process for Db2 z/OS Extract figure illustrates the replication process for the Db2 z/OS Extract and its mainframe components.

Figure 1-1 Replication Process for Db2 z/OS Extract

The process starts and runs as shown using the numbers 1 through 9 in the figure, which is given below:

Extract reads the parameters, including the JCL parameters, from the parameter file created during installation.
Extract reports the startup information and prepares to write the trail files.
ODBC is used to gather information from the Db2 database and start replication.
The OGGINITB SQL stored procedure starts to prepare shared memory and to gather other data needed for replication.
The OGGIB001 external program called by the SQL stored procedure starts the memory monitor task using the OGGJT001 job setup program.
The OGGMT001 memory monitor task starts monitoring the ECSA and 64-bit shared memory.
The OGGREADB SQL Function calls the external program OGGRB001.
The OGGRB001 external program repeatedly calls the Db2 log read program to create a result set that returns 1 to many log record buffers to the Extract.
When a log record result set is complete, OGGRB001 ends after sending the result set to the Extract.

Extract repeats steps 7 to 9 until shut down or abnormal termination. If the memory task fails to start, OGGI001 program returns a flag indicating there was a JCL error or setup issue and Extract manages its own memory. If the memory task starts properly, the memory task tests constantly changing fields in the 48-byte ECSA shared memory. These fields stop changing if the Extract terminates for any reason. At that point, the memory manager waits in case the Extract or network is slow and releases the memory before shutting down after a configured time limit.

To install the components needed for Oracle GoldenGate for Db2 z/OS for Extract:

Ensure that a library (PDSE) exists on the Db2 z/OS system and an entry for it is made in the authorized library list. This library is the location where the Oracle GoldenGate external program objects will reside.
Ensure that an APF-authorized WLM environment exists that references the PDSE from the preceding step. Oracle recommends that NUMTCB value for the WLM environment be 10-40 for stored procedures. The NUMTCB value depends on the maximum number of Extracts that are running concurrently against the database and on how much throughput each Extract requires. If you want flexibility in setting NUMTCB, you specify it in the startup JCL for the WLM, but not in the creation panel.
You can set up security for the WLM application environments and for creating stored procedures by completing the following:
1. (Optional) Specify which WLM-established address spaces can run stored procedures. If you do not complete this step, then any WLM-established address space can run stored procedures.
2. Grant access to users to create procedures in specific WLM address spaces.
3. Grant access to users to create procedures in specific schemas. Use the GRANT statement with the CREATIN option for the appropriate schema.
4. Grant access to users to create packages for procedures in specific collections. Use the GRANT statement with the CREATE option for the appropriate collection.
5. Grant access to refresh the WLM environments to the appropriate people.
6. Add additional RACF authority to the appropriate people, allowing the WLM procedures to start the memory manager job.
Ensure the ID used to run the WLM startup JCL procedure has permission to use RRSAF. Each time one of the Db2 WLM address spaces is started, it uses RRSAF to attach to Db2. See the Db2 11 for z/OS Installation and Migration Guide
In the Linux or UNIX installation of Oracle GoldenGate for Db2 z/OS, there is a ZIP file called zOSPrograms.zip. Unzip zOSPrograms.zip to zOSPrograms.tar and copy zOSPrograms.tar in binary mode to your Db2 z/OS system into an HFS directory.
On your Db2 z/OS system in USS or OMVS, change directories to the directory containing zOSPrograms.tar.
Restore the objects with the command: tar -xovf zOSPrograms.tar.

Note:

In this command, the copy target is double-quote forward-slash single-quote authorized PDSE name single-quote double quote. The -X is an uppercase capital X not a lowercase x.
Copy the objects to the authorized PDSE. Use the cp –X ogg[irmj][abt][0-9]* “//’authorized_PDSE_name’” where authorized_PDSE_name is the name of the APF authorized PDSE, which is intended for the Oracle GoldenGate objects. Using this command installs the objects with the default names.
Installing the scripts with different names allows you to conform with system protocols, or it allows you to run multiple versions of Oracle GoldenGate. To install the scripts with different names, it is recommended to create a shell script that renames the programs before copying them to the PDSE. An example of the shell script is given in the following code snippet.
```
#!/bin/bash
# Copy new programs renaming them to version 21.12 names.
cp oggib001 oggi2112
cp oggrb001 oggr2112
cp oggmt001 oggm2112
cp oggjt001 oggj2112
cp -X oggi2112 “//’SYS4.WLMDSNA.AUTHLOAD’”
cp -X oggr2112 “//’SYS4.WLMDSNA.AUTHLOAD’”
cp -X oggm2112 “//’SYS4.WLMDSNA.AUTHLOAD’”
cp -X oggj2112 “//’SYS4.WLMDSNA.AUTHLOAD’”
```
You can run the script using chmod +x command. You can copy and reuse this script for new versions.
You must create the SQL procedures using your SQL tool of choice so that Oracle GoldenGate can call the Extract objects. The Oracle GoldenGate stored procedures should have permission granted to only those users that use them for replication.

An example SQL script in the Oracle GoldenGate install directory contains the SQL statements to set up the stored procedures on the Db2 z/OS instance. The demo_db2_setupb_os390.sql script is for Db2 v11.1 and higher and can run from any SQL tool on any platform that can connect to your Db2 z/OS instance. This script must run on the Db2 instance that you use with your Extract. The script provided in the remote installation directory is in ASCII format. The same script is restored through zOSPrograms.tar on the Db2 z/OS system in EBCDIC and is suitable for use through native Db2 z/OS tools such as SPUFI.

Edit the following line before running the scripts:
- Modify the WLM ENVIRONMENT line to use the correct name for the WLM environment that you will use for Oracle GoldenGate.

Note:

The oggifi0001 schema name is configurable using the TRANLOGOPTIONS REMOTESCHEMA schemaname parameter. The procedure names are not configurable. Each of the external names in the script and the PDSE can be renamed as long as the script names and the PDSE object names match. Changing these names is part of the procedure that allows migration to new versions or if specific naming procedures must be adhered to on Db2 z/OS. The following table contains a check list of components that you may wish to edit and/or update:

Table 1-2 List of Editable Components

Component	From	Where
`oggib001`	tar file	authorized PDSE
`oggrb001`	tar file	authorized PDSE
`oggmt001`	tar file	authorized PDSE & proc library
`oggjt001`	tar file	authorized PDSE & Extract parm
`oggpr001`	tar file	procedure library & Extract parm
proclib	MVS	add Extract parm if needed
step libraries	MVS	WLM and `oggpr001` procedure library
remoteschema		`demo_db2_setupb_os390.sql` and Extract parm
WLM name	MVS	`demo_db2_setupb_os390.sql`
external program		`demo_db2_setupb_os390.sql`

Note:

Remember to perform all these steps after every new patch installation.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 z/OS

Using Shared Memory Manager for Extract

Oracle GoldenGate Extract starts a separate task, or job, from the WLM to monitor shared memory usage. This memory consists of a small 48 to 64 byte ECSA area, and a large 64-bit area based on the Extract buffer size.

Specific fields in shared memory get updated for every read performed by the Extract. These fields are updated whether or not the script returns any data. The monitor checks those fields to ensure the Extract has not become inactive. If the Extract is inactive, the shared memory is released, and the monitor ends. You can control the Memory Manager using the remote_memory_options parameter in the Extract’s parameter file.

You can specify multiple sub-parameters to configure the monitor task. You can configure the wait interval and inactive time the monitor uses by specifying sub-parameters of the remote memory options, as shown in the following example:

remote_memory_options wait_interval 2000 inactive_time 01:00

The wait interval is expressed in hundredths of seconds in the example and causes the monitor to wait 20 seconds between each memory check. If the monitor has checked for 1 hour (format HH:MM) and the Extract is still inactive, then the monitor will shut down after releasing the shared memory. If the Extract returns to an active state during that hour, the monitor will reset its state and continue monitoring.

The wait_interval can have values from 100 to 6000 and the default is 1000. The inactive_time can be from 00:10 to 12:00 and the default is 00:30. If the monitor does not start properly, the Extract displays a warning message in the Extract report and the Extract continues the processing. The Extract will attempt to release ECSA memory when it shuts down.

The remote memory parameter has three options to make this feature work. The syntax for these parameters is:

task_procedure proc name
task_library proc library
task_setup task setup program

Example:

remote_memory_options task_procedure OGGPR001 
remote_memory_options task_library TEST.PROCLIB
remote_memory_options task_setup OGGJT001

You may specify multiple options in a single command, as shown below:

remote_memory_options task_procedure OGGPR001 task_library TEST.PROCLIB task_setup OGGJT001

Note:

The values for the remote memory parameter are case insensitive.

The default values are procedure name OGGPR001 and the task setup program OGGJT001. There is no default for task library as the procedure might be installed in one of the MVS system default procedure libraries. The task library parameter is only needed if the procedure is not in a system default library.

The memory task will start with a simple JOB card and an EXEC procedure name with parameters passed from the Extract. Some z/OS systems may require various other parameters on the job card. The JOB parameters can also be modified using the remote memory parameter, as shown in the example given below.

remote_memory_options task_jobname [valid MVS job name (see below)]
remote_memory_options task_acct_info [valid MVS acct value ( see below)]
remote_memory_options task_programmer [valid MVS programmer name, Can use single quotes]
remote_memory_options task_class [valid MVS job class A to Z or 0 to 9]
remote_memory_options task_msgclass [valid MVS msgclass A to Z or 0 to 9]
remote_memory_options task_msglevel [valid MVS message level n or (,n) or (n,n)  n=valid digit]
remote_memory_options task_priority [valid MVS priority 0-15]

You can specify the JOB name using two valid characters and an asterisk, such as AA*. The default JOB name is GG*. The asterisk is replaced by six random numbers when it is specified. Otherwise, if you specify a one to eight byte character name, it must be a valid MVS job name.

Specify account values in any of the following valid MVS formats:

OTXI
‘MY ACCT’
(ACCT,1234,ABC)

For parameters, like acct_info and programmer, that allow special characters, you must enclose those in single quotes. In addition, the MVS rules about using double single quotes or ampersands within quotes continue to apply. The Extract does minimal validation for these parameters and leaves the complete validation to the MVS process. Extract will accept the first one if you specify duplicate parameters and ignore any duplicates.

A sample procedure JCL file will be included in the zOSPrograms.zip file. The JCL has the following format:

//*==================================================================== 
//* EXAMPLE JCL FOR RUNNING THE COMMON MEMORY MONITOR PROCEDURE
//* ADDRESS SPACE NEEDING AN AUTHORIZED LOAD LIBRARY
//* NOTE: THE PROGRAM OGGMT001 CAN BE RENAMED IN THE LIBRARY BUT THE
//*       NEW NAME MUST MATCH THE PROGRAM NAME IN THIS JCL
//*==================================================================== 
//OGGDSNNA PROC RGN=0K TR=,EX=,MEM=,LEN=,SEC=,DUR=,VER=
//OGGDSNNX EXEC PGM=OGGMT001,REGION=&RGN,TIME=NOLIMIT,
// PARM='&TR &EX &MEM &LEN &SEC &DUR &VER'
//*-------------------------------------------------------------------- 
//* REPLACE &PREFIX.**.AUTHLOAD LIBRARIES WITH SITE SPECIFIC FILE(S)
//* ALSO REPLACE THE CEE LIBRARY WITH SITE SPECIFIC FILE
//* DSNN COULD REPRESENT A DB2 SPECIFIC LOAD LIBRARY IF ONE EXISTS
//*-------------------------------------------------------------------- 
//STEPLIB  DD DISP=SHR,DSN=&PREFIX..WLMDSNN.USER.AUTHLOAD
//         DD DISP=SHR,DSN=CEE.SCEERUN
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*

Modify the libraries marked with PREFIX so that they work in your system. If you renamed the program OGGMT001 you copied from the zOSPrograms.tar file, you must change it in the JCL. The null parameters on the PROC statement are there for information purposes. The job setup program supplies those values using information passed from the Extract. You may also specify as many step library dataset names as required. The JCL procedure supplied in the zOSPrograms.tar file gives an example using more than one step library.

Parent topic: Requirements for Installing Oracle GoldenGate for DB2 z/OS

Requirements for Installing Oracle GoldenGate for MySQL

Learn the prerequisites for installing Oracle GoldenGate for a MySQL database.

Topics:

Parent topic: Database Requirements

Supported Databases

Oracle GoldenGate for MySQL supports capture and delivery for MySQL, Oracle MySQL Database Service, Amazon Aurora MySQL, Amazon RDS for MariaDB, Amazon RDS for MySQL, Azure Database for MySQL, and MariaDB.

For supported database versions, review the Certification Matrix.

Limitations of Support

Parent topic: Requirements for Installing Oracle GoldenGate for MySQL

Limitations of Support

Following are the limitations of support for Oracle GoldenGate for MySQL:

MySQL databases enabled with binary log transaction compression are not supported with Oracle GoldenGate Extract.
MySQL databases enabled with binary log encryption are not supported with Oracle GoldenGate Extract.

Parent topic: Supported Databases

Database Storage Engine

Requirements for the database storage engine are as follows:

Oracle GoldenGate supports the InnoDB storage engine for a source MySQL database.
All the components of Oracle GoldenGate for MySQL, including Extract, Replicat, and GGSCI connect to the database using the MySQL native API.
Oracle GoldenGate supports capture and apply from and to the InnoDB engine. Apply to MyISAM engine works, but there might be data integrity issues as MyISAM engine in non-transactional.

Parent topic: Requirements for Installing Oracle GoldenGate for MySQL

Database Character Set

MySQL provides a facility that allows users to specify different character sets at different levels.

Level	Example
Database	create database test charset utf8;
Table	create table test( id int, name char(100)) charset utf8;
Column	create table test ( id int, name1 char(100) charset gbk, name2 char(100) charset utf8));

Limitations of Support

When you specify the character set of your database as utf8mb4/utf8, the default collation is utf8mb4_unicode_ci/utf8_general_ci. If you specify collation_server=utf8mb4_bin, the database interprets the data as binary. For example, specifying the CHAR column length as four means that the byte length returned is 16 (for utf8mb4) though when you try to insert data more than four bytes the target database warns that the data is too long. This is the limitation of database so Oracle GoldenGate does not support binary collation. To overcome this issue, specify collation_server=utf8mb4_bin when the character set is utf8mb4 and collation_server=utf8_bin for UTF-8.
The following character sets are not supported:
- armscii8
- keybcs2
- utf16le
- geostd8

Parent topic: Requirements for Installing Oracle GoldenGate for MySQL

Other Programs and Settings for MySQL

Oracle GoldenGate 21c for MySQL is packaged with MySQL client libraries 8.0.26 and requires OpenSSL 1.1.1 be installed on the Oracle GoldenGate server.

If Oracle GoldenGate is installed on a MySQL 8.0 (versions less than 8.0.34) database server, then add the MySQL installation’s home\bin directory to the PATH or LD_LIBRARY_PATH environment variable as shown.

For Linux:
```
export LD_LIBRARY_PATH=mysql_home/bin:$PATH
```
For Windows:
```
set PATH=mysql_home\bin;%PATH%
```
If Oracle GoldenGate is installed on a MySQL (versions 5.7, 8.0.34+) or MariaDB database server, or installed on a hub server, then install OpenSSL 1.1.1 and add its installation location to the PATH or LD_LIBRARY_PATH environment variable.

This is required for both Linux and Windows systems and the environment variable must include the directory containing the following files:

libssl.so.10 and libcrypto.so.10 files for Linux systems
libcrypto-1_1-x64.dll and libssl-1_1-x64.dll files for Windows systems

OpenSSL 1.1.1 binaries are available through openssl.org or by installing a MySQL 8.0 product that includes the OpenSSL 1.1.1 libraries, such as Connector/ODBC 8.0 version 8.0.33.

Parent topic: Requirements for Installing Oracle GoldenGate for MySQL

Requirements for Installing Oracle GoldenGate for Oracle Database

Learn about the requirements for installing Oracle GoldenGate on Oracle database. These apply to both capture modes unless explicitly noted.

Ensure that your database has minimal supplemental logging enabled.
Database user privileges and configuration requirements are explained in Establishing Oracle GoldenGate Credentials in Using Oracle GoldenGate for Oracle Database.
If the database is configured to use a bequeath connection, the sqlnet.ora file must contain the bequeath_detach=true setting.
Oracle Databases must be in ARCHIVELOG mode so that Extract can process the log files.
It is highly recommended to use the FORCE LOGGING mode on the database side, or on the specific tablespace of the replicated tables, to ensure that all transactional data is written to redo logs.

Topics:

Setting TNS_ADMIN

Parent topic: Database Requirements

Setting TNS_ADMIN

The TNS_ADMIN environment variable contains the path to the TNS files.

It is recommended (but not required) to set the environment variable TNS_ADMIN. If this environment variable is not set, then Oracle GoldenGate looks for the $HOME/.tnsnames.ora or /etc/tnsnames.ora file. In addition, the environment variable must be set before starting the Admin Client or GGSCI. Otherwise, this variable is not detected.

If you are not using TNS_ADMIN, then you can use connection qualifiers such as (DESCRIPTION=(ADDRESS=( ...)), with TNS aliases.

A preferred technique for configuring database connections is using the EZconnect syntax. You need the username, password, hostname, port number, and service name connection information to use the EZConnect syntax.

Syntax that you need to specify in the User ID field: username@hostname:port/service_name

Here's an example for setting the User ID with EZConnect: c##ggadmin@dc.example.com:1521/dc1.example.com

Parent topic: Requirements for Installing Oracle GoldenGate for Oracle Database

Requirements for Installing Oracle GoldenGate for PostgreSQL

Learn the prerequisites for installing Oracle GoldenGate for a PostgreSQL database.

Also see the post-installation instructions for installing the DataDirect driver for PostgreSQL in Classic Architecture at Post-installation Tasks. These instructions are required for installing the DataDirect driver for Linux operating system after completing the installation.

Topics:

Parent topic: Database Requirements

Prerequisites for Installing Oracle GoldenGate for PostgreSQL

PostgreSQL libpq Module

For Oracle GoldenGate installations beginning with release 21.6.0 and after, required PostgreSQL libpq libraries are now included in the Oracle GoldenGate installation package and do not need to be installed separately.

For Oracle GoldenGate installations prior to release 21.6.0, PostgreSQL libpq libraries need to be manually installed where Oracle GoldenGate is to be installed. The steps to install the correct libpq module when running Oracle GoldenGate versions prior to release 21.6.0 are:

Note:

It is highly recommended to patch Oracle GoldenGate to the most recent patch available on the support.oracle.com page. If you plan to install the base release 21.3 (GA release) immediately followed by the release 21.6 patch or later, then there is no need to install the PostgreSQL libpq module separately.

Installing the PostgreSQL libpq Module

The steps to install the PostgreSQL libpq module are:

Follow the steps to install the PostgreSQL package, available at: https://www.postgresql.org/download/
Select the Linux operating system family and Red Hat/Rocky/CentOS Linux distribution from the Packages and Installers drop-down list.
Select the highest PostgreSQL version that is supported with Oracle GoldenGate.
Select the platform on which Oracle GoldenGate is to be installed, such as Red Hat Enterprise, Rocky, or Oracle version 8.
Last, select the architecture as x86_64 from the Architecture drop-down list.

This will provide the PostgreSQL setup scripts needed to install the required package(s).

Install the repository RPM and the libs module. The sample code is given below:

# Install the repository RPM: sudo dnf install -y

https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# Disable the built-in PostgreSQL module:

sudo dnf -qy module disable postgresql

# Install PostgreSQL libs module:

sudo dnf install -y postgresql14-libs

Database Software for Capture

To capture from a PostgreSQL database, Oracle GoldenGate requires the test_decoding database plug-in be installed for the database. This plug-in might not have been installed by default when the database was installed.

Ensure that the postgresqlversion#-contrib package is installed on the database server, as shown in the example:

sudo yum install postgresql14-contrib

Parent topic: Requirements for Installing Oracle GoldenGate for PostgreSQL

Other Programs and Settings

Additional requirements for PostgreSQL are listed in this topic.

Configure the LD_LIBARY_PATH and OGG_HOME environment variables prior to installing Oracle GoldenGate.

Note:

It is highly recommended to patch Oracle GoldenGate to the most recent patch available on support.oracle.com/. If you plan to install the base release 21.3 (the GA release) immediately followed by a patched version, then perform the steps given below to set the environment variables based on the final patch version that you will install.

For Oracle GoldenGate installations prior to release 21.6.0, set the following environment variables before installing Oracle GoldenGate:
1. OGG_HOME – The planned Oracle GoldenGate installation path.
2. LD_LIBARY_PATH – Includes the $OGG_HOME/lib and PostgreSQL libpq directories.
  
  Example:
  
  export OGG_HOME=<GoldenGate_Installation_Path>
  
  export LD_LIBRARY_PATH=$OGG_HOME/lib:/usr/pgsql-14/lib

For Oracle GoldenGate installations of release 21.6.0 and after, set the following environment variables before installing Oracle GoldenGate:
1. OGG_HOME – The planned Oracle GoldenGate installation path.
2. LD_LIBARY_PATH – Includes the $OGG_HOME/lib directory.
  
  Example:
  
  export OGG_HOME=<GoldenGate_Installation_Path>
  
  export LD_LIBRARY_PATH=$OGG_HOME/lib

When installing Oracle GoldenGate on a remote server (one different from where the database is running), set the remote server's time and time zone to that of the source database server so that Oracle GoldenGate Extract can correctly position by time when creating the Extract with the BEGIN option, otherwise, position by a valid LSN value.

Parent topic: Requirements for Installing Oracle GoldenGate for PostgreSQL

Requirements for Installing Oracle GoldenGate for NonStop SQL/MX

The operating database requirements for running Oracle GoldenGate for NonStop SQL/MX are:.

On a source SQL/MX system, the Extract process uses a program named VAMSERV to capture transaction data from the audit trails. This program is placed into the installation subvolume when you install Oracle GoldenGate for NonStop SQL/MX. You will be prompted to install VAMSERV in the installation instructions in this guide.
Oracle GoldenGate uses ODBC/MX to connect to the SQL/MX database. You may need to FUP DUP the ODBC/MX driver DLL to a location where the operating system will find it. This step is required every time the operating system is compiled, in case the new operating system includes a new version of the ODBC/MX.

Parent topic: Database Requirements

Requirements for Installing Oracle GoldenGate for SQL Server

To operate with SQL Server databases, Oracle GoldenGate supports the following instance, database, and other configurations.

Parent topic: Database Requirements

Prerequisites for Installing Oracle GoldenGate Microservice Architecture for SQL Server

Open a terminal session and using Microsoft’s RedHat Enterprise Server installation instructions for adding the ODBC Drivers for Linux, perform the following steps with default values. Respond with 'y' when prompted.

sudo su #RedHat Enterprise Server 7
curl https://packages.microsoft.com/config/rhel/7/prod.repo > 
/etc/yum.repos.d/mssql-release.repo 
exit

sudo yum remove unixODBC-utf16 unixODBC-utf16-devel #to avoid conflicts
sudo ACCEPT_EULA=Y yum install msodbcsql17
sudo ACCEPT_EULA=Y yum install mssql-tools
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bash_profile
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
source ~/.bashrc

Parent topic: Requirements for Installing Oracle GoldenGate for SQL Server

SQL Server Supported Versions

Certified versions of SQL Server can be found on the published certification matrix available for each release of Oracle GoldenGate, which is available at the following link:

https://www.oracle.com/middleware/technologies/fusion-certification.html

Oracle GoldenGate Extract supports Enterprise Edition and some versions of SQL Server Standard Edition. Review the Exceptions and Additonal Information column of the certification matrix to see the details of which Standard Edition versions of SQL Server are supported for Extract.

Oracle GoldenGate Delivery supports both SQL Server Enterprise and Standard editions.

Oracle GoldenGate supports remote capture and delivery for Azure SQL Database Managed Instance and remote delivery for Azure SQL Database.

Oracle GoldenGate supports remote capture and delivery for Amazon RDS for SQL Server.

Parent topic: Requirements for Installing Oracle GoldenGate for SQL Server

Other Programs and Settings

Observe the following program and settings information for Oracle GoldenGate for SQL Server:

Install the Microsoft ODBC Driver 17 for the operating system where Oracle GoldenGate is to be installed:

https://docs.microsoft.com/en-us/sql/connect/odbc/download-odbc-driver-for-sql-server?view=sql-server-2017

Note:
Do not install the Microsoft ODBC Driver 18 as it is not supported by Oracle GoldenGate.

When installing Oracle GoldenGate on Linux, follow the instructions for installing Microsoft ODBC Driver 17 for SQL Server on Linux and MAC OS, available at https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-2017#17, refer to the content listed under the RedHat Enterprise Server section.
Installation of the Oracle GoldenGate CDC cleanup task for Classic Architecture installation requires the Microsoft sqlcmd Utility. Download instructions for Windows and Linux systems can be found at:

https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-ver15
To install capture on a remote Linux or Windows server, set the remote server's time and time zone to that of the database server, or use LSN based positioning for the Extract.

Installing Microsoft ODBC Drivers for Linux

Parent topic: Requirements for Installing Oracle GoldenGate for SQL Server

Installing Microsoft ODBC Drivers for Linux

For Oracle GoldenGate installed on Linux, the Microsoft ODBC. The following tasks are required to install the Linux drivers.

(Oracle GoldenGate Marketplace only) Edit the file /etc/passwd, to grant temporary shell access to the root user.
```
$ sudo vi /etc/passwd
```
(Oracle GoldenGate Marketplace only) In the file /etc/passwd, change the value for the root user from /usr/sbin/nologin to /bin/bash. Save and close the file.

Using Microsoft’s RedHat Enterprise Server installation instructions for adding the ODBC Drivers for Linux, perform the following steps with default values by answering 'y' when prompted.

$ sudo su

$ #RedHat Enterprise Server 7
$ curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/mssql-release.repo

$ exit
$ sudo yum remove unixODBC-utf16 unixODBC-utf16-devel #to avoid conflicts
$ sudo ACCEPT_EULA=Y yum install msodbcsql17
$ sudo ACCEPT_EULA=Y yum install mssql-tools
$ echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bash_profile
$ echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
$ source ~/.bashrc

(Oracle GoldenGate Marketplace only) After installing the Linux drivers, you can reset the original shell access values for the root user.
```
$ sudo vi /etc/passwd
```
(Oracle GoldenGate Marketplace only) Change the value for the root user from /bin/bash to /usr/sbin/nologin. Save and close the file.

Parent topic: Other Programs and Settings

Where to Install Oracle GoldenGate

Oracle GoldenGate for SQL Server must be installed on a supported operating system as per the Certification Matrix, and can be installed on the database server itself or on an application hub server, based on your preference.

Parent topic: Requirements for Installing Oracle GoldenGate for SQL Server

Requirements for Installing Oracle GoldenGate for Teradata

Learn the prerequisites for installing Oracle GoldenGate for a Teradata database.

Topics:

Parent topic: Database Requirements

Supported Platforms for a Replication Server

In a Teradata environment, you install Oracle GoldenGate on a server that is separate from the one where the Teradata target databases are installed. This machine will be the replication server and must be a platform that is supported by Oracle GoldenGate for the Teradata database.

Parent topic: Requirements for Installing Oracle GoldenGate for Teradata

Operating System Privileges for Teradata

The Manager process requires an operating system user that has privileges to control Oracle GoldenGate processes and to read, write, and purge files and subdirectories in the Oracle GoldenGate directory. The Replicat processes require privileges to access the database.

Parent topic: Requirements for Installing Oracle GoldenGate for Teradata

Installing ODBC Drivers for Teradata

Install a supported Teradata ODBC driver based on the database version and operating system where Oracle GoldenGate will be installed. Use the following link to find the available Teradata ODBC drivers:

https://downloads.teradata.com/download/connectivity

Review the README instructions provided by Teradata and complete the required driver installation steps.

Parent topic: Requirements for Installing Oracle GoldenGate for Teradata

Requirements for Installing Oracle GoldenGate for TimesTen

Learn the prerequisites for installing Oracle GoldenGate for a TimesTen database.

Topics:

System Requirements and Preinstallation Instructions
This chapter contains the requirements for the system and database resources that support Oracle GoldenGate.

Parent topic: Database Requirements

System Requirements and Preinstallation Instructions

This chapter contains the requirements for the system and database resources that support Oracle GoldenGate.

Topics:

Parent topic: Requirements for Installing Oracle GoldenGate for TimesTen

Supported Database Architectures

Oracle GoldenGate for Oracle TimesTen supports the Classic and Scaleout architectures of the TimesTen database.

Parent topic: System Requirements and Preinstallation Instructions

Supported Platforms and Database Versions

Oracle TimesTen supports installing Oracle GoldenGate on Linux.

For supported platform and database version information, review the certification matrix:

https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html.

Parent topic: System Requirements and Preinstallation Instructions

Oracle TimesTen Software Installation

The Oracle TimesTen Client needs to be installed on the server where Oracle GoldenGate is going to be installed. If Oracle GoldenGate is installed on the Oracle TimesTen database server, then the required components are already available. However, if you are installing Oracle GoldenGate on a hub server, then you must separately install the Oracle TimesTen Client.

In both cases you will need to configure the ODBC connection information.

For Linux platforms there is only one TimesTen software distribution that provides both server and client components. To download the Oracle TimesTen Software, visit:

https://www.oracle.com/database/technologies/timesten-downloads.html

Before beginning to install Oracle GoldenGate with Oracle TimesTen, you must also set the LD_LIBRARY_PATH variable:

Download theTimesTen Scaleout and TimesTen Classic/Cache 18.x for Linux x86 (64-bit) build.
Extract the Oracle TimesTen installation files to the designated location, based on the instructions provided in Oracle TimesTen In-Memory Database Installation Guide.
Set the LD_LIBARY_PATH system variable to include the TimesTen installation’s lib directory. This system variable must be set to install and run Oracle GoldenGate. Example:
```
export LD_LIBRARY_PATH=/installpath/tt18.1.2.2.0/lib:$LD_LIBRARY_PATH
```

Parent topic: System Requirements and Preinstallation Instructions

Client-only Instance Creation

For non-database server environments where you plan to install Oracle GoldenGate, after installing the Oracle TimesTen client libraries, follow the TimesTen document instructions to create a client-only instance of TimesTen.

Perform the following:

[oracle@tt_installation_dir]$ ./tt18.1.2.1.0/bin/ttInstanceCreate -clientonly

Follow the instance installation prompts, taking note of where the TimesTen instance is installed. This information will be required when setting up a Replicat’s ODBC connection to TimesTen.
Set the TIMESTEN_HOME system variable to the TimesTen instance path.

Example:
```
export TIMESTEN_HOME=/instancepath/tt181
```

Parent topic: System Requirements and Preinstallation Instructions

Operating System Privileges

The operating system privileges for using Oracle GoldenGate for Oracle TimesTen are:

You need read and write privileges on the Oracle GoldenGate installation directory.
Oracle GoldenGate Replicat and Manager processes must operate as an operating system user that has privileges to read, write, and delete files and subdirectories in the Oracle GoldenGate directory. In addition, the Manager process requires privileges to control all other Oracle GoldenGate processes.
Dedicate the Replicat and Manager operating system users to Oracle GoldenGate to avoid access to sensitive information to other users who run Oracle GoldenGate processes.

Parent topic: System Requirements and Preinstallation Instructions

Database Requirements

This section describes the database requirements for using Oracle GoldenGate for Oracle TimesTen.

Database User for Oracle GoldenGate Processes

Parent topic: System Requirements and Preinstallation Instructions

Database User for Oracle GoldenGate Processes

Follow these requirements for the database user for Oracle GoldenGate processes:

Note:

Times Ten is only supported as a target.

Create a database user that is dedicated to Oracle GoldenGate. It can be the same user for all of the Oracle GoldenGate processes that must connect to a database:
- Replicat (target database)
- DEFGEN (target database)
To preserve the security of your data, and to monitor Oracle GoldenGate processing accurately, do not permit other users, applications, or processes to log on as, or operate as, the Oracle GoldenGate database user.
For Oracle GoldenGate to replicate to a target Oracle TimesTen database, grant SELECT, INSERT, UPDATE, and DELETE on all the target tables to the Replicat database user.
For creating heartbeat and checkpoint tables, grant CREATE TABLE to the Replicat database user.

Parent topic: Database Requirements