1. Oracle GoldenGate Classic Documentation
  2. Prepare
  3. Prepare Your Database for Oracle GoldenGate Classic Architecture
  4. Sybase
  5. Understanding What's Supported for Sybase
  6. Supported Operations and Objects for Sybase

Supported Operations and Objects for Sybase

This section lists the data operations and database objects that 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.

  • The maximum number of columns and the maximum column size per table that is supported by the database.

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

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

  • GETTRUNCATES and IGNORETRUNCATES by Extract and Replicat.

  • Data that is encrypted with a system-encrypted password.

  • Array fetching during initial loads, as controlled by the FETCHBATCHSIZE parameter.

  • The BATCHSQL Replicat feature on ASE 15.7 SP110 and later on the following platforms:

    • AIX

    • Linux x64

    • Sun Solaris SPARC

    • Sun Solaris x64

    • Windows x64

    In certain scenarios, the CS_NUMERIC and CS_DECIMAL data types are not supported by BatchSQL because of a bug in the Sybase specific CT Library. LOB replication is supported in BatchSql mode for Sybase database version 157 SP110 onward. This will improve the LOB replication performance. It is restricted to 16384 bytes of LOB data that means if LOB data is more than 16384 bytes, the data would not be processed through BATCHSQL mode instead the mode switched to Normal.

  • Limitations on Computed Columns support are as follows:

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

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

    • 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 are not used. 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, all of the columns are used 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. Sybase does not support non-persisted computed columns as part of a key so neither does Oracle GoldenGate.

    • To support TRUNCATE TABLE, all table names should be unique across all schemas within a database. This rule applies to Extract and Replicat.

  • Limitations on Automatic Heartbeat Table support are as follows:

    • Heartbeat frequency should an integer that is divisible by 60. Oracle GoldenGate heartbeat parameter frequency is accepted in minutes, although you can use in seconds. The Sybase job scheduler uses the minutes in integer not in decimal so it is converted internally to set the frequency in minutes to the nearest possible value. For example, setting this value to 65 seconds results in the frequency being set to 1 minute; 140 seconds results in the value set to 2 minutes.

    • Data truncation occurs with a Replicat abend when it exceeds more than 1500 characters for the incoming_routing_path and outgoing_routing_path of the GG_HEARTBEAT_SEED, GG_HEARTBEAT, and GG_HEARTBEAT_HISTORY tables. The incoming_routing_path and outgoing_routing_path size of these table is set to 1500 characters in ASCII and is a 500 max bytes in multibyte characters. Ensure that the incoming and outgoing routing path strings are within the specified limit.

    • Sybase job scheduler must be configured on the ASE server prior to running Oracle GoldenGate heartbeat functionality.

    • For heartbeat table functionality to operate correctly, the login user must have the replication_role, js_admin_role, js_user_role roles.