To find the most recent matrix of Oracle GoldenGate builds for specific combinations of database version and operating system, log onto
http://support.oracle.com and select the Certifications tab. For assistance, click Tips for Finding Certifications. An e-mail and password are required to enter this site.
This section outlines the operating system resources that are necessary to support Oracle GoldenGate.
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.
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 the guidelines for sizing trails in Administering Oracle GoldenGate for Windows and UNIX.
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.
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.
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 Administering Oracle GoldenGate for Windows and UNIX.
The following network resources must be available to support Oracle GoldenGate.
For optimal performance and reliability, especially in maintaining low latency on the target, use the fastest network possible and install redundancies at all points of failure.
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 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.
This section descibes the operating database requirements for running Oracle GoldenGate for NonStop SQL/MX.
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.
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 SQL/MX database)
Replicat (target SQL/MX database)
DEFGEN (source or target database)
Dedicate an NSK user (
groupID.userID ) or OSS alias userID to Oracle GoldenGate. This user requires the following access privileges at the SQL/MX data level:
Access privileges are granted through the SQL/MX command interface with a GRANT statement. For more information on the
GRANT command, see the SQL/MX documentation.
The SQL/MX data types supported by Oracle GoldenGate are:
SYSKEY values are not preserved on the target. The target database generates a new unique value.
Oracle GoldenGate does not support negative dates.
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.
The objects and operations supported by Oracle GoldenGate for SQL/MX are:
Oracle GoldenGate supports the extraction and replication of DML operations on tables that contain rows of up to 512 KB in length.
Oracle GoldenGate supports the maximum number and size of columns per table that is supported by the database.
Updates to primary keys are supported for SQL/MX version 3.2 and later.
The objects and operations that Oracle GoldenGate does not support for SQL/MX are:
Extraction or replication of DDL (data definition language) operations
Oracle GoldenGate parameters that involve fetching from the database, such as
NonStop SQL/MX distributed transactions