About Openflow Connector for Oracle¶

1. Embedded License (Snowflake-provided)¶

Snowflake provides the Oracle XStream license to you directly for a fee. This model allows you to consume XStream replication without a direct contract with Oracle. For more information, see Embedded license details and the Openflow Connector for Oracle Addendum.

2. Independent license (Bring Your Own License - BYOL)¶

You provide your own Oracle license that includes XStream entitlements (for example, Oracle GoldenGate license). For more information, see Independent license (BYOL) details.

Billing¶

Oracle XStream services are billed monthly and drawn from your Snowflake capacity balance. The fee has two components - a license fee and a Support & Maintenance (S&M) fee. The license fee is calculated based on the number of processor cores in your source Oracle database, multiplied by the Oracle Processor Core Factor.

Commitment (The “Day 61” Rule)¶

The first 60 days are free for up to 16 licensed cores. However, activating the connector beyond the 60-day trial initiates a non-cancelable 36-month billing term (“Initial Term”).

• Automatic Conversion: Billing commences automatically on Day 61. To avoid charges, you must cancel the trial in the Admin » Terms » Openflow for Oracle dashboard before Day 60.

• Lock-in: If your Snowflake agreement is terminated during this Initial Term, the entire remaining balance for the Initial Term becomes due immediately.

Post-term renewal and penalties¶

After the Initial Term, the license fee becomes $0 but the Support & Maintenance (S&M) fee continues.

• Opt-out Consequence: You can opt-out of S&M renewal through the dashboard in Admin » Terms » Openflow for Oracle. However, if S&M coverage stops, the connector processors are locked. To resume operations, you must purchase a NEW Embedded License (resetting the 36-month full-price commitment).

Requirements¶

You are responsible for accurately reporting the number of processor cores and the correct core factor in the connector configuration. This information must be kept current if your source database hardware changes.

Restrictions¶

This option is not available for:

• Public sector entities (for example, Government and Education entities).

• Customers purchasing Snowflake through the GCP Marketplace.

• Customers contracted with Snowflake through a third-party reseller (for example, CDW, Optiv).

Configuration¶

To configure the Embedded License:

• Review and accept the Openflow Connector for Oracle Addendum terms presented in the UI.

• Select the Embedded License type.

• Enter the CPU core count details for your source Oracle database: Total Cores (the total number of physical cores on the source database server) and Core Factor (the Oracle processor core factor, for example, 0.5 for Intel processors). Consult the Oracle Processor Core Factor Table for the correct value.

Requirements¶

You are solely responsible for ensuring that your use of the connector complies with the terms of your existing Oracle license agreement. Snowflake does not validate or audit your Oracle entitlements.

Configuration¶

To configure the Independent License (BYOL):

• Review and accept the Openflow Connector for Oracle Addendum terms presented in the UI.

• Select the Independent License type.

When configuring the connector, proceed without entering any core count or billing-related information.

How tables are replicated¶

The tables are replicated in the following stages:

1. Schema introspection: The connector discovers the columns in the source table, including the column names and types, then validates them against Snowflake’s and the connector’s Limitations. Validation failures cause this stage to fail, and the cycle completes. After successful completion of this stage, the connector creates an empty destination table in Snowflake.

2. Snapshot load: The connector copies all data available in the source table into the destination table. If this stage fails, then no more data is replicated. After successful completion, the data from the source table is available in the destination table.

3. Incremental load: The connector tracks changes in the source table and applies those changes to the destination table. This process continues until the table is removed from replication. Failure at this stage permanently stops replication of the source table until the issue is resolved.

Table replication status¶

Interim failures, such as connection errors, do not prevent table replication. However, permanent failures, such as unsupported data types, prevent table replication.

To troubleshoot replication issues or verify that a table has been successfully removed from the replication flow, check the Table State Store:

1. In the Openflow runtime canvas, right-click a processor group and choose Controller Services. A table listing controller services displays.

2. Locate the row labeled Table State Store, click the More button on the right side of the row, and then choose View State.

A list of tables and their current states displays. Type in the search box to filter the list by table name. The possible states are:

• NEW: The table is scheduled for replication but replication hasn’t started.

• SNAPSHOT_REPLICATION: The connector is copying existing data. This status displays until all records are stored in the destination table.

• INCREMENTAL_REPLICATION: The connector is actively replicating changes. This status displays after snapshot replication ends and continues to display indefinitely until a table is either removed from replication or replication fails.

• FAILED: Replication has permanently stopped due to an error.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

If a permanent failure prevents table replication, remove the table from replication. After you address the problem that caused the failure, you can add the table back to replication. For more information, see Restart table replication.

Data retention¶

Destination table metadata columns¶

Each destination table includes the following metadata columns that track replication information:

Soft-deleted rows¶

When a row is deleted from the source table, the connector does not physically remove it from the destination table. Instead, the row is marked as deleted by setting the _SNOWFLAKE_DELETED metadata column to true.

This approach allows you to:

• Retain historical data for auditing or compliance purposes.

• Query deleted records when needed.

• Decide when and how to permanently remove data based on your requirements.

To query only active (non-deleted) rows, filter on the _SNOWFLAKE_DELETED column:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

To query deleted rows:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

Dropped columns¶

When a column is dropped from the source table, the connector does not drop the corresponding column from the destination table. Instead, the column is renamed by appending the __SNOWFLAKE_DELETED suffix to preserve historical values.

For example, if a column named EMAIL is dropped from the source table, it is renamed to EMAIL__SNOWFLAKE_DELETED in the destination table. Rows that existed before the column was dropped retain their original values, while rows added after the drop have NULL in this column.

You can still query historical values from the renamed column:

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

Renamed columns¶

Due to limitations in CDC (Change Data Capture) mechanisms, the connector cannot distinguish between a column being renamed and a column being dropped followed by a new column being added. As a result, when you rename a column in the source table, the connector treats this as two separate operations: dropping the original column and adding a new column with the new name.

For example, if you rename a column from A to B in the source table, the destination table will contain:

• A__SNOWFLAKE_DELETED: Contains values from before the rename. Rows added after the rename have NULL in this column.

• B: Contains values from after the rename. Rows that existed before the rename have NULL in this column.

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

Journal tables¶

During incremental replication, changes from the source database are first written to journal tables before being merged into the destination tables. The connector does not automatically remove data from journal tables, as this data may be useful for auditing, debugging, or reprocessing purposes.

Journal tables are created in the same schema as their corresponding destination tables and follow this naming convention:

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

Where:

• <TABLE_NAME> is the name of the destination table.

• <timestamp> is the creation timestamp in Unix epoch format (seconds since January 1, 1970), ensuring uniqueness.

• <number> starts at 1 and increments whenever the destination table schema changes, either due to schema changes in the source table or modifications to column filters.

For example, if your destination table is SALES.ORDERS, the journal table might be named SALES.ORDERS_JOURNAL_1705320000_1.