This chapter contains the following sections:
To find out which Oracle GoldenGate builds are available for a specific combination of database version and operating system, log onto
http://support.oracle.com and select the Certifications tab. 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.
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, "Downloading Oracle GoldenGate."
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. For details on how to configure the Manager process to handle the required ports, see Administering Oracle GoldenGate for Windows and UNIX.
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 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.
The Extract process must operate as an operating system user that has read access to the transaction log files, both online and archived. If you install the Manager process as a Windows service during the installation steps in this documentation, you must install as Administrator for the correct permissions to be assigned. If you cannot install Manager as a service, assign read access to the Extract process manually, and then always run Manager and Extract as Administrator.
Dedicate the Extract, Replicat, and Manager operating system users to Oracle GoldenGate. Sensitive information might be available to anyone who runs an Oracle GoldenGate process.
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 GoldenGate fully supports virtual machine environments created with any virtualization software on any platform. When installing Oracle GoldenGate into a virtual machine environment, select a build that matches the database and the operating system of the virtual machine, not the host system.
This section contains Oracle GoldenGate requirements that are specific to the Sybase database.
The Extract process makes calls directly to the Sybase Replication API on a source Sybase server. The source database on this server must be configured as follows to support data capture by Oracle GoldenGate.
DSQUERY variable to the server that contains the database that Oracle GoldenGate will be using.
Because Extract uses the Sybase LTM to read the Sybase transaction log, it cannot run if Sybase RepServer is running on the same database. Only one process at a time can reserve a context that allows it to read the transaction log on the same database.
The Extract process must be permitted to manage the secondary log truncation point. For more information, see Section 3.2.3, "Initializing the Secondary Truncation Point".
The source replication server must be an active database. Oracle GoldenGate cannot capture from a database that is in warm standby mode.
Configure the database page size to 4k, 8k,16k, 32k, or larger. If you configure a 2k database page size and attempt to create the GoldenGate
UpgradeCheckpoint table, the database errors.
Oracle GoldenGate requires a database user account. Create this account and assign privileges according to the following guidelines.
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, or operate as, the Oracle GoldenGate database user.
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 utility (source or target database)
The Extract process requires permission to access the source database. Do one of the following:
Grant System Administrator privileges.
Assign a user name with
replication_role . The command to grant replication role is either:
sp_role 'grant', replication_role, Extract_user
use dbname grant role replication_role to Extract_user
Note:Specific DDL or DML operations may require the use of both
The Replicat process requires connect and DML privileges on the target database.
This section lists the Sybase data types that Oracle GoldenGate supports and any limitations of this support.
INT (signed and unsigned)
TINYINT (signed and unsigned)
SMALLINT (signed and unsigned)
DECIMAL (fixed-point) are supported with no integrity loss when moving data to a target column of the same data type without involving calculations or transformation. When calculations or transformation must be performed, Oracle GoldenGate supports a maximum value of a signed long integer (32-bits).
BIT is supported for automatic mapping between Sybase databases. To move
BIT data between Sybase and another database type, Oracle GoldenGate treats
BIT data as binary. In this case, the following are required:
BIT column must be mapped to the corresponding source or target column with a
COLMAP clause in a
For ASE 15.7, these data types cannot be replicated:
BIGINT (as a key column)
TINYINT and Extract is not in the same version of Replicat, you will need to create a
targetdef file even if you are replicating between identical Sybase versions.
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.
These data types are supported to the maximum length supported by the database, this being the maximum page size.
NVARCHAR replication results using the Sybase
datalength functions when a Sybase database is the target and the source is a heterogenous database and you replicate from the source to the target may result in a data integrity issue. This occurs when you use a Sybase release earlier than Adaptive Server Enterprise 15.5 for Windows x64 platform EBF 21262: 15.5 ESD #5.3.
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 time zone, conversion may add or subtract hours, which can cause the timestamp to exceed the lower or upper supported limit.
Oracle GoldenGate does not support negative dates.
IMAGE are supported up to 2 GB in length.
Large objects that are replicated from other databases (such as Oracle
CLOB) can be mapped to Sybase
VARBINARY columns. To prevent Replicat from abending if the replicated large object is bigger than the size of the target column, use the
DBOPTIONS parameter with the
ALLOWLOBDATATRUNCATE option in the Replicat parameter file. For more information, see Reference for Oracle GoldenGate for Windows and UNIX.
To move data to a Sybase target from a source database that permits empty
LOB columns, use the
DBOPTIONS parameter with the
EMPTYLOBSTRING option in the Replicat parameter file. This parameter accepts a string value and prevents Replicat from setting the target column to
NULL, which is not permitted by Sybase. For more information, see Reference for Oracle GoldenGate for Windows and UNIX.
When a source table contains multiple identical rows, it can cause
LOB inconsistencies in the target table. This occurs when the source table lacks a primary key or other unique row identifier. The rows are inserted by Replicat on the target, but if the
LOB data is updated in a subsequent source operation, it will only be replicated to the first row that was inserted on the target.
Do not use
NOT NULL constraints on the in-row LOB column. If you want to use
NOT NULL constraints, use them on the off-row LOB column.
If you need to fetch the in-row LOB data directly from the table you must use
Oracle GoldenGate for Sybase 15.7 does not support the in-row LOB column replication (however, it can still push the data into the in-row LOB column at in the Replicat database). This means tables included in the replication cannot have any in-row LOB columns. Oracle GoldenGate will abend if any replication table includes an in-row LOB column. If you need in-row LOB support, contact Oracle Support for further information.
Money data types are supported with no integrity loss when moving data to a target column of the same data type without involving calculations or transformation. When calculations or transformation must be performed, Oracle GoldenGate supports a maximum value of a signed long integer (32-bits).
IDENTITY data type is supported for replication in one direction only, but not for a bi-directional configuration.
This section lists the Sybase data types that Oracle GoldenGate does not support.
TIMESTAMP data is not supported. Timestamp columns must be excluded from Oracle GoldenGate because they are populated automatically by the database, which generates errors on the target if Replicat attempts to apply a replicated timestamp value. To exclude timestamp columns from being captured by Oracle GoldenGate, use the
COLSEXCEPT option of the
TABLE parameter. Because the system generates the timestamps, the source and target values will be different.
rowobject data type is not supported.
This section lists the data operations and database objects that Oracle GoldenGate supports.
Oracle GoldenGate supports the extraction and replication of insert, update, and delete operations on Sybase tables that contain rows of up to 512 KB in length.
Oracle GoldenGate supports the maximum number of columns and the maximum column size per table that is supported by the database.
Oracle GoldenGate supports deferred inserts, deferred indirect inserts, deferred updates, and deferred deletes. It is possible that the use of deferred updates could cause primary key constraint violations for the affected SQL on the target. If these errors occur, use the Replicat parameter
Oracle GoldenGate supports
TRUNCATE TABLE if the names of the affected tables are unique across all schemas. If the table names are not unique across all schemas, use the
IGNORETRUNCATES parameter for those tables to prevent Replicat from abending.
Oracle GoldenGate supports
IGNORETRUNCATES by Extract and Replicat.
Oracle GoldenGate supports data that is encrypted with a system-encrypted password.
Oracle GoldenGate supports array fetching during initial loads, as controlled by the
BATCHSQL Replicat feature of Oracle GoldenGate is supported on ASE 15.7 SP110 and greater on the following platforms:
Sun Solaris SPARC
Sun Solaris x64
The Sybase specific parameter
sybIgnoreConvError is not supported with
BatchSQL feature. In certain scenarios, the
CS_DECIMAL data types are not supported by
BatchSQL because of a bug in the Sybase specific CT Library. The
LOB data type is also not supported in
Oracle GoldenGate fully supports persisted computed columns. The change values are present in the transaction log and can be captured to the trail.
You cannot use
NOT NULL constraints on in-row LOB columns. If you need to use
NOT NULL constraints, do so only with off-row LOB columns.
Oracle GoldenGate supports tables with non-persisted computed columns, but does not capture change data for these columns because the database does not write it to the transaction log. To replicate data for non-persisted computed columns, use the
FETCHMODCOLS option of the
TABLE parameter to fetch the column data from the table. Keep in mind that there can be discrepancies caused by differences in data values between when the column was changed in the database and when Extract fetches the data for the transaction record that is being processed.
Replicat does not apply DML to any computed column, even if the data for that column is in the trail, because the database does not permit DML on that type of column. Data from a source persisted computed column, or from a fetched non-persisted column, can be applied to a target column that is not a computed column.
In an initial load, all of the data is selected directly from the source tables, not the transaction log. Therefore, in an initial load, data values for all columns, including non-persisted computed columns, gets written to the trail or sent to the target, depending on the method that is being used. As when applying change data, however, Replicat does not apply initial load data to computed columns, because the database does not permit DML on that type of column.
Oracle GoldenGate will not use a persisted computed column that is defined as a key column, an index column, or that is part of a
KEYCOLS clause in a
MAP statement. If a unique key or index includes a computed column and Oracle GoldenGate must use that key, the computed column will be ignored. Additionally, if a unique key or index contains a computed column and is the only unique identifier on the table, Oracle GoldenGate will use all of the columns except the computed column as an identifier to find the target row. Thus, the presence of a computed column in a key or index affects data integrity if the remaining columns do not enforce uniqueness. Note that Sybase does not support non-persisted computed columns as part of a key, and neither does Oracle GoldenGate.
For Oracle GoldenGate to support
TRUNCATE TABLE, all table names must be unique across all schemas within a given database.
This section lists the data operations and database objects that Oracle GoldenGate does not support.
Data that is encrypted with a user-defined password.
Extraction or replication of DDL (data definition language) operations.
Multi-Extract configuration. Only one Extract can reserve a context to read the Sybase transaction logs.
SHOWSYNTAX is supported in the
NODYNSQL is deprecated.
Table names that contain data with an underscore followed by some characters then a space (for example,
zzz_j ) is not supported. Oracle GoldenGate cannot process records containing this type of character string with GGSCI,
REPLICAT. Additionally, this type of data cannot be used with Oracle GoldenGate wildcard (*). If you do have this type of data in your table name, you must drop this kind of table name from your database, and then they restart the application to process and respect Oracle GoldenGate wildcard.