This chapter includes the following sections:
Make sure that you are installing your product on a supported hardware or software configuration. For more information, see the certification document for your release on the Oracle Fusion Middleware Supported System Configurations page.
Oracle has tested and verified the performance of your product on all certified systems and environments; whenever new certifications occur, they are added to the proper certification document right away. 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.
This section describes operating system requirements.
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 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 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, 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 Reference for Oracle GoldenGate for Windows and UNIX.
Assign the following free disk space:
To determine the size of the Oracle GoldenGate download file, view the Size column before downloading your selected build from Oracle Software Delivery Cloud. The value shown is the size of the files in compressed form. The size of the expanded Oracle GoldenGate installation directory will be significantly larger on disk. For more information, see Section 2.3, "Understanding and Obtaining the Oracle GoldenGate Distribution."
Allow at least an additional 1 GB of disk space on any system that hosts Oracle GoldenGate trails, which are files that contain the working data. 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 the guidelines for sizing trails in Administering Oracle GoldenGate for Windows and UNIX.
By default, Oracle GoldenGate maintains data that it swaps to disk in the
dirtmp sub-directory of the Oracle GoldenGate installation directory. The cache manager assumes that all of the free space on the file system is available. 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. You can assign a name and size to this directory with the
CACHEDIRECTORY option of the
CACHEMGR parameter. The
CACHESIZE option of
CACHEMGR sets a soft limit for the amount of virtual memory (cache size) that is available for caching transaction data. See Reference for Oracle GoldenGate for Windows and UNIX for the default values of these options and detailed explanations, in case system adjustments need to be made.
The following network resources must be available to support Oracle GoldenGate.
Configure the system to use TCP/IP 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. Host names are easier to use.
Oracle GoldenGate requires some unreserved and unrestricted TCP/IP ports, the number of which depends on the number and types of processes in your configuration. See the Administering Oracle GoldenGate for Windows and UNIX 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. You will specify them with parameters when configuring the Manager process.
Configure your firewalls to accept connections through the Oracle GoldenGate ports.
The following are the privileges in the operating system that are required to install Oracle GoldenGate and to run the processes.
To install on Windows, the person who installs Oracle GoldenGate must log in as Administrator.
To install on Windows, the person who installs Oracle GoldenGate must log in as Administrator.
To install on UNIX, the person who installs Oracle GoldenGate must have read and write privileges on the Oracle GoldenGate installation directory.
The Oracle GoldenGate Extract, 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 the other Oracle GoldenGate processes.
Dedicate the Extract, Replicat, and Manager operating system users to Oracle GoldenGate.
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:
If the characters do not display correctly after setting the code page, try changing the console font to Lucida Console, which has an extended character set.
The following are additional considerations in support of Oracle GoldenGate.
Before installing Oracle GoldenGate on a Windows system, install and configure the Microsoft Visual C ++ 2010 SP1 Redistributable Package. Make certain it is the SP1 version of this package, and make certain to get the correct bit version for your server. This package installs runtime components of Visual C++ Libraries. For more information, and to download this package, go to
Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.
This section describes database requirements.
The Oracle GoldenGate Extract process calls the
DB2READLOG function in the Administrative API to read the transaction log files of a DB2 LUW source database. In addition to
DB2READLOG, Extract uses a small number of other API routines to check the source database configuration on startup.
The Oracle GoldenGate Replicat process uses the DB2 CLI interface on a DB2 LUW target database. For instructions on installing this interface, see the DB2 documentation.
The database can reside on a different server from the one where Oracle GoldenGate is installed, so long as the database is defined locally. For example, the following enables you to use database
mydb locally with data that is on
catalog tcpip node abc123 remote abc123.us.mycompany.com server 00000catalog db mydb as abc123 at node abc123 AUTHENTICATION server
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:
Extract (source database)
Replicat (target database)
DEFGEN (source or 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. It is recommended that you store the login credentials in an Oracle GoldenGate credential store. The credential store makes use of local secure storage for the login names and passwords, and permits you to specify only an alias in the Oracle GoldenGate parameter files. For more information about this option, as well as alternative security options, see Administering Oracle GoldenGate for Windows and UNIX.
Assign system administrator (
SYSADM) or database administrator (
DBADM) authority to the database user under which Extract runs. To give the Extract user
DBADM authority, a user with
SYSADM authority can issue the following grant statement.
GRANT DBADM ON DATABASE TO USER user
This authority can also be granted from the
User and Group Objects folder in the DB2 Control Center. The database tab for the user that is assigned to an Oracle GoldenGate process should have the Database Administrative Authority box checked.
Note:If the Extract user 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]
Grant at least the following privileges to the database user under which Replicat runs:
CONNECT to the target database
SELECT on the system catalog views
DELETE on the target tables
Oracle GoldenGate supports all DB2 LUW data types, except those listed in Non-Supported DB2 LUW Data Types.
Oracle GoldenGate supports multi-byte character data types and multi-byte data stored in character columns. Multi-byte data is only supported in a like-to-like configuration. Transformation, filtering, and other types of manipulation are not supported for multi-byte character data.
CLOB columns must have a
LOGGED clause in their definitions.
VARGRAPHIC columns must be in a database where the character set is UTF16. Any other character set causes the Oracle GoldenGate to abend.
The support of range and precision for floating-point numbers depends on the host machine. In general, the precision is accurate to 16 significant digits, but you should review the database documentation to determine the expected approximations. Oracle GoldenGate rounds or truncates values that exceed the supported precision.
Extract fully supports the capture and apply of
TIMESTAMP(9). Extract also captures
TIMESTAMP(12), but it truncates the data to nanoseconds (maximum of nine digits of fractional time) and issues a warning to the error log. Replicat truncates timestamp data from other sources to nanoseconds when applying it to
TIMESTAMP(12) in a DB2 LUW target.
Oracle GoldenGate supports timestamp data from 0001/01/03:00:00:00 to 9999/12/31:23:59:59. If a timestamp is converted from GMT to local time, these limits also apply to the resulting timestamp. Depending on the timezone, conversion may add or subtract hours, which can cause the timestamp to exceed the lower or upper supported limit.
Oracle GoldenGate does not support the filtering, column mapping, or manipulation of large objects that are larger than 4K. Full Oracle GoldenGate functionality can be used for objects that are 4K or smaller.
Replication of XML columns between source and target databases with the same character set is supported. If the source and target database character sets are different, then XML replication may fail with a database error because some characters may not be recognized (or valid) in the target database character set.
Oracle GoldenGate supports the maximum number of columns and column size per table that is supported by the database.
TRUNCATE TABLE for DB2 LUW version 9.7 and later.
Multi Dimensional Clustered Tables (MDC) for DB2 LUW 9.5 and later.
Materialized Query Tables. Oracle GoldenGate does not replicate the MQT itself, but only the base tables. The target database automatically maintains the content of the MQT based on the changes that are applied to the base tables by Replicat.
ROW COMPRESSION. In DB2 LUW version 10.1 and later,
COMPRESS YES STATIC is supported and
COMPRESS YES ADAPTIVE are supported. To support
COMPRESS YES in DB2 LUW versions 9.7 and earlier, the
TRANLOGOPTIONS parameter with the
ALLOWTABLECOMPRESSION option must be used, and the compressed table cannot contain LOBs.
Extended row size feature is enabled by default. It is supported with a workaround using
FETCHCOLS. For any column values that are
VARGRAPHIC data types and are stored out of row in the database, you must fetch these extended rows by specifying these columns using the
FETCHCOLS option in the
TABLE parameter in the extract parameter file. With this option set, when the column values are out of row then Oracle GoldenGate will fetch its value. If the value is out of and
FETCHCOLS is not specified then Extract will abend to prevent any data loss. If you do not want to use this feature, set the
extended_row_size parameter to
Temporal tables with DB2 LUW 10.1 FixPack 2 and greater are supported. This is the default for Replicat.
Limitations on Automatic Heartbeat Table support are as follows:
Oracle GoldenGate heartbeat parameters frequency and purge frequency are accepted in seconds and days. However, the DB2 LUW task scheduler accepts its schedule only in cron format so the Oracle GoldenGate input value to cron format may result in some loss of accuracy. For example:
ADD HEARTBEATTABLE, FREQUENCY 150, PURGE_FREQUENCY 20
This example sets the
FREQUENCY to 150 seconds, which is converted to the closest minute value of 2 minutes, so the heartbeat table is updated every 120 seconds instead of every 150 seconds. Setting
PURGE_FREQUENCY to 20 means that the history table is purged at midnight on every 20th day.
The following are steps are necessary for the heartbeat scheduled tasks to run:
DB2_ATS_ENABLE registry variable to
SYSTOOLSPACE tablespace if it does not already exist:
CREATE TABLESPACE SYSTOOLSPACE IN IBMCATGROUP MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 4
Ensure instance owner has Database administration authority (DBADM):
GRANT DBADM ON DATABASE TO
Schema, table or column names that have trailing spaces.
Multiple instances of a database
Extraction or replication of DDL (data definition language) operations
Generated columns (
GENERATE ALWAYS clause).
Row size support. This feature is enabled by default in DB2 LUW 10.5 and later, but must be disabled to support Oracle GoldenGate.
Note:To include tables with non-supported types of table compression in the Oracle GoldenGate configuration, deactivate the non-supported compression and then reorganize the tables; otherwise, exclude them from the Oracle GoldenGate configuration.
For a list of characters that are supported in object names, see Administering Oracle GoldenGate for Windows and UNIX.