SQL Server: Supported Data Types, Objects, and Operations

Learn about support information for Oracle GoldenGate on SQL Server Database.

With Oracle GoldenGate for SQL Server supports capture and delivery of initial load and transactional data for supported SQL Server database versions.

Oracle GoldenGate for SQL Server supports the mapping, filtering, and transformation of source data, unless noted otherwise in this document, as well as replicating data derived from other source databases supported by Oracle GoldenGate, into SQL Server databases.

Instance Requirements

Database Requirements

Observe the following requirements and limitations for supporting Oracle GoldenGate:

Limitations:

Table Requirements

Tables to be included for capture and delivery must include only the data types that are listed in Supported SQL Server Data Types.

Supported SQL Server Data Types

The following data types are supported for capture and delivery, unless specifically noted in the limitations that follow:

Limitations:

Limitations on Computed Columns:

Non-Supported SQL Server Data Types and Features

Supported Objects and Operations for SQL Server

The following objects and operations are supported:

Non-Supported Objects and Operations for SQL Server

The following objects and operations are not supported:

Requirements for Table Level DDL Changes

Oracle GoldenGate for SQL Server does not support the capture or delivery of DDL changes. However, beginning with Oracle GoldenGate 21c, changes made to tables enabled with TRANDATA will not cause Extract to abend. Extract will continue to process change data for the table as it existed when TRANDATA was enabled.

Operations considered to be table-level DDL changes include, but are not limited to: ALTER TABLE, TRUNCATE TABLE, index rebuilds, and partition switches.

To avoid data inconsistencies due to table level DDL changes, the following steps are required.

  1. Source: Pause or Stop application data to the table or tables to be modified.

  2. Source: Ensure that there are no open transactions against the table to be modified.

  3. Source: Ensure that the SQL Server CDC Capture job processes all remaining transactions for the table that is to be modified.

  4. Source: Ensure that the Extract processes all the transactions for the table that is to be modified, prior to making any DDL changes.

  5. Target: Ensure that the Replicat processes all the transactions for the table that is to be modified, prior to making any DDL changes.

  6. Optionally, implementing an Event Marker table can be used to determine when all of the remaining transactions have been processed for the table that is to be modified, and handle the coordination of when to correctly stop the Extract and Replicat.

  7. Source: Stop the Extract process.

  8. Target: Stop the Replicat process.

  9. Source: Disable supplemental logging for the table to be modified by running DELETE TRANDATA.

  10. Source: Make table DDL changes to the source table.

  11. Target: Make table DDL changes to the target table.

  12. Source: Re-enable supplemental logging by running ADD TRANDATA to the table(s) after the modifications have been performed.

  13. Source: Start the Extract.

  14. Target: Start the Replicat.

  15. Source: Resume application data to the table or tables that were modified.

System Schemas for SQL Server

The following system schemas are not supported for Replication:

The guest schema is not supported using wildcard mappings, but is supported when explicitly listed, such as TABLE guest.employees.