Documentation
Advanced Search


Installing and Configuring Oracle GoldenGate for Sybase

1 System Requirements and Preinstallation Instructions

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

This chapter contains the following sections:

1.1 Supported Platforms

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.

1.2 Operating System Requirements

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

1.2.1 Memory 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.

1.2.2 Disk Requirements

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.

1.2.3 Temporary Disk Requirements

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 to this directory with the CACHEDIRECTORY option of the CACHEMGR parameter.

1.2.4 Network Requirements

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.

1.2.5 Operating System Privileges

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.

1.2.6 Console Character Set

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 OS_character_set

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.

1.2.7 Other Programs

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 http://www.microsoft.com.

  • 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.

1.3 Database Requirements

This section contains Oracle GoldenGate requirements that are specific to the Sybase database.

1.3.1 Database Configuration

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.

  • Set the 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 will throw an error.

1.3.2 Database User for Oracle GoldenGate Processes

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
      

      Or

      use dbname grant role replication_role to Extract_user
      

    Note:

    Specific DDL or DML operations may require the use of both sa_role and replication_role.

  • The Replicat process requires connect and DML privileges on the target database.

1.4 Supported Sybase Data Types

This section lists the Sybase data types that Oracle GoldenGate supports and any limitations of this support.

1.4.1 Integers

  • BIGINT

  • BIT

  • DECIMAL

  • INT (signed and unsigned)

  • TINYINT (signed and unsigned)

  • NUMERIC

  • SMALLINT (signed and unsigned)

Limitations of Support

  • NUMERIC and 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:

    • The BIT column must be mapped to the corresponding source or target column with a COLMAP clause in a TABLE or MAP statement.

    • The BIT data must be converted by means of the NUMBIN Oracle GoldenGate column-conversion function.

  • For ASE 15.7, these datatypes cannot be replicated:

    • BIGINT (as a key column)

    • BIGDATETIME

    • BIGTIME

  • When replicating TINYINT and Extract is not in the same version of Replicat, you will need to create a sourcedef and/or targetdef file even if you are replicating between identical Sybase versions.

  • See also Section 1.5, "Non-Supported Sybase Data Types".

1.4.2 Floating-Point Numbers

  • DOUBLE

  • FLOAT

  • REAL

Limitations of Support

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.

1.4.3 Character Data

  • CHAR

  • NCHAR

  • NVARCHAR

  • VARCHAR

  • UNICHAR

  • UNIVARCHAR

Limitations of Support

These data types are supported to the maximum length supported by the database, this being the maximum page size.

1.4.4 Dates and Timestamps

  • BIGDATETIME

  • BIGTIME

  • DATE

  • DATETIME

  • SMALLDATETIME

  • TIME

Limitations of Support

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 negative dates.

1.4.5 Large Objects

  • BINARY

  • IMAGE

  • TEXT

  • UNITEXT

  • VARBINARY

Limitations of Support

  • TEXT, UNITEXT and IMAGE are supported up to 2 GB in length.

  • Large objects that are replicated from other databases (such as Oracle BLOB and CLOB ) can be mapped to Sybase CHAR , VARCHAR , BINARY , and 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 contraints, 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 FETCHCOLS/FETCHMODCOLS.

  • 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.

1.4.6 Money Types

  • MONEY

  • SMALLMONEY

Limitations of Support

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).

1.4.7 IDENTITY Type

The IDENTITY data type is supported for replication in one direction only, but not for a bi-directional configuration.

1.4.8 User-Defined Types

User-defined types are fully supported.

1.5 Non-Supported Sybase Data Types

The only Sybase data type that Oracle GoldenGate does not support TIMESTAMP.

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.

1.6 Supported Operations and Objects for Sybase

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 HANDLECOLLISIONS .

  • 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 data that is encrypted with a system-encrypted password.

  • Oracle GoldenGate supports array fetching during initial loads, as controlled by the FETCHBATCHSIZE parameter.

  • Oracle GoldenGate supports GETTRUNCATES and IGNORETRUNCATES by Extract and Replicat.

Limitations on Computed Columns

  • 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 contraints, 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 FETCHCOLS or 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 TABLE or 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.

1.7 Non-Supported Operations and Objects for Sybase

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.

  • The BATCHSQL feature of Oracle GoldenGate.

  • Multi-Extract configuration. Only one Extract can reserve a context to read the Sybase transaction logs.

  • Because SHOWSYNTAX is supported in the DYNSQL mode, NODYNSQL is deprecated.

Close Window

Table of Contents

Installing and Configuring Oracle GoldenGate for Sybase

Expand | Collapse