Fivetran Uses _fivetran_id Instead of the Oracle Source Primary Key

Issue

An Oracle connection configured with Binary Log Reader uses _fivetran_id as the destination primary key, even though the source table has a primary key.

Environment

• Connector: Oracle
• Incremental sync method: Binary Log Reader

Resolution

To resolve this issue, rename the affected source table, schema, or column so that all identifiers are 30 characters or fewer. For example:

ALTER TABLE your_table RENAME COLUMN <long_column_name> TO <short_name>;

Before renaming a production column, determine whether any reports, jobs, or downstream systems reference its current name.

We detect this DDL change and trigger a re-sync while processing the updated redo logs. A manual re-sync isn't required.

Cause

This issue occurs when a source schema, table, or column name exceeds 30 characters. When this happens, Oracle suppresses supplemental logging for the entire table, which means the redo logs no longer contain the information Binary Log Reader needs to replicate changes using the primary key. To prevent data loss, we fall back to ROWID-based capture and use _fivetran_id as the destination primary key.

Excluding a long-named column from your connection schema doesn't resolve the issue. Oracle suppresses supplemental logging based on the column's presence in the source table, regardless of whether you include it in your connection schema. We can't restore the suppressed logging.