Release Notes
April 2023
We now support syncing the INTERVAL YEAR TO MONTH and INTERVAL DAY TO SECOND data types from your source. They appear as the STRING data type in your destination.
Now, if we detect non-specified precision or scale in your source data, we map that data to the STRING data type in your destination. Previously, we mapped it to the FLOAT data type.
October 2022
Fivetran Teleport Sync is now available in beta for our Oracle and Oracle E-Business Suite connectors. Learn more in our Fivetran Teleport Sync for Oracle documentation.
August 2022
Fivetran history mode is now in beta for the following connectors:
Learn more in our history mode documentation.
February 2022
Our Oracle RAC connector is now generally available.
See our Oracle RAC connector setup instructions.
September 2021
Our Generic Oracle, Oracle RAC, and Oracle E-Business Suite connectors now support multitenant container databases. Learn more in our Supported configurations documentation.
July 2020
We have fixed a bug with very high-precision NUMBER values from Oracle. Previously, we either truncated these values or did not sync them to the destination. Now, we sync these values to the destination without truncating them, but we change the column type to STRING to accommodate high-precision values. Re-sync any tables where you have previously synced high-precision NUMBER values to ensure data integrity.
May 2020
You can now configure your Generic Oracle, RDS Oracle, and Oracle E-Business Suite connectors using the Fivetran REST API. This feature is in BETA and available only for Standard and Enterprise accounts.
We have a new method for counting the rows in a table that is much faster than our old method. Previously, the query we used to count rows would sometimes time out after 30 minutes, causing the sync to fail. The new method's speed makes your syncs much more reliable. If the new method fails, we will fall back to the old method.
April 2020
We have a new way to import tables with fewer than 1 million rows. Our new method will make initial and historical syncs much faster and reduce the resource load on your Oracle database. We will roll out this change over the next few weeks.
We have fixed a bug where we mapped NUMBER column values incorrectly if the column was defined with no precision or scale in the source database. Previously, these values may have been truncated in the destination, but they are now copied to the destination exactly as they appear in the source database. We will roll out this fix over the next few weeks. Once the fix rolls out to you, re-sync any tables where you have previously synced NUMBER column values to ensure data integrity.
February 2020
We have fixed a bug with FLOAT, REAL, and DOUBLE PRECISION column values. Previously, these values may have been truncated in the destination, but they are now copied to the destination exactly as they appear in the source database.
January 2020
We are rolling out support for TRUNCATE statements. When we encounter a TRUNCATE statement for one of your selected tables, we set the _fivetran_deleted column value to TRUE for every row in that table that predates the TRUNCATE statement.
December 2019
We now create a task in your Fivetran dashboard that reminds you to re-sync your data when you have a transaction that has been uncommitted for more than six hours. The re-sync ensures that we do not miss any data from our syncs.
We are rolling out support for RAW column types.
November 2019
We now support the TIMESTAMP WITH LOCAL TIME ZONE column type. It will appear as TIMESTAMP in your destination.
We've fixed some bugs with NUMBER and FLOAT column types with high precision or scale. Previously, these values might have been rounded, but they are now copied to the destination exactly as they appear in the source database. Oracle 11g is an exception to this fix because LogMiner incorrectly rounds some values.
We no longer re-sync tables when we detect GRANT DDL operations. We will roll out this change to all connectors over the next four weeks.
October 2019
The two-hour limit on importing tables has been removed resulting in fewer syncs appearing as "Rescheduled" in the dashboard.
Syncs that fail due to falling behind processing archive logs during the incremental update phase will appear as "Rescheduled" in the dashboard and are attempted again immediately. Previously, there was no indication of a problem.
These changes will be rolled out over the next month.
September 2019
If you have a logging service connected to your Fivetran account, the import progress of your tables in the event logs will be visible in your logs as an import_progress event. Table names will be in either the COMPLETE or IN_PROGRESS state, depending on their sync status. Tables that are not reported in the event have not started their import.
We have reduced our minimum archive log retention period to 3 hours. We still recommend setting a retention time of more than 24 hours.
We've fixed a few bugs that slowed down the import process for partitioned tables. To leverage the new speed improvements, you must enable SELECT access to the DBA_EXTENTS, DBA_TABLESPACES, and DBA_SEGMENTS system views. A new warning message on the Alerts page of your Fivetran dashboard will prompt you to enable access.
August 2019
We have optimized our LogMiner query. The query now only selects for and processes tables which have changes inside the window for which LogMiner is active.
Incremental updates should now make progress even when the connection to the server is unstable. This will reduce the number of failed syncs due to temporary network issues.
Improvements to fast import strategy
Our quick import strategy now works for tables stored in BIGFILE tablespaces. However, this requires access to another view: dba_tablespaces. You will receive a one-time warning requesting access to dba_tablespaces in your dashboard the next time your Oracle connector runs.
If you have previously given us permission for dba_extents and choose not to provide access to dba_tablespaces, your connector's initial imports will still benefit from the quicker imports but may not sync data from tables stored in BIGFILE tablespaces.
The Systems Views Permission setup test will now include information about dba_tablespaces, in addition to dba_extents, if you choose not to provide access to them.
Changes to connection method requirements for Oracle connectors
Going forward, all connectors for Oracle databases versions 12.1 and earlier will be required to connect via SSH tunnels. This connection method ensures that all connections to your databases are secure and encrypted. If you do not currently connect via SSH tunnel, you will be required to update your connection method to continue syncing data. To set up an SSH tunnel, reach out to your network administrator.
July 2019
We have added support for table-level supplemental logging. This will reduce overhead when syncing with Fivetran if you only want to replicate some of your tables in an Oracle database.
June 2019
We can now sync changes to primary keys.
For each table where the primary key is expected to change, you need to run the following query:
ALTER TABLE "<schema>"."<table>" ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS
If you don't configure the logging data correctly, you will receive a warning when Fivetran encounters a primary key change. The warning will give you customized instructions.
We will gradually roll out this improvement to connectors over the next month.
March 2019
Fivetran has added core support for the TIMESTAMP WITHOUT TIMEZONE data type. Up until now, Fivetran assumed that timestamps without timezone were in UTC. This addition means that for the following databases with a TIMESTAMP WITHOUT TIMEZONE type will replicate to a more correct destination type:
- MySQL
- Oracle
- PostgreSQL
- SQL Server
TIMESTAMP WITHOUT TIMEZONE support is immediately available for Oracle, PostgreSQL, and SQL Server. MySQL and MariaDB support will be released soon.
| Source | Applicable Type |
|---|---|
| Oracle | TIMESTAMP |
| PostgreSQL | TIMESTAMP |
| SQL Server | DATETIME, DATETIME2, SMALLDATETIME |
| MySQL and MariaDB | DATETIME |
This change is backwards compatible. Fivetran will continue assuming UTC time zone if the destination type is TIMESTAMP WITH TIMEZONE. In order to get the more specific type, drop the table in the destination and re-sync the table in your Fivetran dashboard.
We are changing our architecture to allow for much higher data throughput. Starting on April 30, 2019, all Fivetran connectors will originate from a new set of fixed IP addresses. For the US region, these IPs are:
- 35.227.135.0/29
- 35.234.176.144/29
- 52.0.2.4/32.
Update your IP safelists for the following databases and destinations before April 30. Not doing so will result in a connection failure.
Databases:
- MariaDB
- MongoDB
- MySQL
- Oracle
- PostgreSQL
- SQL Server
Destinations:
- Redshift
- Azure Synapse
- Snowflake
If you don't use any of the above databases or destinations with Fivetran, you don't need to take any action.
Fivetran has significantly increased the speed of initial syncs in Oracle by leveraging information from a system metadata table called DBA_EXTENTS.
November 2018
You can now trigger re-syncs of individual tables from your Fivetran dashboard:
The re-sync button appears when you hover your cursor over the row that contains the table name.
This feature is available for the following connectors:
- Amazon DynamoDB
- MongoDB
- MySQL
- NetSuite SuiteAnalytics
- Oracle
- PostgreSQL
- Salesforce
- SQL Server
- Zuora
August 2018
For Oracle connectors, TIMESTAMP data types will now be represented as TIMESTAMP WITHOUT TIME ZONE types in the destination. Since DATE column types are also timezone unaware, dates that lack a time component will be interpreted as TIMESTAMP WITHOUT TIME ZONE types as well. This update is currently only available for Snowflake destinations.
April 2018
Oracle's DATE data type is really a TIMESTAMP WITH TIME ZONE. It is a common convention to use midnight as a way to represent dates in Oracle. We now detect this pattern and convert these values to DATE in the destination. If you currently have an Oracle connector, you will need to change the existing TIMESTAMP WITH TIME ZONE columns in your destination to DATE columns in order to leverage this feature.
When performing the initial sync of large tables from Oracle RAC sources, we now use smaller block ranges to avoid getting interrupted by multi-node transactions.
We receive changed data from Oracle using LogMiner, and we use the system change number (SCN) as a cursor. We now use smaller ranges of SCNs to reduce the probability of a failed request.
You now get a warning in your Fivetran dashboard when no database transactions have been committed for over an hour after the start of the transaction.